9 ms·

I do not understand the appeal of LISPy languages. I get that the parser is simple and elegant, but I believe the developer (of the compiler in this case) shoul

I do not understand the appeal of LISPy languages. I get that the parser is simple and elegant, 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 cumbersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add that extra complexity into the parser than have me stare down these endless paretheses. Parsing something C-like is not that, hard, trust me, I've done it

n4ture 2y 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 2y ago
  <3
- NewsaHackO 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
        As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup
      - bmacho 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
        [dead]
    - GoblinSlayer 2y 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 2y ago
    [dead]
- Guvante 2y 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 2y 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 2y 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 2y 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 2y 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__ 2y ago
    It's not an exact repeat.
    - vfclists 2y 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 2y 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. )
vbezhenar 2y ago
The unmatched beauty of the Lisp is the elegance of writing code generators (macros). Code is list and main structure is list. This is genius.
- fuzztester 2y ago
  It's called https://en.m.wikipedia.org/wiki/Homoiconicity https://en.m.wikipedia.org/wiki/Homoiconicity
skavi 2y ago
i have never used a lisp, but i’d assume due to its focus on macros, you are alternately the developer of a compiler and the user of that compiler. so making it easy on the compiler dev makes it easy on you.
Zambyte 2y ago
Are you interested in learning the appeal?
endgame 2y ago
Focusing on the runtime's parser is a red herring and I think a common error in lisp advocacy. Even if I didn't the full power of a lisp macro system, it is an absolute joy to manipulate programs written in s-expressions. Being able to cut/copy/paste/jump-[forward/back] by sexpr is really convenient, and often done nowhere near as well in other languages. I think this is because until the invention of tree-sitter and LSPs (and the former isn't yet widely adopted in editor tech), most editors had regex-based syntax highlighting and some kind of ad-hoc "parser" for a language. This makes them less aware of the language the developer is editing, but was probably a pragmatic design decision by editor implementers: it's easier than writing a full parser and means the editor can still assist even if a program is syntactically ill-formed.
- torginus 2y ago
  It does sound interesting, and I'll look into Lisp, can you give me some advice on what's the best way to learn it? On your other point, I've programmed in many languages in many years, and mostly I did some in an environment with an IDE, or powerful language-specific tooling (not tree-sitter) that had a proper good understanding of the syntax and semantics of the language used.
  - eager_learner 2y ago
    A good text to make you aware of the power of Lisp is "The Anatomy of Lisp" by John Allen (MIT). It's an old text but they don't write books like that anymore.
  - Zambyte 2y ago
    If you learn better by video than by reading, the Structure and Interpretation of Computer Programs lectures by Abelson and Sussman are spectacular. I have watched the entire course multiple times. The SICP book also receives a lot of praise, but I have yet to read it myself. They specifically use Scheme, but most of the knowledge can be translated to other Lisp dialects as well. The biggest difference between the different Lisp dialects are the macro systems and the standard libraries, so getting started and learning it doesn't really matter which one you choose. GNU Guile or Racket would be easy to use to follow along with SICP though.
yuppiemephisto 2y ago
> I’d rather have the language … check out Lean 4 then. Its syntax system is based on Racket but —instead of parens— implements stuff like [JSX syntax](https://github.com/leanprover-community/ProofWidgets4/blob/d5230b84587659f474a3d3cff68b8e8d9ad3ba5b/ProofWidgets/Data/Html.lean https://github.com/leanprover-community/ProofWidgets4/blob/d...) and a [maze](https://github.com/dwrensha/lean4-maze https://github.com/dwrensha/lean4-maze)
unchar1 2y ago
The first thing that comes to mind is macros.
deleted 2y ago
[deleted]
chongli 2y ago
The appeal can be seen with paredit-style [1] editor plugins. They give you the power of working on trees rather than text. When you master the paredit way of editing you’ll wish you could do that with every language. [1] https://paredit.org/ https://paredit.org/
caddzooks 2y ago
Consider the following LISP function that performs a transformation of an MxN matrix: (defun transpose (matrix) (apply #'mapcar #'list matrix)) Based on my own experience I think I can say that It isn't until one has acquired a reasonable amount of experience with the language that they can fully appreciate its power.
- satvikpendem 2y ago
  Now try it with BQN
evdubs 2y ago
Try defining data in C. Try extracting data from that data you've defined in C. If you can understand the appeal of having JSON in JavaScript, you can understand some of the appeal of Lisp.
- Vegenoid 2y ago
  I’m having trouble understanding what you mean, if you could provide or link to an example I’d appreciate it.
  - evdubs 2y ago
    Sure. Here's a comment with more of an explanation: https://news.ycombinator.com/item?id=36158974 https://news.ycombinator.com/item?id=36158974
    - GoblinSlayer 2y ago
      How does it know "1970-01-01" is a date?
      - evdubs 2y ago
        It wouldn't. The consumer would need to know to expect a date as a string and parse it.
    - Vegenoid 2y ago
      I feel like I must be missing something, because I don’t understand why representing data in an s-expression is better than representing it as nested arrays (lists of lists) and hashtables/dictionaries. I also don’t see why representing data in a language’s data structure is inherently better than representing it in a language-agnostic format like JSON, and having libraries to parse and convert data from that format into a language data structure, or a library that defines a JSON type, or storing the JSON in a string and using a library that operates on strings that contains valid JSON. I’ve worked with data in this way (JSON on disk, converted to nested arrays/tables in code) and haven’t felt it to be painful. I can see how one might have a taste preference for it, but I’m struggling to understand what the tangible benefits are.
shakna 2y ago
Most Lisp-y language have multiple parsers. The frontend may be that one, or it might be another. Racket has hundreds of frontends [2], Scheme has Wisp [0], and so on. The ideal part of it comes down to the language being able to manipulate itself. Make the tokens an array, that you can shift, inject and/or mould into what you need. That being said, that power isn't isolated to just Lisp-y. A few stack languages have it, like Forth, or to plug myself [1]. However, stack languages are a bit harder to optimise. It isn't that they don't want a complicated parser. It's that you want to be able to easily modify that parser as its running, without hitting TeX levels of performance slowdowns. [0] https://srfi.schemers.org/srfi-119/srfi-119.html https://srfi.schemers.org/srfi-119/srfi-119.html [1] https://git.sr.ht/~shakna/jstack https://git.sr.ht/~shakna/jstack [2] https://doi.org/10.1145/3580417 https://doi.org/10.1145/3580417
nimih 2y ago
I personally find lisp-y syntax to be pleasant to write, and to generally be straightforward and easy to read. It's interesting to hear you have the opposite opinion, though.
mmcromp 2y ago
I tried fennel for a game jam and honestly was pretty disappointed. The way lisp languages are pitched here, I thought I was in for a mind opening experience, but instead the end experience was pretty much identical to lua in ever meaningful way, the only differences felt surface level (I.e. using closures, and parentheses). I'm forever indebt to lisp for giving JS it's saving graces (closures and FN as first class citizens), but I think we some honestly on what the end experience really is.
- fredrikholm 2y ago
  Did you program against a REPL connected to your game, with state maintaining hot reload? Does your editor support working with s-expressions (eg. slurping and barfing)? Batch processing style programming (write to file, save, run, stop, repeat) in Lisp removes some 3/4 of what the language(s) offer. It's especially so if one is navigating code by text rather than structure, eg. jump-to-next-word instead of jump-to-next-expression. What is magical about Lisps, esp. the ones that are fully featured in this sense (Common Lisp, Clojure), is that you're programming a running program without losing state when you re-evaluate code. That is magic. Instead of doing the save-compile-run-setup-conditions-wait-for-result-repeat hundreds of times per session, you run and write the code for your given problem when it arises during gameplay. On top of that you throw on things like paredit, condition systems and you're and order of magnitude less frustrated and dare I say it, productive, than when you constantly have to churn through constant transitions between the code-in-file and game-in-memory disparity. For games especially, things like test driven development make no sense because state is so insanely tangled. So you either hope for the best, or you program against a live game. I prefer the second option.
- sph 2y ago
  The way to appreciate a Lisp is to use an actual Lisp, not a syntax transpiler for a non-Lispy language. Common Lisp, Racket or Scheme with a good REPL and editor integration are light years ahead than Fennel which is little more Lua-with-parens.
  - iLemming 2y ago
    > Fennel is little more Lua-with-parens. Totally. And Clojure is Java-with-parens; Janet is C-with-parens; LFE - Erlang-with-parens; Elisp is a Stallman's erotic fantasy, neatly wrapped in parens. Only Common Lisp is an "actual Lisp for immortal souls" - the rest is for peasants.
dimitar 2y ago
And yet people write a ton of XML, JSON or YAML by hand.
deleted 2y ago
[deleted]

n4ture 2y 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 2y ago
<3
NewsaHackO 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
      As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup
    - bmacho 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
      [dead]
  - GoblinSlayer 2y 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 2y ago
  [dead]
Guvante 2y 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 2y 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 2y 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 2y 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 2y 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__ 2y ago
  It's not an exact repeat.
  - vfclists 2y 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 2y 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. )

vbezhenar 2y ago

The unmatched beauty of the Lisp is the elegance of writing code generators (macros). Code is list and main structure is list. This is genius.

fuzztester 2y ago
It's called https://en.m.wikipedia.org/wiki/Homoiconicity https://en.m.wikipedia.org/wiki/Homoiconicity

skavi 2y ago

i have never used a lisp, but i’d assume due to its focus on macros, you are alternately the developer of a compiler and the user of that compiler. so making it easy on the compiler dev makes it easy on you.

Zambyte 2y ago

Are you interested in learning the appeal?

endgame 2y ago

Focusing on the runtime's parser is a red herring and I think a common error in lisp advocacy. Even if I didn't the full power of a lisp macro system, it is an absolute joy to manipulate programs written in s-expressions. Being able to cut/copy/paste/jump-[forward/back] by sexpr is really convenient, and often done nowhere near as well in other languages. I think this is because until the invention of tree-sitter and LSPs (and the former isn't yet widely adopted in editor tech), most editors had regex-based syntax highlighting and some kind of ad-hoc "parser" for a language. This makes them less aware of the language the developer is editing, but was probably a pragmatic design decision by editor implementers: it's easier than writing a full parser and means the editor can still assist even if a program is syntactically ill-formed.

torginus 2y ago
It does sound interesting, and I'll look into Lisp, can you give me some advice on what's the best way to learn it? On your other point, I've programmed in many languages in many years, and mostly I did some in an environment with an IDE, or powerful language-specific tooling (not tree-sitter) that had a proper good understanding of the syntax and semantics of the language used.
- eager_learner 2y ago
  A good text to make you aware of the power of Lisp is "The Anatomy of Lisp" by John Allen (MIT). It's an old text but they don't write books like that anymore.
- Zambyte 2y ago
  If you learn better by video than by reading, the Structure and Interpretation of Computer Programs lectures by Abelson and Sussman are spectacular. I have watched the entire course multiple times. The SICP book also receives a lot of praise, but I have yet to read it myself. They specifically use Scheme, but most of the knowledge can be translated to other Lisp dialects as well. The biggest difference between the different Lisp dialects are the macro systems and the standard libraries, so getting started and learning it doesn't really matter which one you choose. GNU Guile or Racket would be easy to use to follow along with SICP though.

yuppiemephisto 2y ago

> I’d rather have the language … check out Lean 4 then. Its syntax system is based on Racket but —instead of parens— implements stuff like [JSX syntax](https://github.com/leanprover-community/ProofWidgets4/blob/d5230b84587659f474a3d3cff68b8e8d9ad3ba5b/ProofWidgets/Data/Html.lean https://github.com/leanprover-community/ProofWidgets4/blob/d...) and a [maze](https://github.com/dwrensha/lean4-maze https://github.com/dwrensha/lean4-maze)

unchar1 2y ago

The first thing that comes to mind is macros.

deleted 2y ago

[deleted]

chongli 2y ago

The appeal can be seen with paredit-style [1] editor plugins. They give you the power of working on trees rather than text. When you master the paredit way of editing you’ll wish you could do that with every language. [1] https://paredit.org/ https://paredit.org/

caddzooks 2y ago

Consider the following LISP function that performs a transformation of an MxN matrix: (defun transpose (matrix) (apply #'mapcar #'list matrix)) Based on my own experience I think I can say that It isn't until one has acquired a reasonable amount of experience with the language that they can fully appreciate its power.

satvikpendem 2y ago
Now try it with BQN

evdubs 2y ago

Try defining data in C. Try extracting data from that data you've defined in C. If you can understand the appeal of having JSON in JavaScript, you can understand some of the appeal of Lisp.

Vegenoid 2y ago
I’m having trouble understanding what you mean, if you could provide or link to an example I’d appreciate it.
- evdubs 2y ago
  Sure. Here's a comment with more of an explanation: https://news.ycombinator.com/item?id=36158974 https://news.ycombinator.com/item?id=36158974
  - GoblinSlayer 2y ago
    How does it know "1970-01-01" is a date?
    - evdubs 2y ago
      It wouldn't. The consumer would need to know to expect a date as a string and parse it.
  - Vegenoid 2y ago
    I feel like I must be missing something, because I don’t understand why representing data in an s-expression is better than representing it as nested arrays (lists of lists) and hashtables/dictionaries. I also don’t see why representing data in a language’s data structure is inherently better than representing it in a language-agnostic format like JSON, and having libraries to parse and convert data from that format into a language data structure, or a library that defines a JSON type, or storing the JSON in a string and using a library that operates on strings that contains valid JSON. I’ve worked with data in this way (JSON on disk, converted to nested arrays/tables in code) and haven’t felt it to be painful. I can see how one might have a taste preference for it, but I’m struggling to understand what the tangible benefits are.

shakna 2y ago

Most Lisp-y language have multiple parsers. The frontend may be that one, or it might be another. Racket has hundreds of frontends [2], Scheme has Wisp [0], and so on. The ideal part of it comes down to the language being able to manipulate itself. Make the tokens an array, that you can shift, inject and/or mould into what you need. That being said, that power isn't isolated to just Lisp-y. A few stack languages have it, like Forth, or to plug myself [1]. However, stack languages are a bit harder to optimise. It isn't that they don't want a complicated parser. It's that you want to be able to easily modify that parser as its running, without hitting TeX levels of performance slowdowns. [0] https://srfi.schemers.org/srfi-119/srfi-119.html https://srfi.schemers.org/srfi-119/srfi-119.html [1] https://git.sr.ht/~shakna/jstack https://git.sr.ht/~shakna/jstack [2] https://doi.org/10.1145/3580417 https://doi.org/10.1145/3580417

nimih 2y ago

I personally find lisp-y syntax to be pleasant to write, and to generally be straightforward and easy to read. It's interesting to hear you have the opposite opinion, though.

mmcromp 2y ago

I tried fennel for a game jam and honestly was pretty disappointed. The way lisp languages are pitched here, I thought I was in for a mind opening experience, but instead the end experience was pretty much identical to lua in ever meaningful way, the only differences felt surface level (I.e. using closures, and parentheses). I'm forever indebt to lisp for giving JS it's saving graces (closures and FN as first class citizens), but I think we some honestly on what the end experience really is.

fredrikholm 2y ago
Did you program against a REPL connected to your game, with state maintaining hot reload? Does your editor support working with s-expressions (eg. slurping and barfing)? Batch processing style programming (write to file, save, run, stop, repeat) in Lisp removes some 3/4 of what the language(s) offer. It's especially so if one is navigating code by text rather than structure, eg. jump-to-next-word instead of jump-to-next-expression. What is magical about Lisps, esp. the ones that are fully featured in this sense (Common Lisp, Clojure), is that you're programming a running program without losing state when you re-evaluate code. That is magic. Instead of doing the save-compile-run-setup-conditions-wait-for-result-repeat hundreds of times per session, you run and write the code for your given problem when it arises during gameplay. On top of that you throw on things like paredit, condition systems and you're and order of magnitude less frustrated and dare I say it, productive, than when you constantly have to churn through constant transitions between the code-in-file and game-in-memory disparity. For games especially, things like test driven development make no sense because state is so insanely tangled. So you either hope for the best, or you program against a live game. I prefer the second option.
sph 2y ago
The way to appreciate a Lisp is to use an actual Lisp, not a syntax transpiler for a non-Lispy language. Common Lisp, Racket or Scheme with a good REPL and editor integration are light years ahead than Fennel which is little more Lua-with-parens.
- iLemming 2y ago
  > Fennel is little more Lua-with-parens. Totally. And Clojure is Java-with-parens; Janet is C-with-parens; LFE - Erlang-with-parens; Elisp is a Stallman's erotic fantasy, neatly wrapped in parens. Only Common Lisp is an "actual Lisp for immortal souls" - the rest is for peasants.

dimitar 2y ago

And yet people write a ton of XML, JSON or YAML by hand.

deleted 2y ago

[deleted]