5 ms·

I went there, saw the Lisp syntax, and noped back out.

by mike_hock 4y ago

dunefox 4y ago
Your loss.
co_dh 4y ago
Me too
malodyets 4y ago
Nope as a verb is new to me - just heard it for the second time this week. First time was from my child.
- adrusi 4y ago
  It's somewhat youthful internet slang. You'd hear it at the American public highschool I was at 12 years ago.
sergiotapia 4y ago
Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.
- nnadams 4y ago
  I've been using Lisp for hobby projects for a few years. Yes the syntax takes some time, but > I feel like if I used it, it would atrophy my skills in other more traditional languages. was not the case for me at all. If you go into a text editor and remove all the parentheses, I find that's how Lisp programmers tend to see Lisp, (function argument) isn't that far from function(argument). Learning Lisp has only improved my skills as a programmer, after getting ideas like code as data, macros, let over lambda, CLOS and the metaobject protocol. It's a simple model that to me shows how other languages have picked an abstraction and stuck with it, but Lisp has all the tools to implement those abstractions and more. More mainstream languages are great at focusing the developer, and that makes them very practical. It is amusing though to watch many of the "new features" in languages come out even though Lisp had them years ago.
  - asyd 4y ago
    Reading Peter Norvig's PAIP (https://github.com/norvig/paip-lisp https://github.com/norvig/paip-lisp) in 1998 totally blew my mind. It completely changed how I think about programming in every other language I use(d). I love it still, and always will. And yes, my experience is the same as yours: learning lisp made me a better programmer in every other language I use (especially -- but not only -- Python). The simplicity and symmetry of the syntax is a big part of that love for me. Being able to manipulate lisp code as lisp data, using the full power of the language to do so, is just brilliant. Janet looks lovely! Looking forward to the book.
- mypetocean 4y ago
  The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle](https://en.wikipedia.org/wiki/Mere-exposure_effect https://en.wikipedia.org/wiki/Mere-exposure_effect)). I've never used a Lisp-family language, but I find the reaction against parentheses to be overblown. The reading order of the code is also _consistent,_ rather than the frequent switching between infix notation, prefix notation, and postfix notation which we have to learn and parse in most languages outside the Lisp family. This is a benefit which deceptively looks like it is _more_ complicated, despite being simpler to parse visually (and otherwise). Another example of the familiarity principle at work.
  - mypetocean 4y ago
    Oh, I guess Markdown doesn't work. Huh. Well, shoot.
    - tmtvl 4y ago
      HN comment formatting options can be found here: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
  - tremon 4y ago
    The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. This tired trope needs to die. Yes, there are more parentheses, because lisp also uses parentheses where other languages use [] or {} or ;. The real thing is that people from C-like languages are used to seeing different block markers for different constructs. It takes effort to read Lisp coming from other languages, because those other languages have a richer symbol vocabulary. Learning to read code without those symbols is like reading English where all punctuation has been replaced with a single space. Sure you ll get there eventually but it s a very cheap straw man argument to pretend that the only complaint people have about Lisps is the positioning of the parentheses.
- camdez 4y ago
  I certainly don't fault you for having that reaction, but I would encourage you to look deeper and not dismiss one of the most interesting families of programming languages on the basis that it looks weird. Far from atrophying your skills in other languages, many people say that learning Lisp makes them better programmers even when they're coding in other languages. Lisps don't arbitrarily look weird—there's a deep, principled, elegant reason for it; Lisp code represents how the code will be evaluated in the most direct way, without relying on (some would say needlessly) complex parsing / precedence rules. There are no surprises and no arbitrary rules to learn. There are no useless semicolons to forget, and you'll never have to wonder if `+=` returns the RHS or the result of the operation (or does it even have a return value?). You don't have this meaningless distinction where you can't directly reduce with `+` because—ugh—it's not a function, it's an operator. You just say `(reduce + [1 2 3])`. You never have to do this ugly Ruby stuff... words.map &:length # or words.map { |w| w.length } ...because methods are really just polymorphic functions, but language designers chose syntax that doesn't compose elegantly. You don't have this useless distinction between statements and expressions that limits how you can compose code. You never have to drop down to some ugly, limited tertiary expression form (`COND ? X : Y`) of `if` because—whoops—`if` is a "statement". You just write: (println (if me? "me" "you")) Because, duh, we wanted an `if`. What do we gain by adding all of this noise?: if (is_me) { println("me"); } else { println("you"); } Absolutely nothing. The parens on the conditional, the curly braces, the semicolons, the `else` keyword—they're essentially meaningless incantations to appease the compiler. And we've introduced an undesirable opportunity for the two branches to accidentally diverge over time. But most importantly, our code is written in the data structures of our language. Code as data means we can manipulate code as easily as we manipulate data, which means we can trivially (re-)write code with code (i.e. macros). And not shitty string generating macros, or macros that can only do a handful of sanctioned things—we can write our own control structures in couple lines of code. We can add new abstractions to the programming language from user space. Wish the language had an `if-not` construct? You can add it with, like, 3 lines of code. Wish functions could have optional parameters? Add it. Wish it had a pattern matching functions like SML or Erlang? Cool. Java-style annotations? Logging that is fully removed when running in high performance mode? A different OO model? Multi-line string literals? String interpolation? A graph of dependent calculations that only get run when used? A more convenient way to load dependencies? It's all easily doable. I've coded in Lisps (and a dozen other languages) for at least 20 years, and every time I have to use a non-Lisp syntax I just think "wow, these people really missed the boat". It's like having to write math in Roman numerals (would you rather calculate "D + L + IX" or "500 + 50 + 9"?); there's a better way, and that better way has elegant, recursive, underlying design principles that make the ergonomics way better. But, yeah, it doesn't look like C code. And people seem to be really attached to their C syntax.
- eggy 4y ago
  Quite the opposite. Learning a Lisp or an Array language will build your skills and make you a better programmer. Syntax should fade as a criteria as you become proficient in various PLs. For example, the sum of a list (not running or cumulative sum, but total sum. Should equal 10, not 1, 3, 6, 10): Lisp: (+ 1 2 3 4) J/APL[0]: +/1 2 3 4 Python: Sum = sum([1,2,3,4]) print(Sum) They all do the same. I prefer the conciseness of J/APL and Lisp in this case, and the application of a function over the list or vector. The beauty of the REPL is that you see the result without a 'print' statement. Solving problems in these other languages will influence how you program in your base language as well, and usually for the better. I am also guilty of syntax bias. I prefer LFE (Lisp Flavoured Erlang)[3] over Elixir and Gleam. Gleam[1], another language that runs on the Erlang VM (BEAM), had a more ML syntax, but then it chose to join the syntax popularity contest and move to a more Algol/C/Rust syntax. I prefer vanilla Erlang over it too. [0] https://www.jsoftware.com/#/ https://www.jsoftware.com/#/ [1] https://gleam.run/ https://gleam.run/ [3] https://lfe.io/ https://lfe.io/
- 59nadir 4y ago
  > I feel like if I used it, it would atrophy my skills in other more traditional languages. If your skills in other languages are tied to a syntax then you never had any skills to begin with. I've used pretty much every syntax (and too many languages) out there and the only difference I've ever found is that ML syntax is nicer for automatically curried functions and LISP syntax is much nicer for meta-programming. The rest is effectively all down to paradigms, runtimes and libraries.
pmoriarty 4y ago
Lisp syntax is a huge plus for me, and if a language doesn't have it I know it's not for me.
camdez 4y ago
Agreed. This is why I don't do any math I can't do on my fingers. Parentheses are just too scary, and there's no way that parenthesis math junk actually has any useful ideas.
- ravi-delia 4y ago
  I understand the reaction, but some people feel just as negatively about parentheses as lispers feel positively. If I can feel positively about a language purely because of the parens, it's no sillier to feel negatively for the same reason.
  - camdez 4y ago
    I actually agree with that entirely, and the point of my jest was just to say that we should look deeper for the important ideas, not refuse to read the book because we don't like the color of the cover. Lispers don't feel positive about Lisp because of parentheses; change them to curly braces or brackets or ^ and $—that's really not what matters. Lisps with brackets go all the way back to the beginning (https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression). Indentation-based Lisps have been done too (https://readable.sourceforge.io/ https://readable.sourceforge.io/). The point is an expression-based syntax that directly models the code tree, is written in the data structures of language, and is convenient for meta-programming. It's a fundamentally different approach that yields massive benefits (see my other comment in the thread if you want to hear that spelled out in more detail). But we don't see that when we just stop at unfamiliar syntax. Lispers have been structurally-editing code as a matter of course since at least 1970. Most of the rest of the world only got a taste of that when tree-sitter came out circa 2018 (I know I'm rounding the edges here, but the point stands). Half a century later! Why is that? It's not just curly braces vs parens—something deeper is happening here. I do apologize if I came off rude. I'm just so frustrated at hearing this same line year after year after year from people who are missing out some of the most powerful ideas in programming because they prefer this ASCII glyph over that one. It's nothing more than parochialism. It just makes me want to scream (perhaps uncharitably) "surely you're not a serious engineer who works on serious problems if your biggest concern while coding is which character is used to group code?!" I want tools to help me think more clearly, ways to operate at higher levels of abstraction, better concurrency semantics—surface characteristics be damned. Sure, I have my preferences about orthography, but the tail doesn't wag the dog. Look deeper! Learn what each language has to teach you! Then keep the parts that move our craft forward and use whatever glyphs you want. But don't reject the automobile because it doesn't have handlebars. Moreover, the things that look familiar probably have the least to teach you. I believe we have the ability to do so much better as an industry, but it's not going to happen if we reject the unfamiliar just for being so.

I went there, saw the Lisp syntax, and noped back out.

dunefox 4y ago

Your loss.

co_dh 4y ago

Me too

malodyets 4y ago

Nope as a verb is new to me - just heard it for the second time this week. First time was from my child.

adrusi 4y ago
It's somewhat youthful internet slang. You'd hear it at the American public highschool I was at 12 years ago.

sergiotapia 4y ago

Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.

nnadams 4y ago
I've been using Lisp for hobby projects for a few years. Yes the syntax takes some time, but > I feel like if I used it, it would atrophy my skills in other more traditional languages. was not the case for me at all. If you go into a text editor and remove all the parentheses, I find that's how Lisp programmers tend to see Lisp, (function argument) isn't that far from function(argument). Learning Lisp has only improved my skills as a programmer, after getting ideas like code as data, macros, let over lambda, CLOS and the metaobject protocol. It's a simple model that to me shows how other languages have picked an abstraction and stuck with it, but Lisp has all the tools to implement those abstractions and more. More mainstream languages are great at focusing the developer, and that makes them very practical. It is amusing though to watch many of the "new features" in languages come out even though Lisp had them years ago.
- asyd 4y ago
  Reading Peter Norvig's PAIP (https://github.com/norvig/paip-lisp https://github.com/norvig/paip-lisp) in 1998 totally blew my mind. It completely changed how I think about programming in every other language I use(d). I love it still, and always will. And yes, my experience is the same as yours: learning lisp made me a better programmer in every other language I use (especially -- but not only -- Python). The simplicity and symmetry of the syntax is a big part of that love for me. Being able to manipulate lisp code as lisp data, using the full power of the language to do so, is just brilliant. Janet looks lovely! Looking forward to the book.
mypetocean 4y ago
The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle](https://en.wikipedia.org/wiki/Mere-exposure_effect https://en.wikipedia.org/wiki/Mere-exposure_effect)). I've never used a Lisp-family language, but I find the reaction against parentheses to be overblown. The reading order of the code is also _consistent,_ rather than the frequent switching between infix notation, prefix notation, and postfix notation which we have to learn and parse in most languages outside the Lisp family. This is a benefit which deceptively looks like it is _more_ complicated, despite being simpler to parse visually (and otherwise). Another example of the familiarity principle at work.
- mypetocean 4y ago
  Oh, I guess Markdown doesn't work. Huh. Well, shoot.
  - tmtvl 4y ago
    HN comment formatting options can be found here: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
- tremon 4y ago
  The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. This tired trope needs to die. Yes, there are more parentheses, because lisp also uses parentheses where other languages use [] or {} or ;. The real thing is that people from C-like languages are used to seeing different block markers for different constructs. It takes effort to read Lisp coming from other languages, because those other languages have a richer symbol vocabulary. Learning to read code without those symbols is like reading English where all punctuation has been replaced with a single space. Sure you ll get there eventually but it s a very cheap straw man argument to pretend that the only complaint people have about Lisps is the positioning of the parentheses.
camdez 4y ago
I certainly don't fault you for having that reaction, but I would encourage you to look deeper and not dismiss one of the most interesting families of programming languages on the basis that it looks weird. Far from atrophying your skills in other languages, many people say that learning Lisp makes them better programmers even when they're coding in other languages. Lisps don't arbitrarily look weird—there's a deep, principled, elegant reason for it; Lisp code represents how the code will be evaluated in the most direct way, without relying on (some would say needlessly) complex parsing / precedence rules. There are no surprises and no arbitrary rules to learn. There are no useless semicolons to forget, and you'll never have to wonder if `+=` returns the RHS or the result of the operation (or does it even have a return value?). You don't have this meaningless distinction where you can't directly reduce with `+` because—ugh—it's not a function, it's an operator. You just say `(reduce + [1 2 3])`. You never have to do this ugly Ruby stuff... words.map &:length # or words.map { |w| w.length } ...because methods are really just polymorphic functions, but language designers chose syntax that doesn't compose elegantly. You don't have this useless distinction between statements and expressions that limits how you can compose code. You never have to drop down to some ugly, limited tertiary expression form (`COND ? X : Y`) of `if` because—whoops—`if` is a "statement". You just write: (println (if me? "me" "you")) Because, duh, we wanted an `if`. What do we gain by adding all of this noise?: if (is_me) { println("me"); } else { println("you"); } Absolutely nothing. The parens on the conditional, the curly braces, the semicolons, the `else` keyword—they're essentially meaningless incantations to appease the compiler. And we've introduced an undesirable opportunity for the two branches to accidentally diverge over time. But most importantly, our code is written in the data structures of our language. Code as data means we can manipulate code as easily as we manipulate data, which means we can trivially (re-)write code with code (i.e. macros). And not shitty string generating macros, or macros that can only do a handful of sanctioned things—we can write our own control structures in couple lines of code. We can add new abstractions to the programming language from user space. Wish the language had an `if-not` construct? You can add it with, like, 3 lines of code. Wish functions could have optional parameters? Add it. Wish it had a pattern matching functions like SML or Erlang? Cool. Java-style annotations? Logging that is fully removed when running in high performance mode? A different OO model? Multi-line string literals? String interpolation? A graph of dependent calculations that only get run when used? A more convenient way to load dependencies? It's all easily doable. I've coded in Lisps (and a dozen other languages) for at least 20 years, and every time I have to use a non-Lisp syntax I just think "wow, these people really missed the boat". It's like having to write math in Roman numerals (would you rather calculate "D + L + IX" or "500 + 50 + 9"?); there's a better way, and that better way has elegant, recursive, underlying design principles that make the ergonomics way better. But, yeah, it doesn't look like C code. And people seem to be really attached to their C syntax.
eggy 4y ago
Quite the opposite. Learning a Lisp or an Array language will build your skills and make you a better programmer. Syntax should fade as a criteria as you become proficient in various PLs. For example, the sum of a list (not running or cumulative sum, but total sum. Should equal 10, not 1, 3, 6, 10): Lisp: (+ 1 2 3 4) J/APL[0]: +/1 2 3 4 Python: Sum = sum([1,2,3,4]) print(Sum) They all do the same. I prefer the conciseness of J/APL and Lisp in this case, and the application of a function over the list or vector. The beauty of the REPL is that you see the result without a 'print' statement. Solving problems in these other languages will influence how you program in your base language as well, and usually for the better. I am also guilty of syntax bias. I prefer LFE (Lisp Flavoured Erlang)[3] over Elixir and Gleam. Gleam[1], another language that runs on the Erlang VM (BEAM), had a more ML syntax, but then it chose to join the syntax popularity contest and move to a more Algol/C/Rust syntax. I prefer vanilla Erlang over it too. [0] https://www.jsoftware.com/#/ https://www.jsoftware.com/#/ [1] https://gleam.run/ https://gleam.run/ [3] https://lfe.io/ https://lfe.io/
59nadir 4y ago
> I feel like if I used it, it would atrophy my skills in other more traditional languages. If your skills in other languages are tied to a syntax then you never had any skills to begin with. I've used pretty much every syntax (and too many languages) out there and the only difference I've ever found is that ML syntax is nicer for automatically curried functions and LISP syntax is much nicer for meta-programming. The rest is effectively all down to paradigms, runtimes and libraries.

pmoriarty 4y ago

Lisp syntax is a huge plus for me, and if a language doesn't have it I know it's not for me.

camdez 4y ago

Agreed. This is why I don't do any math I can't do on my fingers. Parentheses are just too scary, and there's no way that parenthesis math junk actually has any useful ideas.

ravi-delia 4y ago
I understand the reaction, but some people feel just as negatively about parentheses as lispers feel positively. If I can feel positively about a language purely because of the parens, it's no sillier to feel negatively for the same reason.
- camdez 4y ago
  I actually agree with that entirely, and the point of my jest was just to say that we should look deeper for the important ideas, not refuse to read the book because we don't like the color of the cover. Lispers don't feel positive about Lisp because of parentheses; change them to curly braces or brackets or ^ and $—that's really not what matters. Lisps with brackets go all the way back to the beginning (https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression). Indentation-based Lisps have been done too (https://readable.sourceforge.io/ https://readable.sourceforge.io/). The point is an expression-based syntax that directly models the code tree, is written in the data structures of language, and is convenient for meta-programming. It's a fundamentally different approach that yields massive benefits (see my other comment in the thread if you want to hear that spelled out in more detail). But we don't see that when we just stop at unfamiliar syntax. Lispers have been structurally-editing code as a matter of course since at least 1970. Most of the rest of the world only got a taste of that when tree-sitter came out circa 2018 (I know I'm rounding the edges here, but the point stands). Half a century later! Why is that? It's not just curly braces vs parens—something deeper is happening here. I do apologize if I came off rude. I'm just so frustrated at hearing this same line year after year after year from people who are missing out some of the most powerful ideas in programming because they prefer this ASCII glyph over that one. It's nothing more than parochialism. It just makes me want to scream (perhaps uncharitably) "surely you're not a serious engineer who works on serious problems if your biggest concern while coding is which character is used to group code?!" I want tools to help me think more clearly, ways to operate at higher levels of abstraction, better concurrency semantics—surface characteristics be damned. Sure, I have my preferences about orthography, but the tail doesn't wag the dog. Look deeper! Learn what each language has to teach you! Then keep the parts that move our craft forward and use whatever glyphs you want. But don't reject the automobile because it doesn't have handlebars. Moreover, the things that look familiar probably have the least to teach you. I believe we have the ability to do so much better as an industry, but it's not going to happen if we reject the unfamiliar just for being so.