4 ms·

There's an elitism inherent in this take that I think is misplaced. A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syn

There's an elitism inherent in this take that I think is misplaced. A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syntax and deciding it's not for them. Too many Lisp programmers believe that Lisp way is the right way and not just a set of tradeoffs like every other language design.

yw3410 6y ago
Only a relatively few amount of programmers have programmed in non-Algol syntax in-anger, rather than the reverse. How can you weigh up the pro or con of a syntax when you haven't used it much? I couldn't tell you whether APL syntax was any good.
- cageface 6y ago
  I know quite a few really brilliant programmers that were exposed to scheme or lisp in school but prefer other languages for various reasons in their professional work.
  - yw3410 6y ago
    Does programming in-school really count as programming in anger? I did a module on C++ at university but I'm not equipped to evaluate it.
    - mbrodersen 6y ago
      No offence but it sounds as if you are invoking a “True Scotsman” argument here? Also (using your argument) how do you know LISP is better than C++ when you haven’t programmed C++ “in anger”?
      - kazinator 6y ago
        "[N]ot equipped to evaluate [C++]" clearly means that yw3410 doesn't know whether Lisp is better or worse than C++.
- mbrodersen 6y ago
  I have tried really hard to fall in love with LISP style languages. This includes implementing my own LISP interpreters/compilers just for fun. I also know enough Haskell (and Idris) to compare LISP style languages with the “opposite” end of the functional language spectrum. And I an the maintainer of a high performance functional programming language at work. In the end I still end up never reaching for LISP or Clojure when solving real world programming challenges. The key reason is that I am more productive with strong types. The same reason why I initially loved Ruby and then stopped using it the moment I tried to build anything bigger with it. I realise that not having types makes some people happy. That’s great. It just doesn’t make me happy.
  - yw3410 6y ago
    Whoa, this was a point about syntax (non-Algol vs. Algol) being overstated. Haskell and Idris absolutely fall in non-Algol languages that make people do a double-take. For the record I like lots of languages - dependent types are awesome. I find that the language I reach for will mostly be a function of the problem space. Just an FYI, certain Lisps have static typing as well.
kamaal 6y ago
>>A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syntax and deciding it's not for them. Most of the programmers today have negligible experience with Lisp. It's also not really elitism. I'm not saying people are stupid. But people take great pain in avoiding reading documentation and understanding anything in general. Which is why I gave the Perl example. Reading documentation for 30 mins could help you understand the issues and help you fix them at root, instead of hours of Googling. For some reason people do the latter, not the former.
- kls 6y ago
  I actually think your Perl and specifically regex example where spot on, in my career I have only worked with probably 4 programmers who really understood and could think in regex, which gave them the tools to solve extremely complicated parsing problems rather simply. The rest of the teams just relied on those people to do their regex thinking for them. The sad part, it regex it rather simple to learn and just takes a little effort but people treat it like it is black magic.
  - kazinator 6y ago
    A lot of regex-based solutions are not robust against bad input. Bad input doesn't always mean that the regexes don't match! Regexes have a very happy home inside lexical analyzers for tokenizing languages. Lexers define what is correct input and match every case with some regex pattern. If there is no match, then the input doesn't contain a valid token: the lexer can loudly complain (logging an error that can be treated as fatal by the overall compile job), drop an input character and try matching again. The typical regex solutions in Perl (Awk, ...) scripts go like this: "look for this flimsy, minimal regex somewhere in the stream and assume it's the right thing, then match this other regex in the same line and---woo hoo!--that's our item. Oh, false positives, schmozitives." Basically, if we were to pin it down to a single difference in principles is that using regexes for searching for something small in something large is different from matching an entire input in its totality (and then getting at the desired parts). Searching is the quick and dirty thing that's easy to reach for.

yw3410 6y ago

Only a relatively few amount of programmers have programmed in non-Algol syntax in-anger, rather than the reverse. How can you weigh up the pro or con of a syntax when you haven't used it much? I couldn't tell you whether APL syntax was any good.

cageface 6y ago
I know quite a few really brilliant programmers that were exposed to scheme or lisp in school but prefer other languages for various reasons in their professional work.
- yw3410 6y ago
  Does programming in-school really count as programming in anger? I did a module on C++ at university but I'm not equipped to evaluate it.
  - mbrodersen 6y ago
    No offence but it sounds as if you are invoking a “True Scotsman” argument here? Also (using your argument) how do you know LISP is better than C++ when you haven’t programmed C++ “in anger”?
    - kazinator 6y ago
      "[N]ot equipped to evaluate [C++]" clearly means that yw3410 doesn't know whether Lisp is better or worse than C++.
mbrodersen 6y ago
I have tried really hard to fall in love with LISP style languages. This includes implementing my own LISP interpreters/compilers just for fun. I also know enough Haskell (and Idris) to compare LISP style languages with the “opposite” end of the functional language spectrum. And I an the maintainer of a high performance functional programming language at work. In the end I still end up never reaching for LISP or Clojure when solving real world programming challenges. The key reason is that I am more productive with strong types. The same reason why I initially loved Ruby and then stopped using it the moment I tried to build anything bigger with it. I realise that not having types makes some people happy. That’s great. It just doesn’t make me happy.
- yw3410 6y ago
  Whoa, this was a point about syntax (non-Algol vs. Algol) being overstated. Haskell and Idris absolutely fall in non-Algol languages that make people do a double-take. For the record I like lots of languages - dependent types are awesome. I find that the language I reach for will mostly be a function of the problem space. Just an FYI, certain Lisps have static typing as well.

kamaal 6y ago

>>A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syntax and deciding it's not for them. Most of the programmers today have negligible experience with Lisp. It's also not really elitism. I'm not saying people are stupid. But people take great pain in avoiding reading documentation and understanding anything in general. Which is why I gave the Perl example. Reading documentation for 30 mins could help you understand the issues and help you fix them at root, instead of hours of Googling. For some reason people do the latter, not the former.

kls 6y ago
I actually think your Perl and specifically regex example where spot on, in my career I have only worked with probably 4 programmers who really understood and could think in regex, which gave them the tools to solve extremely complicated parsing problems rather simply. The rest of the teams just relied on those people to do their regex thinking for them. The sad part, it regex it rather simple to learn and just takes a little effort but people treat it like it is black magic.
- kazinator 6y ago
  A lot of regex-based solutions are not robust against bad input. Bad input doesn't always mean that the regexes don't match! Regexes have a very happy home inside lexical analyzers for tokenizing languages. Lexers define what is correct input and match every case with some regex pattern. If there is no match, then the input doesn't contain a valid token: the lexer can loudly complain (logging an error that can be treated as fatal by the overall compile job), drop an input character and try matching again. The typical regex solutions in Perl (Awk, ...) scripts go like this: "look for this flimsy, minimal regex somewhere in the stream and assume it's the right thing, then match this other regex in the same line and---woo hoo!--that's our item. Oh, false positives, schmozitives." Basically, if we were to pin it down to a single difference in principles is that using regexes for searching for something small in something large is different from matching an entire input in its totality (and then getting at the desired parts). Searching is the quick and dirty thing that's easy to reach for.