Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

Post reply on HN
Print view View original

171–180 of 201 posts

Re: An Intuition for Lisp Syntax

#171

Post by slgeorge »

redwoolf wrote: post #157

The problem I'm having with Lisp isn't the syntax or the language, but the ecosystem. Or rather learning about the ecosystem. There's not much information, from what I've found, about best practices for creating a production ready application. A lot of Lisp tutorials and books extoll the virtues of the language and REPL based development but stop there. For example, I want to figure out how to use Lisp in a CI/CD env…

> There's not much information, from what I've found, about best practises for creating a production ready application

I have an interest in functional (Lisp) and decided that for me Clojure was a good choice. It was designed to be used in industry so there's people out there who are using it for real applications. Although I wasn't a fan of the JVM I've learnt my bias was wrong and it's given me access to an ecosystem of libraries.

As I'm more informed now I think that learning Racket, F# or one of the others would also have been fine. But, I don't regret Clojure.

They're all small(ish) communities so you have to be willing to invest in the community, be willing to put together solutions from bits of information and enjoy experimenting.

Whether that's the best use of your time is up to you ;-)

Re: An Intuition for Lisp Syntax

#172

Post by ACow_Adonis »

abhinav22 wrote: post #156
ACow_Adonis wrote: post #97

Earlier quoted context omitted.

It is and it isn't :) Obviously opinions on the language shouldn't be given too much weight if a person hasn't spent too much time investigating/ using it. As a non-JavaScript person, all the JavaScript examples looks like gobbledygook unless I sit down and consciously think about what the examples are showing, and it kinda hurts my head a bit, but I can slowly force myself through it. But as someone with a few years…

Hey :) You wrote a really nice comment ages ago, which partly inspired me to learn lisp and also it’s formatting. I still want clean it up a fair bit, but here’s the draft article: https://ashokkhanna-530.medium.com/formatting-lisp-5e28020b8... Hope it’s okay to use your quote! And if not, I’ll take it down

perfectly ok from me, honestly I'm flattered :)

Re: An Intuition for Lisp Syntax

#173

Post by zeveb »

brabel wrote: post #46
nynx wrote: post #10

I've never really bothered to learn lisp, but this is incredible. I get it now. That being said, I wonder how data types would work as opposed to lists. What would a language based around maps look like?

It would look like Lua: https://www.lua.org They call "maps" tables. Even arrays in Lua are tables, as are everything else. Pretty cool concept... And there's even a low level, statically typed, system language that uses Lua as a composer language, Terra: http://terralang.org In Terra, you manipulate your program using Lua at compile time. Really cool concept.

A large difference is that Lua source is not in the form of Lua tables — and that makes all the difference! Having full access to your complete language at read, compile and run times is what makes Lisp Lisp, and that can only sanely be done with a homoiconic language.

Re: An Intuition for Lisp Syntax

#174

Post by lispm »

PopsiclePete wrote: post #169

To me the problem with LISP's was never the syntax, I understand s-expressions and homoiconicity and all that, the problem was also....this is embarrassing...the dev setup/environment. In every single non-LISP language/environment - whether it be C, C++, Rust, Go, C#, Java - I can sit down comfortably in VIM or Vscode+VIM and just start hacking away. With LISPs, I always feel like I'm fighting my editor - and I am. I…

You could use Lisp in a batch style. I would then propose to use a compiler-based implementation like SBCL, since the compiler gives a lot of feedback. That can help in batch programming -> write code, compile it, run it -> with the added error messages from the compiler or the runtime.

Some people program Lisp with very primitive editors, but they better use the Read Eval Print Loop for interactive programming, too. That would be different from the usual C, C++, ... Java programming. You would need to understand interactive programming. That's a level one needs to master - especially in many situations (and where one does not use SBCL) the dynamic typing of much of Lisp requires interactive exploration/debugging.

Re: An Intuition for Lisp Syntax

#175

Post by Viliam1234 »

jFriedensreich wrote: post #49
simongray wrote: post #44

Earlier quoted context omitted.

> I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain, it would be cool if we could generate them from more readable syntax, maybe something like javascript :D . So many people start out thinking like this when they learn Clojure or some other Lisp and then after like 2-4 weeks of reading Lisp code, any C-like code starts to look co…

I heard that before but i wonder how much is survivorship bias :D it reads just so awkward to me as a programming language, even though i 100% dig the beauty and everything that it allows.

I used Java for 10+ years, including now, and I worked briefly in Clojure for less than 1 year. I think the Clojure syntax is way more reasonable, although I appreciate the maturity of tools used with Java.

Two things were important to make it "click" for me:

1) I realized that "Lisp has many parentheses" actually has it backwards. A Lisp code has about as many parentheses as an equivalent Java code; there is almost a 1:1 relation. It just has less of... unnecessary things. Which results in more "parentheses per square meter", but from this perspective that is a good thing!

2) Some people complain that dense code is more difficult to read. But you don't have to turn everything into one-liners! You can format it into just as many lines as the Java code would have, except the lines will be much shorter now, and therefore easier to read. In Java, you don't have much freedom with formatting, because a typical statement takes more that half of the screen width, so you are stuck with one long column. Lisp with shorter statements gives you more freedom. You can abuse it to write hard-to-read code. You can also use it to design beautiful code that is easy to read. Also, there is a huge difference in legibility of a code that fits in one screen (so you can see it whole at once) and one that does not; and the Lisp functions are shorter on average.

Re: An Intuition for Lisp Syntax

#176

Post by tonyarkles »

bbbobbb wrote: post #161
tonyarkles wrote: post #111

Earlier quoted context omitted.

Going with the example in the article and the nominal purpose of it... how would you take what you’ve written above and parse/execute it without using eval. I’m with you, generally. I have used CL off and on for the last 20 years, and when I come back to it it takes a solid week before I start “reading in Lisp”. It definitely doesn’t come naturally when you spend most of your time reading “C-type” syntax all day. But…

Genuine question since I might be missing something: how would you take the lisp version and parse/execute it without using something like eval?

I'm not sure if you mean in JS or in CL, but it works basically the same way: deserialize it (not eval) and walk through the array, doing the exact same kind of steps they're doing in the article for the JS version. Build up a symbol table (or two, if your function names and variable names are in different namespaces). The evaluation rules are so simple and consistent that the logic required while walking the array is pretty tiny.

To do the same thing with Javascript code involves parsing into an AST and walking the that tree; the hard part is that the rules for walking that tree are dramatically more complicated. In the Lisp case, the AST and the original code look very similar; in the JS case, they diverge quite a bit (there's a ton of crazy things in the JS spec if you dig through it)

Re: An Intuition for Lisp Syntax

#177

Post by Viliam1234 »

eMSF wrote: post #127
coldtea wrote: post #99

Earlier quoted context omitted.

> I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain is (map foo '(1 2 3)) that more difficult than: [1, 2, 3].map(foo) ? Or: (let ((array #(1 2 3 4 5))) (vector-set! array 0 3) (vector-ref array 0)) that more difficult than: let array = [1, 2, 3, 4, 5]; array[0]=3 array[0]

Is (* (f (+ 2 x)) 5) more difficult to parse than: 5 * f(x+2) Considering that we're familiar with the latter syntax (more or less) since kindergarten, I'd say... yes. And the idea that you'd somehow start to consider something you've been doing all your life as “irregular” after 2–4 weeks of Lisp cure is just hilarious.

Depending on how frequent are complex equations in your code, you could make a macro for it, and write it e.g. like this:

  (math 5 * f (x + 2))
I might be tempted to do so if I frequently encountered math expressions of depth 3 or more, which in my short Lisp career I didn't.

Also, I would probably rewrite the expression as:

  (* 5 (f (+ x 2)))
to make it easier to read by putting the simple operand first; or in case of two difficult operands I would use formatting:

  (* (f (+ x 2))
     (g (+ x 3)))
Note that a good editor would check that the parentheses match the formatting, so I wouldn't really count that 3 closing parentheses are needed in the last line; they would be inserted automatically.

Re: An Intuition for Lisp Syntax

#178

Post by Reelin »

flavio81 wrote: post #167
Reelin wrote: post #37

Earlier quoted context omitted.

> a well-structured way to define and enforce APIs I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp? > and oh wow, typing facilities Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.

>Common Lisp isn't typed It is heavily typed. Very strongly typed for the most part (except numbers). So typed that it won't accept a "character vector" in the place of a string. But type checking is mostly at runtime, not at compile-time. The good part is that you can edit your program at runtime and restart it at the exact point the error happened, very easily.

In context, particularly given the reference I made to Typed Racket, it should be abundantly clear that I'm referring to the lack of static typing there.

That being said, I think you'll find truly untyped languages hard to come by. Other than assembly, Forth (similar to assembly in many ways), and esolangs such as Befunge (also quite similar to assembly), languages that see widespread use always check types eventually. Checking types eventually is table stakes. Checking types at compile time, before what you wrote has a chance to explode on you in an unpredictable manner when that one branch for an edge case finally gets taken after a few days of uptime, that's the truly desirable feature that not all languages manage to provide.

Re: An Intuition for Lisp Syntax

#179

Post by novok »

ACow_Adonis wrote: post #97
username90 wrote: post #85

Earlier quoted context omitted.

That becomes a no true Scotsman fallacy though. People argue "Either you like lisp syntax or you haven't used it enough to have a valid opinion". That is a bullshit argument.

It is and it isn't :) Obviously opinions on the language shouldn't be given too much weight if a person hasn't spent too much time investigating/ using it. As a non-JavaScript person, all the JavaScript examples looks like gobbledygook unless I sit down and consciously think about what the examples are showing, and it kinda hurts my head a bit, but I can slowly force myself through it. But as someone with a few years…

I think it's like a language family thing. If your familiar with a C-language (or more accurately, AGOL style) then looking at other C-languages isn't as alien to you. While looking at a LISP family language, it's a different language branch and so you have to learn some new ways of thinking, which can be disorienting.

Ex french & english vs french & indonesian. English and french can recognize words from each other and kind of see some similar grammar rules (the medicine vs. la médecine) while with indonesian those moments are not as frequent.

Re: An Intuition for Lisp Syntax

#180

Post by Reelin »

Jtsummers wrote: post #137
Reelin wrote: post #37

Earlier quoted context omitted.

> a well-structured way to define and enforce APIs I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp? > and oh wow, typing facilities Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.

Common Lisp is typed. It is not (consistently, see SBCL for a counterexample) statically typed. If you try to do: (+ "hello" 3) You will get an error in CL, and with SBCL an expression like that wouldn't even compile.

Yes, I'm aware (see my nearby comment for more detail).

I very much enjoy writing Common Lisp, but use SBCL almost exclusively specifically because of the amount of (static) type checking it does. Even then, there are significant limitations that often leave me frustrated in comparison.

Post reply on HN