3 ms·

Speaking to why a LISP newbie finds it tough to get things done... I think most people think in imperative terms. "I want to make a type. Now, given a thing of

by ben509 7y ago

Speaking to why a LISP newbie finds it tough to get things done... I think most people think in imperative terms. "I want to make a type. Now, given a thing of that type, change a thing here, change a thing here, and return the thing I want." And most languages delineate a programmer's tasks clearly. For instance, in Python and Ruby, logical structure is expressed in blocks, control (mostly) transfers between statements, while calculation is performed in expressions, and these are all visually distinct. LISP's idea that all structures can be expressed as lists doesn't visually demarcate the distinct "things" a programmer is trying to compose. You can absolutely learn it, but it makes it harder. Now, since LISP does basically use an AST directly, it makes metaprogramming trivial. The beauty of extensive metaprogramming is that you can construct new languages cheaply. The curse is that you get a lot of cheaply constructed new languages. If Python wants to add an "async" keyword, they go through weeks of debate and do a long writeup on it.[1] In LISP, someone writes a few macros and, boom, new syntax. The LISP community are smart people, they recognized this and I think the standardization efforts tried to mitigate it, and a ton of thought clearly went into Scheme. But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. It's not as bad for others, though, because if you look at an example of Python code, you can generally see the structure and that narrows down what can fit there. Whereas LISP is always a mess of parens and keywords; yes, it's usually obvious from looking at the docs, but it's just more research you have to do to get something done.

flavio81 7y ago
>But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. On a typical language you have "structures" you mention, like "if", "for", "switch". Lisp also has them, but they look more like function calls. The syntax has a lot of less noise. Automatic indentation helps you visualize such "structures" in an easier way. It's not any more difficult than using a language like Python or C. >And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. Not really, because Common Lisp -the major Lisp dialect- is a strongly typed language, unlike the most popular dynamic languages: Javascript, PHP and Python and Ruby (Python & Ruby being 'duck typed' for the most part). And unlike the famous weakly-typed statically-typed language: C. So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. The most common data construct, the Lisp list, accepts any kind of data type inside, but Lisp also has structs, objects and arrays, all of which can be defined for specific data types. Note that the ANSI Common Lisp standard includes extensive support for type declarations. Not to mention that Lisp, unlike other languages (Java, C++ -- i'm looking at you guys) don't erase types at runtime. Lisp works with values (not variables) , and values are typed. Any value, in Lisp, carries its type information at runtime.
- ben509 7y ago
  > The syntax has a lot less noise. Note here how you unconsciously use "has" instead of "have", that kind of grammatical noise exists because those small redundancies help us understand each other. I think the reason very few computer languages use parens is because they're harder to read by virtue of having less grammatical redundancy. (At the other end of the spectrum, languages like COBOL are hard to read because they're swamped in redundancy.) > So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. I should have been clearer: it can go anywhere while you're writing it, so you have to run it to find out. That's the problem people also have with other dynamic languages when they're working on non-trivial codebases. Also, because types are rarely declared up front, you're often paging through code to figure out what type should go some place. > And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. I agree that's an amazing feature few langauges have been able to copy, but it seems like it wasn't enough.

by ben509 7y ago

flavio81 7y ago

>But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures. On a typical language you have "structures" you mention, like "if", "for", "switch". Lisp also has them, but they look more like function calls. The syntax has a lot of less noise. Automatic indentation helps you visualize such "structures" in an easier way. It's not any more difficult than using a language like Python or C. >And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. Not really, because Common Lisp -the major Lisp dialect- is a strongly typed language, unlike the most popular dynamic languages: Javascript, PHP and Python and Ruby (Python & Ruby being 'duck typed' for the most part). And unlike the famous weakly-typed statically-typed language: C. So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. The most common data construct, the Lisp list, accepts any kind of data type inside, but Lisp also has structs, objects and arrays, all of which can be defined for specific data types. Note that the ANSI Common Lisp standard includes extensive support for type declarations. Not to mention that Lisp, unlike other languages (Java, C++ -- i'm looking at you guys) don't erase types at runtime. Lisp works with values (not variables) , and values are typed. Any value, in Lisp, carries its type information at runtime.

ben509 7y ago
> The syntax has a lot less noise. Note here how you unconsciously use "has" instead of "have", that kind of grammatical noise exists because those small redundancies help us understand each other. I think the reason very few computer languages use parens is because they're harder to read by virtue of having less grammatical redundancy. (At the other end of the spectrum, languages like COBOL are hard to read because they're swamped in redundancy.) > So no, "anything" can't go anywhere, because a type mismatch will cause a runtime error. I should have been clearer: it can go anywhere while you're writing it, so you have to run it to find out. That's the problem people also have with other dynamic languages when they're working on non-trivial codebases. Also, because types are rarely declared up front, you're often paging through code to figure out what type should go some place. > And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either. I agree that's an amazing feature few langauges have been able to copy, but it seems like it wasn't enough.