[HN Gopher] Lisp in Space
___________________________________________________________________
Lisp in Space
Author : dargscisyhp
Score : 107 points
Date : 2023-08-06 12:18 UTC (10 hours ago)
(HTM) web link (corecursive.com)
(TXT) w3m dump (corecursive.com)
| thatcherc wrote:
| If JuliaCon last week is any indication, there might be more Lisp
| in space in the future! As long as the runtime size can be shrunk
| down a bit, but it sounds like that's in the works too.
| netbioserror wrote:
| If I'm remembering correctly there are some CL compilers that
| aim for runtime-free small native executables, even with
| realtime constraints, but I forget which.
| capableweb wrote:
| Not CL, but there is ulisp (http://www.ulisp.com/) for
| microcontrollers, supposed to be really tiny, and there is
| Carp (https://github.com/carp-lang/Carp) which is without a
| GC so seems suitable for real-time stuff.
| imachine1980_ wrote:
| any video of this ?
| adgjlsfhk1 wrote:
| They're starting to be posted, but it will be a few more
| weeks before they're all uploaded. There was a period for a
| week or two after juliacon where the raw 6 hour live-streams
| were up (it was in person this year), but now they are taken
| down because MIT requires all non-livestreamed videos to be
| captioned (for accessibility reasons).
| imachine1980_ wrote:
| Do you remember the name of the talk, so I can see it when
| upload
| thatcherc wrote:
| Slim binaries and better static compilation were
| mentioned as big future features in the closing remarks,
| so that'd be a good one to watch - a lot of the people
| there working in embedded, robotics, or plane satellite
| projects were excited about those.
|
| There weren't any talks I saw where anyone was actually
| running Julia in space, but Ronan Chagas' "Attitude
| control subsystem development using Julia" and Corbin
| Klett's "Realtime embedded systems testing with Julia"
| both get pretty close and point out reasons why you
| wouldn't quite want to run Julia on a satellite or plane
| just yet. Hopefully the videos capture the questions from
| the audience because there were some good followups!
| coldtea wrote:
| These sound like being about Julia proper.
|
| How does that fit with your initial "If JuliaCon last
| week is any indication, there might be more Lisp in space
| in the future"?
|
| Is this about some Lisp written in Julia? Some Lisp with
| interoperability with Julia? Or it's based on considering
| Julia itself a Lisp for some reason?
| leke wrote:
| Are there any popular lisps without parentheses or at least with
| minimal parentheses?
| wjbr wrote:
| If the lisp has read macros you can add it yourself.
|
| There's: sweet-expression
|
| https://srfi.schemers.org/srfi-110/srfi-110.html
|
| https://sourceforge.net/p/readable/wiki/Examples/
| define fibfast(n) ; Typical function notation if {n
| < 2} ; Indentation, infix {...} n
| ; Single expr = no new list fibup(n 2 1 0) ; Simple
| function calls define fibup(maxnum count n-1 n-2)
| if {maxnum = count} {n-1 + n-2} fibup
| maxnum {count + 1} {n-1 + n-2} n-1 define
| factorial(n) if {n <= 1} 1 {n
| * factorial{n - 1}} ; f{...} => f({...})
| agumonkey wrote:
| there were some pseudo syntax made for scheme to remove some
| nesting
|
| see https://srfi.schemers.org/srfi-110/srfi-110.html
|
| not too far from https://chrisdone.com/posts/z/ posted before
|
| ps: personally, lisp syntax has been an issue once every 4
| years. with threading macros, paredit .. you spend 0.00001% of
| your time thinking about it.
| mhitza wrote:
| Any scheme that supports t-expressions
| https://srfi.schemers.org/srfi-110/srfi-110.html
|
| But that has a lot of pushback, and no scheme I've researched
| supported (implemented the SRFI) t-expressions out of the box.
| Usually it's some third party library or runtime you have to
| use for that.
|
| Have played around a bit with it in GNU Guile, but in some
| circumstances I myself got confused :)
| v9v wrote:
| Tcl has some Lisp-y attributes with a bash-esque syntax.
| emmelaich wrote:
| https://chrisdone.com/posts/z/
| pjmlp wrote:
| Dylan and Julia.
| mepian wrote:
| The closest thing to what you want is Dylan, which was
| originally created by Apple: https://opendylan.org/
|
| But parentheses aren't really that bad, after a while you get
| used to them and start seeing the actual structure behind them
| instead, kinda like that quote from The Matrix. Without them
| macros become much more complicated, especially if you want the
| syntax to be infix.
| gumby wrote:
| Honestly, why would you want that? If you start using Lisp you
| rapidly stop focusing on the parentheses and instead focus on
| the code structure.
|
| Indentation is a big guide, but can't do all the work.
| tromp wrote:
| This has been discussed many times before, as shown in
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| behnamoh wrote:
| And yet, none of these efforts caught on. It's as if people
| who like Lisp, like it __with__ parentheses and people who
| don't like Lisp, wouldn't like it even __without__
| parentheses.
| pfdietz wrote:
| The diagnosis that the "problem" with Lisp was the syntax
| has always been wrong.
| behnamoh wrote:
| For me, (...) are not the problem. But the thing that throws me
| off and confuses me when I read Lisp code is the excess use of
| long words. The language is too verbose for its own good. When
| I read Python or other languages, the space between the
| expressions/statements makes it much easier to follow the flow
| and understand what's going on. In Lisp, I often see lines
| stacked together with minimal room for my eyes to "rest".
| gumby wrote:
| As a long term (40+ year) Lisp developer I carry that forward
| into my other languages. Vertical whitespace is free in
| lisps,* as with most languages, so what I try to do us clump
| together an "operation" ideally so that it fits in my fovea
| when when I'm glancing at the code. So a quick glance tells
| me "this isn't what I'm looking for" or alternatively "all
| this goes together so read the whole thing before changing
| anything, but there's a good chance your change won't affect
| other parts of the function."
|
| Thus: (if (< foo 0) (do-this) (do-that))
|
| or if it's long (when (< foo this)
| (some-stuff) (more-stuff) ...)
|
| Obviously one can do this in C++ by introducing a block, but
| it isn't as syntactically natural; a block implies that there
| is important RAII involved, so usually I just do it by
| "vertical clumping"
|
| I find the standard c style (used by lots of languages)
| actually spreads the code out too much, emphasizing the curly
| braces rather than the code itself. (this is a local version
| of the OO+IDE plague that smears functionality across lots of
| tiny files.
|
| This sense of locality is presumably why the gnu programming
| style is compact in some ways and expansive in others,
| different from K&R style, for example,
|
| return-type function-name ( type1 arg1 ) {
|
| allows the eye to see the identifiers without the syntactical
| markers () and {}, letting indentation and vertical
| whitespace to tell a story.
|
| * except, _de facto_ , Interlisp because it normally used a
| structure editor rather than a text editor.
| kazinator wrote:
| Classic old Lisp doesn't have the problem of long words: it
| has mostly short words like _atom_ , _cons_ , _car_ , _cdr_ ,
| _array_ , ...
|
| Then, eventually, along comes Common Lisp with symbols like
| _multiple-value-bind_ and _update-instance-for-redefined-
| class_.
|
| I made a dialect called TXR Lisp in which most of the
| important symbols in the standard library are deliberately
| quite short, to avoid this readability/writability issue.
|
| Lisp code often avoids vertical breaks within sections in a
| function, because many constructs nest, and so the nesting
| and indentation separates them already, like:
| (while ... ... (let ... ...))
| (while ...
|
| It's like point form: - abcde -
| efgh - jlk - mn - next point
| djha-skin wrote:
| I'm told that Elixir still closely follows the tradition of
| "code as data" while the syntax actually looks more like ruby.
| Things like "do...end" blocks are actually just syntax sugar
| for effectively parentheses[1].
|
| I've also read that Julia is an acceptable Lisp [2].
|
| 1: https://news.ycombinator.com/item?id=36986769
|
| 2: https://mfiano.net/posts/2022-09-04-from-common-lisp-to-
| juli...
| behnamoh wrote:
| `do... end` blocks are a big no for me. You'd effectively
| replace single characters like (, {, [, with whole words.
| fndex wrote:
| Just get over it. Semantics are much more important than
| syntax. Every language will have some piece of syntax you
| won't like.
| rajandatta wrote:
| Don't know about popularity but Scheme has a SRFI and syntax
| 'model called Wisp which does away with most brackets. It
| relies on indentation.
| rajandatta wrote:
| syntax 'mode'
| DonaldFisk wrote:
| There are, or rather were Lisps with fewer parenthese: Lisp 2,
| CGOL, Dylan, but I wouldn't say they were popular. It isn't too
| difficult to write one yourself. After you've done so, and used
| it for a while, you'll understand better why those earlier
| projects never gained traction, and learn to love (or, where
| appropriate, not notice) Lisp's parentheses.
| wslh wrote:
| Don't know why you are so downvoted since your question is
| valid:
|
| A single sexpr with only atoms could be written without
| parenthesis and with a EOL.
| Zambyte wrote:
| Clojure and Clojure-like Lisps (Janet, Hylang) use fewer
| parenthesis by replacing them with other pairs of characters
| ([], {}) for certain block structures, which is exactly what
| other non-Lisps do. The only difference is that Clojure still
| puts the opening character at the beginning of the structure
| instead of in the middle, like how non-Lisp languages usually
| do.
| thih9 wrote:
| To be fair, there are more differences; where Clojure
| requires parentheses, non-Lisps often don't need them at all.
|
| E.g. in Python indentation carries meaning. Ruby has
| "do/end"; but also it's possible to skip parentheses in some
| function calls; there are pipes too. Haskell - whatever
| haskell does, sometimes also pipes. There are more examples.
|
| That being said, for me clojure parentheses were always more
| of a help than an inconvenience.
| behnamoh wrote:
| I actually find Clojure's syntax more confusing with all the
| punctuation they threw at it. Compare that, for example, with
| Scheme. I like the idea of keeping Lisps "pure" if that makes
| sense. In Lisp, the first element of a list is the operator.
| Okay, then how is Clojure a Lisp when it has vectors like
| this [1 2 3]? Unless [ is a macro that expands [1 2 3] to
| some real Lisp-y expression under the hood.
| pseudonamed wrote:
| It's a literal vector in the sense that '(1 2 3) is a
| literal list. Though unlike the quoted list it evaluates to
| itself, like a string or an int does.
| fndex wrote:
| > I actually find Clojure's syntax more confusing with all
| the punctuation they threw at it.
|
| Could you give some examples? Or "all the punctuation" you
| are referring just to []?
| Zambyte wrote:
| I'm not the same person you asked, but I find Clojure to
| be as easy to read as Scheme, but harder to write, since
| I need to remember what punctuation to use where.
| capableweb wrote:
| I don't know, it makes sense to use different data
| structures for different purposes. (), [], {} are all
| different data structures (lists, vectors and maps) that
| are useful in different situations, so makes sense to
| have shorthands for them.
| dreamcompiler wrote:
| Maybe. What bothers me about this idea is that it doesn't
| scale: As soon as you need a fourth bracket type you're
| hosed, because there are no more on the keyboard.
|
| With Common Lisp, you can define [ and { if you want to,
| but it's more common to use a reader macro character in
| front of an opening paren or a function name after it if
| you want different data structures. Those approaches
| scale.
| kazinator wrote:
| I just put out a new release of TXR, which has a change that
| can reduce the nesting.
|
| In pipes, you can now bind variables that are in scope of later
| pipeline elements. 1> (flow
| "/usr/share/dict/words" ; start with this path
| (file-get-lines) ; get content as list of lines
| (let lines) ; bind lines variable to this list
| len ; take length of list
| rand ; get pseudo-random in [0, length)
| lines) ; index into lines "subdues"
| manicennui wrote:
| Clojure has several threading macros:
| https://clojure.org/guides/threading_macros
| pfdietz wrote:
| These can all be defined in CL and have been.
|
| https://quickref.common-lisp.net/arrows.html
| lisper wrote:
| I have a macro in my personal library called BINDING-BLOCK that
| eliminates many (though not all) of the parens in common code
| idioms:
|
| https://github.com/rongarret/ergolib/blob/master/core/bindin...
|
| It's also helpful in preventing code from crawling off the
| right side of the screen.
|
| However, like many of the sibling comments point out, if you
| think getting rid of the parens entirely is desirable then you
| have missed the point, which is that Lisp code is not text,
| it's a data structure, a linked list, and the textual
| representation of the code is just a serialization of that data
| structure. And the most straightforward way to serialize a
| linked list is with delimiters at the start and end, like so:
|
| (1 2 3)
| Barrin92 wrote:
| well JavaScript if you're willing to buy into the idea that
| it's scheme in c syntax, which isn't actually that far off.
|
| But no, genuine lisps come with parentheses (or some
| equivalent) because, as the name suggests, the entire point is
| list processing. Lisp programs are just data without (much)
| syntax. The more syntax you add, the less of a lisp it is.
| gumby wrote:
| > well JavaScript if you're willing to buy into the idea that
| it's scheme in c syntax, which isn't actually that far off.
|
| It is quite far off. Just look at the version of "SICP in
| Javascript" (of which Julie Sussman was even one of the
| authors). The important points of the book are obscured by
| all the boilerplate and workarounds for the poor expressivity
| of the language.
| behnamoh wrote:
| Could it be that JS has poor expressivity for the concepts
| discussed in SICP, but good expressivity as a general
| scripting language[0]? Same thing for Python.
|
| [0] And conversely, Scheme doesn't have good expressivity
| as a scripting language.
| pjmlp wrote:
| Given Lisp Machines and Interlisp-D, I would state the
| issue with Scheme is more related to lack of tooling.
| gumby wrote:
| Scheme has better expressivity (or more expressive power
| if you want to put it that way) but there's a higher gain
| mismatch between its syntax and the things people usually
| script these days.
|
| Scripting languages are tightly coupled to the language
| they are scripting.
| dreamcompiler wrote:
| Dylan.
|
| But you said popular, so Javascript then. Seriously, JS is not
| what I'd consider a very good Lisp, but I think it is one
| because it allows you to build real lexical closures.
|
| Edit: Haskell is a sort of a lisp too, and it's the only one
| IMHO that got rid of the parens in an intelligent way. Haskell
| lets you use either prefix or infix notation, and it works
| mostly without parentheses. Plus you can use the '$' character
| as a clever hack to remove parens where they would otherwise be
| needed. But...the price you pay for this is laziness and
| automatic currying, which most Lisps don't do.
| ksherlock wrote:
| If you look at the original LISP paper, it uses meta-
| expressions. Then towards the end is the alternate syntax with
| parenthesis. The Wolfram (Mathematica) language and K were both
| inspired by meta-expressions.
| ssrc wrote:
| Logo would be the most obvious one.
| ynniv wrote:
| Try using a syntax highlighter that reduces their contrast and
| you'll find it looks a lot like python.
| JaDogg wrote:
| Wonder if you can consider a rainbow colour parenthesis plugin
| as an alternative
| [deleted]
| lisper wrote:
| Interview subject here. AMA (but I'm on the road so replies might
| be delayed).
| mepian wrote:
| What are you working on now?
| lisper wrote:
| Chip design tools at Intel. I didn't go there by choice. I
| went to work for a startup that got acquired. And I have a
| couple of side projects I can tell you about if you're
| interested.
| solanav wrote:
| Do share them please!
| lisper wrote:
| https://news.ycombinator.com/item?id=37027284
| rsecora wrote:
| I'd love to hear more about your side projects if you
| wouldn't mind.
| lisper wrote:
| I've started work on a book/blog (still haven't decided
| on the target medium) about how to apply the scientific
| method to everyday life. It's still very drafty, but if
| you want a sneak preview of the current state of things
| you can find it here:
|
| https://flownet.com/ron/TIKN/
|
| Feedback welcome.
|
| This is part of a more overarching effort to try to move
| the needle on climate change. I think one of the reasons
| it's such an intractable problem is that there is too
| much scientific ignorance out there, which supports an
| unjustified level of techno-optimism with regards to CO2
| emissions.
|
| I'm also thinking about turning TIKN into a YouTube
| channel because that seems to be what the cool kids are
| doing nowadays. But I'd want to do this with a
| collaborator because maintaining a YT channel is a
| fucking boatload of work. If you know anyone who might be
| interested please send them my way.
|
| Not entirely unrelated (in fact, the reason I know how
| hard it is to make a good video)... something I did about
| 15 years ago that I'm still proud of despite the fact
| that it never got any traction is make a documentary film
| about homeless people:
|
| https://graceofgodmovie.com/
| aag wrote:
| Ron gave this talk on the subject at Google back in 2012:
|
| https://www.youtube.com/watch?v=_gZK0tW8EhQ
| privong wrote:
| This history is also discussed in an essay by Garrett[0]. And
| there's been a few previous HN posts about it[1]. (I'm not
| suggesting the parent post is a dupe, but people might be
| interested in the essay and related contents).
|
| [0] https://flownet.com/gat/jpl-lisp.html
|
| [1]
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
___________________________________________________________________
(page generated 2023-08-06 23:01 UTC)