6 ms·

I do not understand the appeal of non-LISPy languages. I get that most people are used to reading it and that they are efficent, but I believe the developer (of

by n4ture 1y ago

I do not understand the appeal of non-LISPy languages. I get that most people are used to reading it and that they are efficent, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around. Writing code like this is combersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add those extra parens into the parser than have me stare down these endless semi-colon, linebreaks or indentation. Parsing something Lisp-like is not that, hard, trust me, I've done it.

mgdev 1y ago
<3
NewsaHackO 1y ago
This doesn't really resonate with people though, as most people are more familiar with C-style notation. Also: >Writing code like this is combersome and unnecessarily symbol heavy Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.
- n4ture 1y ago
  Yeah was going to change that part too for something like "Writing code like this is verbose and spans too many lines", but then I just thought it'd be better if it sounded more like the parent comment. And I understand it doesn't resonate with most, I just wanted to highlight how the initial parent comment was very subjective and not very substantive, some people didn't take the joke so well, I guess it could've sounded a bit passive aggressive. I personally enjoy both C-like and Lisp-like syntaxes and languages, I do have a sweet spot for Forth tho. But back on topic, Fennel is a great language, working with Love and Fennel is really nice. And if the parentheses can seem off-putting for some, I'd highly encourage to give it a shot as you can quickly get past it and see how comfy it feels to have your statements properly demarkated. S-expr shine the most when working with XML-like structure. Spinneret[1] was the most fun I ever had working with HTML, every other templating engine feels subpar now that I have tasted that sweet nectar.. [1] https://github.com/ruricolist/spinneret https://github.com/ruricolist/spinneret
  - pertymcpert 1y ago
    It's your comment that seems to add the least, because the majority agree with the OP. The point is that ergonomics is not as good, of course there are contrary opinions. The existence of a contrary and minority opinion doesn't detract from the point.
- fuzztester 1y ago
  >Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily. I had read, some years back, that someone did an actual calculation / demonstration that showed that the number of symbol / punctuation characters in Lisp is actually less than in C-based languages, for a block of code with equal functionality in both languages. I don't have the reference handy. Someone here may know of it, and post it.
  - Zambyte 1y ago
    It's obvious to anyone who is familiar with both. (f x y) vs f(x, y); Note the extra comma and semicolon. The only place this breaks down is for simple arithmetic expressions like (+ a b) vs a + b, which is trivial enough to ignore (and also goes back in favor of Lisp when you start having more operands).
    - packetlost 1y ago
      As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup
    - bmacho 1y ago
      It is only function calling that needs (,); in C and () in Lisp. Which is half as many characters, but much much much noisy since: - it is used everywhere - carries very little information Look at the example on the Janet page transcribed to Python syntax [0]. Several differences: - in Janet nearly every line starts and ends with ( and ), which is just noise - in Janet there are several )))) - in Janet there is no special syntax for: function definition, variable definition, collections, statements - while Python is the opposite, it reads like a mix of English and Mathematics. Also it has special syntax for the ~5 things that you can do with the language, so you can just look at the Python code from far, don't read it, and you'll have a clue what's going on. It is also helpful when you search for something with your eyes. Also nested parentheses are different shaped parentheses, so you know which ones match. Also in theory you could manipulate Python AST the same way you do in Lisps both in your editor and both at program-level. In practice you can't do that. [0] : https://news.ycombinator.com/item?id=34846516 https://news.ycombinator.com/item?id=34846516
- smnplk 1y ago
  >> as it mainly applies to Lisp-like languages that uses parentheses heavily. This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but I believe other lisps are more or less similar. So if everything can be evaluated, then you can have a really great REPL experience. You can be inside your favorite editor and have the tightest feedback loop possible. So the absence of statements is actually a great feature of the language which improves ergonomics.
  - zelphirkalt 1y ago
    The anti parentheses argument is usually just a straw that people grasp, who have no experience with writing code in lispy languages. A quick superficial jab at something they do not know well, so that they can go on with their day, without having to deal with learning a new thing, that might change their whole view of programming.
    - MonkeyClub 1y ago
      Plus, don't forget the secret sauce of Lisp syntax: same number of parentheses, with none of the commas. Nor the semicolons. Nor the brackets. Nor the braces.
      - smnplk 1y ago
        I can live with brackets and braces tho ;) Clojure <3 But that is a very nice observation that is true for traditional lisps. I need to give racket or scheme one more look.
    - eager_learner 1y ago
      [dead]
  - GoblinSlayer 1y ago
    I just don't understand the fixation with REPL. How do you use it? It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.
- eager_learner 1y ago
  [dead]
Guvante 1y ago
Let's be real in most situations it doesn't matter. One "statement" per line is bog standard. Whether that statement is surrounded by parens or ended in a semicolon isn't impactful for reading. LISP is only better when you add source code transformation (which is way easier with its source code looking like the transformed code). But then you introduce "everyone can write their own syntax" which is good and bad given the history of DSLs...
- zelphirkalt 1y ago
  When writing code you are transforming it all the time. Having only expressions (mostly) comes in very handily. It is called structured editing of code.
- jdminhbg 1y ago
  > One "statement" per line is bog standard This isn't really true. Most non-Lisp languages I work in, like JS or Ruby or Python, have things like long_expression =\n long_other_expression, or long_expression\n.another_long_expression\n.another_long_expression.
  - Guvante 1y ago
    And if most of your code looks like that you are making a mistake. "Sometimes I need multiple lines" is fine, exceptions happen. But again I ask, visually are those lines super different? Ditto for things like for loops which have multiple statements in a line.
vfclists 1y ago
Are n4ture and torginus the same person? Why the exact repeat of the earlier post under a different name or some bots at play here?
- bmn__ 1y ago
  It's not an exact repeat.
  - vfclists 1y ago
    Stop karma whoring!! If it is not suspicious then why has the comment been deleted, causing this comment to rise to the top level?
torginus 1y ago
My understanding is that Lisp and most functional languages map very well to PL theory and how compilers and interpreters manipulate programming languages (functions as graphs of code, types as contracts etc.), while procedural languages map well to how CPUs execute programs, and the abstractions operating systems provide (functions as mappable pieces of memory, types as memory or register layouts etc. )

by n4ture 1y ago

mgdev 1y ago

NewsaHackO 1y ago

This doesn't really resonate with people though, as most people are more familiar with C-style notation. Also: >Writing code like this is combersome and unnecessarily symbol heavy Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.

n4ture 1y ago
Yeah was going to change that part too for something like "Writing code like this is verbose and spans too many lines", but then I just thought it'd be better if it sounded more like the parent comment. And I understand it doesn't resonate with most, I just wanted to highlight how the initial parent comment was very subjective and not very substantive, some people didn't take the joke so well, I guess it could've sounded a bit passive aggressive. I personally enjoy both C-like and Lisp-like syntaxes and languages, I do have a sweet spot for Forth tho. But back on topic, Fennel is a great language, working with Love and Fennel is really nice. And if the parentheses can seem off-putting for some, I'd highly encourage to give it a shot as you can quickly get past it and see how comfy it feels to have your statements properly demarkated. S-expr shine the most when working with XML-like structure. Spinneret[1] was the most fun I ever had working with HTML, every other templating engine feels subpar now that I have tasted that sweet nectar.. [1] https://github.com/ruricolist/spinneret https://github.com/ruricolist/spinneret
- pertymcpert 1y ago
  It's your comment that seems to add the least, because the majority agree with the OP. The point is that ergonomics is not as good, of course there are contrary opinions. The existence of a contrary and minority opinion doesn't detract from the point.
fuzztester 1y ago
>Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily. I had read, some years back, that someone did an actual calculation / demonstration that showed that the number of symbol / punctuation characters in Lisp is actually less than in C-based languages, for a block of code with equal functionality in both languages. I don't have the reference handy. Someone here may know of it, and post it.
- Zambyte 1y ago
  It's obvious to anyone who is familiar with both. (f x y) vs f(x, y); Note the extra comma and semicolon. The only place this breaks down is for simple arithmetic expressions like (+ a b) vs a + b, which is trivial enough to ignore (and also goes back in favor of Lisp when you start having more operands).
  - packetlost 1y ago
    As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup
  - bmacho 1y ago
    It is only function calling that needs (,); in C and () in Lisp. Which is half as many characters, but much much much noisy since: - it is used everywhere - carries very little information Look at the example on the Janet page transcribed to Python syntax [0]. Several differences: - in Janet nearly every line starts and ends with ( and ), which is just noise - in Janet there are several )))) - in Janet there is no special syntax for: function definition, variable definition, collections, statements - while Python is the opposite, it reads like a mix of English and Mathematics. Also it has special syntax for the ~5 things that you can do with the language, so you can just look at the Python code from far, don't read it, and you'll have a clue what's going on. It is also helpful when you search for something with your eyes. Also nested parentheses are different shaped parentheses, so you know which ones match. Also in theory you could manipulate Python AST the same way you do in Lisps both in your editor and both at program-level. In practice you can't do that. [0] : https://news.ycombinator.com/item?id=34846516 https://news.ycombinator.com/item?id=34846516
smnplk 1y ago
>> as it mainly applies to Lisp-like languages that uses parentheses heavily. This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but I believe other lisps are more or less similar. So if everything can be evaluated, then you can have a really great REPL experience. You can be inside your favorite editor and have the tightest feedback loop possible. So the absence of statements is actually a great feature of the language which improves ergonomics.
- zelphirkalt 1y ago
  The anti parentheses argument is usually just a straw that people grasp, who have no experience with writing code in lispy languages. A quick superficial jab at something they do not know well, so that they can go on with their day, without having to deal with learning a new thing, that might change their whole view of programming.
  - MonkeyClub 1y ago
    Plus, don't forget the secret sauce of Lisp syntax: same number of parentheses, with none of the commas. Nor the semicolons. Nor the brackets. Nor the braces.
    - smnplk 1y ago
      I can live with brackets and braces tho ;) Clojure <3 But that is a very nice observation that is true for traditional lisps. I need to give racket or scheme one more look.
  - eager_learner 1y ago
    [dead]
- GoblinSlayer 1y ago
  I just don't understand the fixation with REPL. How do you use it? It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.
eager_learner 1y ago
[dead]

Guvante 1y ago

Let's be real in most situations it doesn't matter. One "statement" per line is bog standard. Whether that statement is surrounded by parens or ended in a semicolon isn't impactful for reading. LISP is only better when you add source code transformation (which is way easier with its source code looking like the transformed code). But then you introduce "everyone can write their own syntax" which is good and bad given the history of DSLs...

zelphirkalt 1y ago
When writing code you are transforming it all the time. Having only expressions (mostly) comes in very handily. It is called structured editing of code.
jdminhbg 1y ago
> One "statement" per line is bog standard This isn't really true. Most non-Lisp languages I work in, like JS or Ruby or Python, have things like long_expression =\n long_other_expression, or long_expression\n.another_long_expression\n.another_long_expression.
- Guvante 1y ago
  And if most of your code looks like that you are making a mistake. "Sometimes I need multiple lines" is fine, exceptions happen. But again I ask, visually are those lines super different? Ditto for things like for loops which have multiple statements in a line.

vfclists 1y ago

Are n4ture and torginus the same person? Why the exact repeat of the earlier post under a different name or some bots at play here?

bmn__ 1y ago
It's not an exact repeat.
- vfclists 1y ago
  Stop karma whoring!! If it is not suspicious then why has the comment been deleted, causing this comment to rise to the top level?

torginus 1y ago

My understanding is that Lisp and most functional languages map very well to PL theory and how compilers and interpreters manipulate programming languages (functions as graphs of code, types as contracts etc.), while procedural languages map well to how CPUs execute programs, and the abstractions operating systems provide (functions as mappable pieces of memory, types as memory or register layouts etc. )