7 ms·

Processing parentheses is still parsing. It's kindergarten-level parsing, but it's still parsing. I've written thousands of lines of scheme code preprocessed t

Processing parentheses is still parsing. It's kindergarten-level parsing, but it's still parsing. I've written thousands of lines of scheme code preprocessed to eliminate most parenthesis. I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses, which is so far from the point of Lisp. With modern editor "language server" support and syntax coloring, languages can shape-shift to any appearance they want, separate from meaning. While I love the poetic look of parenthesis-spare Lisp, Bill Joy got it right when he said that code density on a screen affects programmer productivity. I love Haskell, both for this and because one reasons about the activity of programming as if one is doing algebra. While Lisp more easily modifies itself than any other language, macros are bolted on. No one can tell me with a straight face that with a thousand runs of the civilization simulation, our Lisp macros would be the best run. I'd love to see a language where manipulating the language is the core strength, and all ease with data structures follows as a consequence. Lisp is not that language; peek into some of the other simulation runs.

lmilcin 5y ago
> I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses, which is so far from the point of Lisp. I think the reason Lisp self-asphyxiated is because people don't get it. Most try to spend a little bit time programming it as if it was C/Java/Python/whetever else they have used on their last project. They just see a language that can do what they need but it is all wonky and so why bother? Compared to other languages, to get benefits from using Lisp you actually need to understand what the benefits are and what causes the benefits. You can switch from C to Python and reap benefits of Python without having some kind of deep understanding. That's because programming in Python is basically same thing as programming in C, it is just more efficient. There is less stuff to set up (unless you run into compatibility problems), less stuff take care for (begone pesky pointers and memory allocation!) and better API to do repeatable tasks. On the other hand programming in Lisp is different than every other language. But you also can program as if you were programming any other language. So you get confused about what makes Lisp different and if you don't stick it out you might think you just learned Lisp and "what is all teh fuss about?" I think getting from regular programming to Lisp should be presented as same step change as going from not programming to programming. Person who has never programmed and never heard about programming might have a lot of trouble understanding why you would even want to program (in the end it is just adding numbers -- why would that accomplish anything, I am not an accountant?)
- Guthur 5y ago
  For me it's that lisp just sets up the language to be so easily used at multiple levels of abstraction, which is all at once a truism by also not nearly enough to communicate what it is like to use. At this stage there are likely many languages that will allow you to work at similar number of abstractions including syntax, but I'd be surprised if many feel so much like idiomatic code. Implementing macros has some constraints but it's quite possible to internalise and start writing s-exp manipulating code as if it was just any standard problem.
  - lmilcin 5y ago
    That is a good point. To be able to utilize Lisp well you need to be able to structure your application, but you would need already a lot of experience and exposure to well structured applications. Whereas if you are a Java developer you get structure from people who designed Spring and now this is how you fill in controller, this is how you make service method, this is how you make your database layer... all these decisions were already made for you and you just need to follow to get a passable result. Freedom is a double-edged sword. If you don't know how to use it it may very well be worse than not having it in the first place.
- q-big 5y ago
  > That's because programming in Python is basically same thing as programming in C, it is just more efficient. You likely got this illusion because from beginning on, you actually programmed in C in a very "Pythonic" way.
  - lmilcin 5y ago
    Actually, I learned by programming assembly for a long gone platform, 25 years ago. I have learned Python already after many years programming in C, Perl, Java and Common Lisp, professionally. Experience with Lisp gave me a certain way of looking at programming languages. Rather than "oh, how fun!", I am more like "let's see which subset of Lisp it implements". The only really interesting language in recent years that I have learned is Rust which truly does something new and it recalibrated my thinking about utility of making further subsets of Lisps. It seems there is still a lot of possibility for improvement from the language standpoint, and that it is possible that a lot of improvement may come from restricting the developer from doing certain things rather than giving unrestricted freedom.
deleted 5y ago
[deleted]
amw-zero 5y ago
With a straight face - how can you do anything better than macros in Lisp? I’ve always thought of them as the Platonic ideal of macros. What are your problems with them?
- didibus 5y ago
  The only thing I've seen compete is Rebol like languages and their concept of dialects.
- zelphirkalt 5y ago
  Perhaps not better, but different and yet on the same "power level": Smalltalk metaprogramming. Other than that, I am not sure anything more powerful is possible inside a classical computer.
rscho 5y ago
Macros are bolted on in Lisp!? Ok, can you expand a bit on what a language with (syntactic) macros at its core would be like, please?
blacktriangle 5y ago
The parenthesis issue is one that I simply cannot grasp, but have to acknowledge as true simply because so many programmers have voiced it. As far as I can tell there is no correlation between who has an issue with them and who does not. New programmers vs experienced, young vs old, bad vs good, it does not matter. Some programmers love them and for others they are a show stopper. For me, until you demonstrate the same level of structural editing support and powerful macro system without S-expressions, you can pry my parenthesis from my cold dead hands.
- taeric 5y ago
  I think it is only true because so many insist it is true. Same reason python is "easy for beginners.". So much propaganda insists it that folks believe it must be so. Note, my hypothesis is essentially any language that folks insisted is easy for beginners could be easier. There is a certain difficulty that comes from thinking something must be difficult.
  - pierrebai 5y ago
    Portraying widely held opinions as propaganda is quite counter-productive, bordering on denial. Given that you provide no reasoning one way or another, I cannot say more about your personal views, but... Denying Python's simplicity is surprising. Clarity of syntax, avoiding superfluous tokens, and ordering of code in speak-order are a few of the reason for it's simplicity. Interestingly, Python fails at syntax clarity exactly where it adopts functional-style construct: list-comprehension for example. Like it or not, a language, like Lisp, which insist on polish notation is just unnatural, at least for most western speakers. (I don't know any spoken language that would map to placing verbs first in a sentence.)
    - anaerobicover 5y ago
      > (I don't know any spoken language that would map to placing verbs first in a sentence.) There are some less spoken, and some more widely spoken languages have this as an optional possibility. Verb-Subject-Object order: https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93object https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93o...
taeric 5y ago
I think the point is that you don't have to parse from strings. Instead, you can parse the atoms of the lists. I'm large, it comes down to what data type eval takes in. In most languages that have an eval, they take in strings. In lisp, it takes in a list of code.
snicker7 5y ago
> I'd love to see a language where manipulating the language is the core strength, This is the appeal of Julia, where the community uses macros to do things like auto-differentiation (which itself feeds into modeling engines), create domain-specific languages, and to customize compiler behavior (auto-vectorization, target GPU compute shaders).
minhm 5y ago
> macros are bolted on As I understand it, macro is at a metalanguage level above the current code (eg. C macros vs C "normal" codes). In lisp, this metalanguage is in lisp forms, and thus it is parsed by ... the very same lisp parser for the code. Therefore the whole language is available to you at this meta level, and for all the meta levels above this meta level (ie. for macros that build other macros), so it's lisp all the way up. I am not sure why you see it as "bolted-on".
- Izkata 5y ago
  I only know Lisp at a really basic introductory level, but knowing a different homoiconic language my understanding was that "macros" aren't even actually a meta-level thing in these - it's just the language being able to manipulate itself. Using it like this just gets called "meta-level" or "macros" to keep a cleaner separation for developers to reason about.
- dragonwriter 5y ago
  It feels more bolted on than in, say, REBOL, where there aren’t separate macros because functions can selectively take any or all of their arguments unevaluated, as a value but not fully evaluated, or fully evaluated. (Which isn’t to say the Lisp way is worse; there’s strengths and weaknesses of both.)
imode 5y ago
What do you mean by "manipulating the language"?
didibus 5y ago
I'm not sure I follow your point? Do you mean Lisp should evolve its syntax and try to find a representation that doesn't need so many parenthesis?
- fzzzy 5y ago
  The amazing thing about this is that M Expressions were proposed in 1960, but never implemented.
bsder 5y ago
> Processing parentheses is still parsing. Processing parentheses is straightforward. Parsing a DOT is a nightmare. Anybody who says Lisp doesn't have syntax has never parsed CONS-pairs properly.
bsder 5y ago
> I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses Lisp self-asphyxiated because the teaching materials were garbage^W poorly focused for normal programmers from 1985-1995. Stupidly useful things like "Hash Tables" and "Imperative Linear Loops" were always sort of an afterthought/footnote in Lisp books as opposed to "Recursion and Y-combinator" which were 70%+ of the books and 90+% useless to daily programming. Perl stood up and said "Regexs and Hashes are important, useful on a daily basis, and easy to use." And consequently wiped the floor of the non-systems programming community until Python.

lmilcin 5y ago

> I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses, which is so far from the point of Lisp. I think the reason Lisp self-asphyxiated is because people don't get it. Most try to spend a little bit time programming it as if it was C/Java/Python/whetever else they have used on their last project. They just see a language that can do what they need but it is all wonky and so why bother? Compared to other languages, to get benefits from using Lisp you actually need to understand what the benefits are and what causes the benefits. You can switch from C to Python and reap benefits of Python without having some kind of deep understanding. That's because programming in Python is basically same thing as programming in C, it is just more efficient. There is less stuff to set up (unless you run into compatibility problems), less stuff take care for (begone pesky pointers and memory allocation!) and better API to do repeatable tasks. On the other hand programming in Lisp is different than every other language. But you also can program as if you were programming any other language. So you get confused about what makes Lisp different and if you don't stick it out you might think you just learned Lisp and "what is all teh fuss about?" I think getting from regular programming to Lisp should be presented as same step change as going from not programming to programming. Person who has never programmed and never heard about programming might have a lot of trouble understanding why you would even want to program (in the end it is just adding numbers -- why would that accomplish anything, I am not an accountant?)

Guthur 5y ago
For me it's that lisp just sets up the language to be so easily used at multiple levels of abstraction, which is all at once a truism by also not nearly enough to communicate what it is like to use. At this stage there are likely many languages that will allow you to work at similar number of abstractions including syntax, but I'd be surprised if many feel so much like idiomatic code. Implementing macros has some constraints but it's quite possible to internalise and start writing s-exp manipulating code as if it was just any standard problem.
- lmilcin 5y ago
  That is a good point. To be able to utilize Lisp well you need to be able to structure your application, but you would need already a lot of experience and exposure to well structured applications. Whereas if you are a Java developer you get structure from people who designed Spring and now this is how you fill in controller, this is how you make service method, this is how you make your database layer... all these decisions were already made for you and you just need to follow to get a passable result. Freedom is a double-edged sword. If you don't know how to use it it may very well be worse than not having it in the first place.
q-big 5y ago
> That's because programming in Python is basically same thing as programming in C, it is just more efficient. You likely got this illusion because from beginning on, you actually programmed in C in a very "Pythonic" way.
- lmilcin 5y ago
  Actually, I learned by programming assembly for a long gone platform, 25 years ago. I have learned Python already after many years programming in C, Perl, Java and Common Lisp, professionally. Experience with Lisp gave me a certain way of looking at programming languages. Rather than "oh, how fun!", I am more like "let's see which subset of Lisp it implements". The only really interesting language in recent years that I have learned is Rust which truly does something new and it recalibrated my thinking about utility of making further subsets of Lisps. It seems there is still a lot of possibility for improvement from the language standpoint, and that it is possible that a lot of improvement may come from restricting the developer from doing certain things rather than giving unrestricted freedom.

deleted 5y ago

[deleted]

amw-zero 5y ago

With a straight face - how can you do anything better than macros in Lisp? I’ve always thought of them as the Platonic ideal of macros. What are your problems with them?

didibus 5y ago
The only thing I've seen compete is Rebol like languages and their concept of dialects.
zelphirkalt 5y ago
Perhaps not better, but different and yet on the same "power level": Smalltalk metaprogramming. Other than that, I am not sure anything more powerful is possible inside a classical computer.

rscho 5y ago

Macros are bolted on in Lisp!? Ok, can you expand a bit on what a language with (syntactic) macros at its core would be like, please?

blacktriangle 5y ago

The parenthesis issue is one that I simply cannot grasp, but have to acknowledge as true simply because so many programmers have voiced it. As far as I can tell there is no correlation between who has an issue with them and who does not. New programmers vs experienced, young vs old, bad vs good, it does not matter. Some programmers love them and for others they are a show stopper. For me, until you demonstrate the same level of structural editing support and powerful macro system without S-expressions, you can pry my parenthesis from my cold dead hands.

taeric 5y ago
I think it is only true because so many insist it is true. Same reason python is "easy for beginners.". So much propaganda insists it that folks believe it must be so. Note, my hypothesis is essentially any language that folks insisted is easy for beginners could be easier. There is a certain difficulty that comes from thinking something must be difficult.
- pierrebai 5y ago
  Portraying widely held opinions as propaganda is quite counter-productive, bordering on denial. Given that you provide no reasoning one way or another, I cannot say more about your personal views, but... Denying Python's simplicity is surprising. Clarity of syntax, avoiding superfluous tokens, and ordering of code in speak-order are a few of the reason for it's simplicity. Interestingly, Python fails at syntax clarity exactly where it adopts functional-style construct: list-comprehension for example. Like it or not, a language, like Lisp, which insist on polish notation is just unnatural, at least for most western speakers. (I don't know any spoken language that would map to placing verbs first in a sentence.)
  - anaerobicover 5y ago
    > (I don't know any spoken language that would map to placing verbs first in a sentence.) There are some less spoken, and some more widely spoken languages have this as an optional possibility. Verb-Subject-Object order: https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93object https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93o...

taeric 5y ago

I think the point is that you don't have to parse from strings. Instead, you can parse the atoms of the lists. I'm large, it comes down to what data type eval takes in. In most languages that have an eval, they take in strings. In lisp, it takes in a list of code.

snicker7 5y ago

> I'd love to see a language where manipulating the language is the core strength, This is the appeal of Julia, where the community uses macros to do things like auto-differentiation (which itself feeds into modeling engines), create domain-specific languages, and to customize compiler behavior (auto-vectorization, target GPU compute shaders).

minhm 5y ago

> macros are bolted on As I understand it, macro is at a metalanguage level above the current code (eg. C macros vs C "normal" codes). In lisp, this metalanguage is in lisp forms, and thus it is parsed by ... the very same lisp parser for the code. Therefore the whole language is available to you at this meta level, and for all the meta levels above this meta level (ie. for macros that build other macros), so it's lisp all the way up. I am not sure why you see it as "bolted-on".

Izkata 5y ago
I only know Lisp at a really basic introductory level, but knowing a different homoiconic language my understanding was that "macros" aren't even actually a meta-level thing in these - it's just the language being able to manipulate itself. Using it like this just gets called "meta-level" or "macros" to keep a cleaner separation for developers to reason about.
dragonwriter 5y ago
It feels more bolted on than in, say, REBOL, where there aren’t separate macros because functions can selectively take any or all of their arguments unevaluated, as a value but not fully evaluated, or fully evaluated. (Which isn’t to say the Lisp way is worse; there’s strengths and weaknesses of both.)

imode 5y ago

What do you mean by "manipulating the language"?

didibus 5y ago

I'm not sure I follow your point? Do you mean Lisp should evolve its syntax and try to find a representation that doesn't need so many parenthesis?

fzzzy 5y ago
The amazing thing about this is that M Expressions were proposed in 1960, but never implemented.

bsder 5y ago

> Processing parentheses is still parsing. Processing parentheses is straightforward. Parsing a DOT is a nightmare. Anybody who says Lisp doesn't have syntax has never parsed CONS-pairs properly.

bsder 5y ago

> I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses Lisp self-asphyxiated because the teaching materials were garbage^W poorly focused for normal programmers from 1985-1995. Stupidly useful things like "Hash Tables" and "Imperative Linear Loops" were always sort of an afterthought/footnote in Lisp books as opposed to "Recursion and Y-combinator" which were 70%+ of the books and 90+% useless to daily programming. Perl stood up and said "Regexs and Hashes are important, useful on a daily basis, and easy to use." And consequently wiped the floor of the non-systems programming community until Python.