3 ms·

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A prettier lisp would do the world good, but things like sweet expressions are confusing for absolutely new devs to implement and veterans feel like they don't need them. Short version: Lisp wallows in obscurity thanks to it's "look"

lloeki 9y ago
Sweet expressions are a bridge too far IMHO. I would be perfectly content with merely getting rid of those dangling ))))) thanks to simple parentheses insertion† based on a single very simple indent/dedent rule: > if the next line is indented, anything from the beginning of the current line starting at the indent till a dedent matching the current line indent is wrapped in one set of parentheses. Seriously, what about this? defmacro deftag [name] list 'defn name ['& 'inner] list 'str "<" (str name) ">" '(apply str inner) "</" (str name) ">" deftag html deftag body deftag h1 deftag p Now what about the DSL that now downright looks like slim-lang?: html body h1 "Hello World" p "How's it going?" Or look at that: defn qsort [coll] if (empty? coll) coll let [pivot (first coll) remainder (rest coll)] concat (qsort (filter (partial > pivot) remainder)) [pivot] (qsort (filter (partial <= pivot) remainder)) (even the qsort ones could be removed, but they balance [pivot] somehow) I'm perfectly happy with writing (+ 1 2 3) or whatever, the only parentheses that bother me are those that are perfectly delineated by indentation already, just as newlines perform the same duty as semicolons. They're just duplicated noise††. † Other languages perform similar semicolon insertion, with varying degrees of success and ambiguities (JS==terrible, Go==terrific). †† I know, you're supposed to get used to it and "unsee" them. I know, "paredit!". But seriously if you have to write a tool solely to produce noise, and you have to get accustomed to ignore said noise, well, somehow, something's off.
- deleted 9y ago
  [deleted]
- Jtsummers 9y ago
  Dylan. Dylan offered something like what you're asking for here. You had much the same power as traditionally structured lisps (it even has an alternative s-expression syntax). https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language)
- kamaal 9y ago
  You might want to take a look at Haskell. It comes from a family of languages called ML. And ML was known at one point as Lisp without parenthesis. Modern incarnations of the same like F# are attractive too. But Lisp is what it is, List processing.
kamaal 9y ago
This is not true for many reasons. Firstly every time you begin a block of code in any language you add parentheses, So the parentheses count comes out same in all languages. Secondly, parentheses are a non-issue in lisp. Its almost like reading english text with spaces. After a while(quite quickly in-fact) they are a total non issue. >>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write Arguably the biggest problem today is programmers who are stuck at early intermediate level all life.
taeric 9y ago
I find this the least compelling reason, to be honest. Especially when I check how many brackets and other decorations I have in a typical java file. The majority of the code, actually, has a similar number of brackets, and way more commas. :) (Specifically, most java could be a lisp if you just move the function name into its paren and remove all of the commas.) Granted, the bike shedding that goes on in our industry is hilarious. I think many people blame semicolons as one of the major hurdles to learning c nowadays. The things we fixate on...
flavio81 9y ago
>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. Are you sure? Reading a file in Go func read(f) { var text string var scanner *bufio.Scanner var err error file, err := os.Open(f) if err != nil { log.Fatal(err) } scanner = bufio.NewScanner(file) for scanner.Scan() { text += scanner.Text() } err = scanner.Err() if err != nil { log.Fatal(err) } fmt.Println(text) } in Common Lisp (defun read (filename) (with-open-file (input filename) (loop for line = (read-line input nil) while line do (print line)))) Now tell me which one is easier to read. And the lisp example you can understand what it does without even knowing any kind of Lisp language; it is almost english.
- mixmastamyk 9y ago
  Not very convincing. Yes the words are simpler, but the density and mental paren parsing are roadblocks. Perhaps a lisp with python-style indentation for blocks would be more easily read? def read (filename) with-open-file (input filename) for line in (read-line input nil) while line do print line
kbutler 9y ago
A lisp program will tend to have fewer parentheses than an equivalent Java program has parens + braces. They just stack up at the end of the expression. For example, see https://gist.github.com/coding4food/1248505 https://gist.github.com/coding4food/1248505 Part of this is because lisp tends to be more concise, so there are fewer expressions required. There are relatively few places where lisp adds parentheses, rather than just moving them - mostly just basic operator expressions: (+ a b) vs a + b. Adding parens (a + b) doesn't make it any harder to read. For function calls, Algol-descended languages already use parentheses and prefix notation, they just put the parens around the arguments instead of the whole expression: (function argument list) vs function(argument, list)

lloeki 9y ago

Sweet expressions are a bridge too far IMHO. I would be perfectly content with merely getting rid of those dangling ))))) thanks to simple parentheses insertion† based on a single very simple indent/dedent rule: > if the next line is indented, anything from the beginning of the current line starting at the indent till a dedent matching the current line indent is wrapped in one set of parentheses. Seriously, what about this? defmacro deftag [name] list 'defn name ['& 'inner] list 'str "<" (str name) ">" '(apply str inner) "</" (str name) ">" deftag html deftag body deftag h1 deftag p Now what about the DSL that now downright looks like slim-lang?: html body h1 "Hello World" p "How's it going?" Or look at that: defn qsort [coll] if (empty? coll) coll let [pivot (first coll) remainder (rest coll)] concat (qsort (filter (partial > pivot) remainder)) [pivot] (qsort (filter (partial <= pivot) remainder)) (even the qsort ones could be removed, but they balance [pivot] somehow) I'm perfectly happy with writing (+ 1 2 3) or whatever, the only parentheses that bother me are those that are perfectly delineated by indentation already, just as newlines perform the same duty as semicolons. They're just duplicated noise††. † Other languages perform similar semicolon insertion, with varying degrees of success and ambiguities (JS==terrible, Go==terrific). †† I know, you're supposed to get used to it and "unsee" them. I know, "paredit!". But seriously if you have to write a tool solely to produce noise, and you have to get accustomed to ignore said noise, well, somehow, something's off.

deleted 9y ago
[deleted]
Jtsummers 9y ago
Dylan. Dylan offered something like what you're asking for here. You had much the same power as traditionally structured lisps (it even has an alternative s-expression syntax). https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language)
kamaal 9y ago
You might want to take a look at Haskell. It comes from a family of languages called ML. And ML was known at one point as Lisp without parenthesis. Modern incarnations of the same like F# are attractive too. But Lisp is what it is, List processing.

kamaal 9y ago

This is not true for many reasons. Firstly every time you begin a block of code in any language you add parentheses, So the parentheses count comes out same in all languages. Secondly, parentheses are a non-issue in lisp. Its almost like reading english text with spaces. After a while(quite quickly in-fact) they are a total non issue. >>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write Arguably the biggest problem today is programmers who are stuck at early intermediate level all life.

taeric 9y ago

I find this the least compelling reason, to be honest. Especially when I check how many brackets and other decorations I have in a typical java file. The majority of the code, actually, has a similar number of brackets, and way more commas. :) (Specifically, most java could be a lisp if you just move the function name into its paren and remove all of the commas.) Granted, the bike shedding that goes on in our industry is hilarious. I think many people blame semicolons as one of the major hurdles to learning c nowadays. The things we fixate on...

flavio81 9y ago

>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. Are you sure? Reading a file in Go func read(f) { var text string var scanner *bufio.Scanner var err error file, err := os.Open(f) if err != nil { log.Fatal(err) } scanner = bufio.NewScanner(file) for scanner.Scan() { text += scanner.Text() } err = scanner.Err() if err != nil { log.Fatal(err) } fmt.Println(text) } in Common Lisp (defun read (filename) (with-open-file (input filename) (loop for line = (read-line input nil) while line do (print line)))) Now tell me which one is easier to read. And the lisp example you can understand what it does without even knowing any kind of Lisp language; it is almost english.

mixmastamyk 9y ago
Not very convincing. Yes the words are simpler, but the density and mental paren parsing are roadblocks. Perhaps a lisp with python-style indentation for blocks would be more easily read? def read (filename) with-open-file (input filename) for line in (read-line input nil) while line do print line

kbutler 9y ago

A lisp program will tend to have fewer parentheses than an equivalent Java program has parens + braces. They just stack up at the end of the expression. For example, see https://gist.github.com/coding4food/1248505 https://gist.github.com/coding4food/1248505 Part of this is because lisp tends to be more concise, so there are fewer expressions required. There are relatively few places where lisp adds parentheses, rather than just moving them - mostly just basic operator expressions: (+ a b) vs a + b. Adding parens (a + b) doesn't make it any harder to read. For function calls, Algol-descended languages already use parentheses and prefix notation, they just put the parens around the arguments instead of the whole expression: (function argument list) vs function(argument, list)