8 ms·

The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" Any given Lisp is still a programming language--it ha

by tikhonj 13y ago

The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" Any given Lisp is still a programming language--it has some syntax and it has semantics. But it does have a much simpler grammar than any language (save Forth). The grammars exist because programs are made to be read by people, not just computers. A more heterogeneous notation can make for more concise code that's easier to scan and easier to read. Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax. At the same time, I also often want less noise--ie no parentheses. I want all this so that I can quickly scan and comfortably read my code. That's why we need grammars.

nabla9 13y ago
>I also often want less noise--ie no parentheses. You have not reached Lisp enlightenment yet. Because you use Emacs, you can get shortcut to enlightenment by choosing color for parentheses that almost hides them to the background.
- goldenkey 13y ago
  I prefer rainbow parenthesis based on nesting depth.
- jballanc 13y ago
  You could also use a Scheme that has implemented SRFI 49: http://srfi.schemers.org/srfi-49/srfi-49.html http://srfi.schemers.org/srfi-49/srfi-49.html (I think the fact that SRFI 49 is not more popular might say something, though...)
  - klrr 13y ago
    That reminds me of the language Z. http://chrisdone.com/z/ http://chrisdone.com/z/
  - sparkie 13y ago
    There's also http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html, which hasn't taken off "yet." (Unlikely it ever will, just like M-expressions)
- catnaroek 13y ago
  > You have not reached Lisp enlightenment yet. I want a semantically sane language. What do I care what code Lisp macros can autogenerate if nobody can make sure it makes any damn sense?
  - JackMorgan 13y ago
    So, a language where, say, blocks are started sometimes with parameters that are delimited with pipes, and sometimes the bodies need a terminating end keyword, other times they need wrapping curly brackets. If you want an explicit lambda, you have to wrap that whole block in curly brackets with a lambda keyword. Classes and functions need an end delimiter but not an explicit start delimiter; if statements however need both a start and end delimiter in "if x then y else z end" Ruby is not semantically sane, it's insane in a way we have all gotten used to. (If you don't know ruby, try to rewrite this for your ALGO language of choice, I picked ruby for its simplicity) S-expressions are about as semantically sane as you can get, it's just most of us have a <5 year head start with the craziness of c-style languages.
    - catnaroek 13y ago
      > So, a language where, say, blocks are started sometimes with parameters that are delimited with pipes, and sometimes the bodies need a terminating end keyword, other times they need wrapping curly brackets. If you want an explicit lambda, you have to wrap that whole block in curly brackets with a lambda keyword. Classes and functions need an end delimiter but not an explicit start delimiter; if statements however need both a start and end delimiter in "if x then y else z end" You are talking about syntax here. > Ruby is not semantically sane, it's insane in a way we have all gotten used to. I hate Ruby even more. It is just as semantically insane as Lisp, and the syntax is worse. > (If you don't know ruby, try to rewrite this for your ALGO language of choice, I picked ruby for its simplicity) Ruby is not simple. It is full of corner cases and redundant constructs. It is hard to make any sort of reasonable guarantee about a Ruby program without resorting to some heavy testing. And no matter what nice property you might have wrestled out of the system, someone else can destroy it anyway by means of monkey patching. > S-expressions are about as semantically sane as you can get S-expressions are syntax with no intrinsic semantics. > it's just most of us have a <5 year head start with the craziness of c-style languages. What about Haskell? (And, in general, languages that have a denotational semantics that makes equational reasoning feasible.) For more details, see: https://news.ycombinator.com/item?id=6954348 https://news.ycombinator.com/item?id=6954348
raverbashing 13y ago
> But it does have a much simpler grammar than any language (save Forth). And that's why I prefer Forth syntax But yes, you're always going to have a grammar. Albeit simple, you need a tokenizer/parser for lisp and forth. It's simple, but it is there. Computers don't know what 2.345 or "blah" means, we still need a way of inputting this in a friendly way.
- draegtun 13y ago
  Another language with a simple grammar and partially inspired by Forth & Lisp is Rebol... $ rebol >> price: 99 == 99 >> either price > 100 [10] [5] == 5 >> ;;; and even more interesting is... >> ten: [10] == [10] >> five: [5] == [5] >> either price > 100 ten five == 5
  - vezzy-fnord 13y ago
    I remember trying REBOL years ago, but only for a short while and I didn't see it as much of an improvement over Lisp. Should I revisit it again some day?
    - draegtun 13y ago
      I wouldn't view Rebol as a Lisp++ but rather something that's inspired by but interestingly different yet simpler to grasp to Lisp. > Should I revisit it again some day? I'm probably not the best person to ask here because I've only come across Rebol in last 12 months. I've had great fun playing with it and have used it for a few small scripts/projects. The current pros would be: - Rebol3 is now opensourced (since 12-12-2012) - Rebol3 is faster than Rebol2 (in my simple tests about twice as fast) & with smaller footprint. - Rebol3 comes with some design improvements, for eg. 64-bit integers, module system, async schemes & more. However the cons are: - Rebol3 still in alpha/beta development. - So not all features of Rebol2 are (yet) present in Rebol3. - Rebol3 GUI is only available for Windows & Android at this moment. So depending on your use case then you may find yourself still needing to use Rebol2.
JackMorgan 13y ago
If you code in C, C++, C#, JS, or Java, there is a good chance your code has just as many curly brackets and parentheses as the equivalent code in lisp. The biggest differences being they are more irregular in location and there are more newlines separating your closing delimiters. Check this insightful comment out. https://news.ycombinator.com/item?id=6960546 https://news.ycombinator.com/item?id=6960546 If you code in Ruby, Python, or Coffeescript, yeah, lisp has more parens, no doubt. That is the price of its regularity. Lisp could throw all that out the window, but you'd lose the easy macros. Edit: added the link
bad_user 13y ago
I think a more helpful question would be "in what instances do I need syntax?". Could you build a type-system like Haskell has for LISP? Would it be usable? In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones. LISP is at its core a dynamic language. It makes sense to treat code as being data that can be manipulated. Getting rid of all that syntax gives you great power in terms of what you can do. And personally I find Clojure code to be much saner than code written in Ruby or Python, but that's another discussion. However, the other side of the coin are Haskell or Miranda (its predecessor) or languages in the ML family or Scala. These languages go to great length to achieve much of LISP's expressiveness, while ensuring a great amount of static type-enforcement. Haskell is especially notable because Haskell is lazy and has many goodies, such as type-classes or rank-2 types. People say that when a piece of Haskell code successfully compiles it is usually correct. LISP can't do this, even though there have been experiments with pluggable type-systems. For an excellent rant on the choice of Scheme for SICP (and not Miranda, Haskell's predecessor), checkout: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p... So IMHO, syntax helps if you want static type-safety, because the language and the type-system exposed need to be expressive. Whether static type-safety is useful or not, it's a matter of debate, being highly dependent on the problem domain. One could argue that static type-safety is very useful if the shape of the data you're manipulating is well defined and doesn't change much, otherwise you're better off with a dynamic language, but that's another discussion.
- catnaroek 13y ago
  > In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones. Type systems fall squarely in the "semantics, not syntax" department.
  - brudgers 13y ago
    Yes, that is true of type systems. But the comment was that syntax is needed for a language which implements static types. This implies static type checking, and while Hindley-Milner inference can do a lot of lifting, a statically typed language which had no syntax for explicitly expressing types might struggle to express solutions that lend themselves to programmer defined data types.
catnaroek 13y ago
> The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" A more useful question is the following: "is a simple grammar the be-all and end-all of programming language design?". I think the answer is "no". Ceteris paribus, a simpler grammar is of course to be preferred to a complex grammar. But, ultimately, people write programs for what they do (so that they can be useful) and for what they mean (so that they can be maintainable), not for how they look like. So a simple semantics takes precedence over a simple syntax. > Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax. That is precisely what languages like Haskell (and to a lesser extent ML) give you: a typed lambda calculus (semantic simplicity) with infix operators (syntactic eye candy) for convenience. The type system reduces the universe of valid programs to those that typecheck, so you do not have to worry about stuff like the meaning of 2 + "potato".
- brudgers 13y ago
  Racket is typed, and as strongly typed as Haskell and ML. I think what you were getting at is that Haskell and ML are statically typed whereas Racket is dynamically typed by default. However, #lang typed/racket allows full access to static type checking.
  - catnaroek 13y ago
    There is no such thing as dynamic typing: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ http://existentialtype.wordpress.com/2011/03/19/dynamic-lang...
    - brudgers 13y ago
      By that token, there is no such thing as statically typed either, and if we chase the turtles all the way down to the Turing tarpit, there's only two types: high and low and they're both voltages or the equivalent. As Wittgenstein remarked, many philosophical conundrums arise from the odd results that follow from using ordinary language in an odd way.
brudgers 13y ago
Racket lets you use infix operators if you want: (5 . * . 3) ; 15 (5 . > . 3) ; #t As a bonus, you even get more verbose syntax as in other languages, because Racket, being a Lisp will let you write code any old which way so long as there is a macro available to parse it.
- kroger 13y ago
  There are many infix macros for Common Lisp. This one [1], for instance, allows you to write: #I( x^^2 + y^^2 ) And, naturally, you can macroexpand the macro. [1] ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/code/syntax/infix/infix.cl
  - brudgers 13y ago
    The difference, if there is one, is that Racket provides an infix syntax as part of its definition, i. e. there is a standard notation. I''ve seen it used in the reference documentation for the -> operator when writing contracts.
    - kroger 13y ago
      Racket is a scheme, but this infix notation is unique to racket, i.e. it's not in the scheme specification. In fact, there are other proposals for infix notation for scheme, such as http://srfi.schemers.org/srfi-105/srfi-105.html http://srfi.schemers.org/srfi-105/srfi-105.html
danneu 13y ago
> I actually rather like... > I've found that I still heavily prefer... > I also often want... > I want all this so that I can... ... > That's why we need grammars. Well, that was a twist ending.
6d0debc071 13y ago
> A more heterogeneous notation can make for more concise code that's easier to scan and easier to read. [...] I want all this so that I can quickly scan and comfortably read my code. I actually find those harder to read. Generally, because I can indent Lisp code however the heck I like, I have a pretty good idea what's going on just from looking at the structure of the code and reading a few words here and there. It's a fairly common experience for me in other languages to be scanning back and forth across a line searching for that $%^$£%£ operator rather than (in the rare event I get really lost in a Lisp file) just going, "Highlight the next s-expression up, ah that's what's going on." Or "You know what? Indent my code for me in a different way." I wonder whether there's a divide between people who understand code initially by looking at the structure and people who understand code initially by looking at the operators in terms of who likes Lisp :/

by tikhonj 13y ago

nabla9 13y ago

>I also often want less noise--ie no parentheses. You have not reached Lisp enlightenment yet. Because you use Emacs, you can get shortcut to enlightenment by choosing color for parentheses that almost hides them to the background.

goldenkey 13y ago
I prefer rainbow parenthesis based on nesting depth.
jballanc 13y ago
You could also use a Scheme that has implemented SRFI 49: http://srfi.schemers.org/srfi-49/srfi-49.html http://srfi.schemers.org/srfi-49/srfi-49.html (I think the fact that SRFI 49 is not more popular might say something, though...)
- klrr 13y ago
  That reminds me of the language Z. http://chrisdone.com/z/ http://chrisdone.com/z/
- sparkie 13y ago
  There's also http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html, which hasn't taken off "yet." (Unlikely it ever will, just like M-expressions)
catnaroek 13y ago
> You have not reached Lisp enlightenment yet. I want a semantically sane language. What do I care what code Lisp macros can autogenerate if nobody can make sure it makes any damn sense?
- JackMorgan 13y ago
  So, a language where, say, blocks are started sometimes with parameters that are delimited with pipes, and sometimes the bodies need a terminating end keyword, other times they need wrapping curly brackets. If you want an explicit lambda, you have to wrap that whole block in curly brackets with a lambda keyword. Classes and functions need an end delimiter but not an explicit start delimiter; if statements however need both a start and end delimiter in "if x then y else z end" Ruby is not semantically sane, it's insane in a way we have all gotten used to. (If you don't know ruby, try to rewrite this for your ALGO language of choice, I picked ruby for its simplicity) S-expressions are about as semantically sane as you can get, it's just most of us have a <5 year head start with the craziness of c-style languages.
  - catnaroek 13y ago
    > So, a language where, say, blocks are started sometimes with parameters that are delimited with pipes, and sometimes the bodies need a terminating end keyword, other times they need wrapping curly brackets. If you want an explicit lambda, you have to wrap that whole block in curly brackets with a lambda keyword. Classes and functions need an end delimiter but not an explicit start delimiter; if statements however need both a start and end delimiter in "if x then y else z end" You are talking about syntax here. > Ruby is not semantically sane, it's insane in a way we have all gotten used to. I hate Ruby even more. It is just as semantically insane as Lisp, and the syntax is worse. > (If you don't know ruby, try to rewrite this for your ALGO language of choice, I picked ruby for its simplicity) Ruby is not simple. It is full of corner cases and redundant constructs. It is hard to make any sort of reasonable guarantee about a Ruby program without resorting to some heavy testing. And no matter what nice property you might have wrestled out of the system, someone else can destroy it anyway by means of monkey patching. > S-expressions are about as semantically sane as you can get S-expressions are syntax with no intrinsic semantics. > it's just most of us have a <5 year head start with the craziness of c-style languages. What about Haskell? (And, in general, languages that have a denotational semantics that makes equational reasoning feasible.) For more details, see: https://news.ycombinator.com/item?id=6954348 https://news.ycombinator.com/item?id=6954348

raverbashing 13y ago

> But it does have a much simpler grammar than any language (save Forth). And that's why I prefer Forth syntax But yes, you're always going to have a grammar. Albeit simple, you need a tokenizer/parser for lisp and forth. It's simple, but it is there. Computers don't know what 2.345 or "blah" means, we still need a way of inputting this in a friendly way.

draegtun 13y ago
Another language with a simple grammar and partially inspired by Forth & Lisp is Rebol... $ rebol >> price: 99 == 99 >> either price > 100 [10] [5] == 5 >> ;;; and even more interesting is... >> ten: [10] == [10] >> five: [5] == [5] >> either price > 100 ten five == 5
- vezzy-fnord 13y ago
  I remember trying REBOL years ago, but only for a short while and I didn't see it as much of an improvement over Lisp. Should I revisit it again some day?
  - draegtun 13y ago
    I wouldn't view Rebol as a Lisp++ but rather something that's inspired by but interestingly different yet simpler to grasp to Lisp. > Should I revisit it again some day? I'm probably not the best person to ask here because I've only come across Rebol in last 12 months. I've had great fun playing with it and have used it for a few small scripts/projects. The current pros would be: - Rebol3 is now opensourced (since 12-12-2012) - Rebol3 is faster than Rebol2 (in my simple tests about twice as fast) & with smaller footprint. - Rebol3 comes with some design improvements, for eg. 64-bit integers, module system, async schemes & more. However the cons are: - Rebol3 still in alpha/beta development. - So not all features of Rebol2 are (yet) present in Rebol3. - Rebol3 GUI is only available for Windows & Android at this moment. So depending on your use case then you may find yourself still needing to use Rebol2.

JackMorgan 13y ago

If you code in C, C++, C#, JS, or Java, there is a good chance your code has just as many curly brackets and parentheses as the equivalent code in lisp. The biggest differences being they are more irregular in location and there are more newlines separating your closing delimiters. Check this insightful comment out. https://news.ycombinator.com/item?id=6960546 https://news.ycombinator.com/item?id=6960546 If you code in Ruby, Python, or Coffeescript, yeah, lisp has more parens, no doubt. That is the price of its regularity. Lisp could throw all that out the window, but you'd lose the easy macros. Edit: added the link

bad_user 13y ago

I think a more helpful question would be "in what instances do I need syntax?". Could you build a type-system like Haskell has for LISP? Would it be usable? In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones. LISP is at its core a dynamic language. It makes sense to treat code as being data that can be manipulated. Getting rid of all that syntax gives you great power in terms of what you can do. And personally I find Clojure code to be much saner than code written in Ruby or Python, but that's another discussion. However, the other side of the coin are Haskell or Miranda (its predecessor) or languages in the ML family or Scala. These languages go to great length to achieve much of LISP's expressiveness, while ensuring a great amount of static type-enforcement. Haskell is especially notable because Haskell is lazy and has many goodies, such as type-classes or rank-2 types. People say that when a piece of Haskell code successfully compiles it is usually correct. LISP can't do this, even though there have been experiments with pluggable type-systems. For an excellent rant on the choice of Scheme for SICP (and not Miranda, Haskell's predecessor), checkout: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p... So IMHO, syntax helps if you want static type-safety, because the language and the type-system exposed need to be expressive. Whether static type-safety is useful or not, it's a matter of debate, being highly dependent on the problem domain. One could argue that static type-safety is very useful if the shape of the data you're manipulating is well defined and doesn't change much, otherwise you're better off with a dynamic language, but that's another discussion.

catnaroek 13y ago
> In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones. Type systems fall squarely in the "semantics, not syntax" department.
- brudgers 13y ago
  Yes, that is true of type systems. But the comment was that syntax is needed for a language which implements static types. This implies static type checking, and while Hindley-Milner inference can do a lot of lifting, a statically typed language which had no syntax for explicitly expressing types might struggle to express solutions that lend themselves to programmer defined data types.

catnaroek 13y ago

> The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" A more useful question is the following: "is a simple grammar the be-all and end-all of programming language design?". I think the answer is "no". Ceteris paribus, a simpler grammar is of course to be preferred to a complex grammar. But, ultimately, people write programs for what they do (so that they can be useful) and for what they mean (so that they can be maintainable), not for how they look like. So a simple semantics takes precedence over a simple syntax. > Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax. That is precisely what languages like Haskell (and to a lesser extent ML) give you: a typed lambda calculus (semantic simplicity) with infix operators (syntactic eye candy) for convenience. The type system reduces the universe of valid programs to those that typecheck, so you do not have to worry about stuff like the meaning of 2 + "potato".

brudgers 13y ago
Racket is typed, and as strongly typed as Haskell and ML. I think what you were getting at is that Haskell and ML are statically typed whereas Racket is dynamically typed by default. However, #lang typed/racket allows full access to static type checking.
- catnaroek 13y ago
  There is no such thing as dynamic typing: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ http://existentialtype.wordpress.com/2011/03/19/dynamic-lang...
  - brudgers 13y ago
    By that token, there is no such thing as statically typed either, and if we chase the turtles all the way down to the Turing tarpit, there's only two types: high and low and they're both voltages or the equivalent. As Wittgenstein remarked, many philosophical conundrums arise from the odd results that follow from using ordinary language in an odd way.

brudgers 13y ago

Racket lets you use infix operators if you want: (5 . * . 3) ; 15 (5 . > . 3) ; #t As a bonus, you even get more verbose syntax as in other languages, because Racket, being a Lisp will let you write code any old which way so long as there is a macro available to parse it.

kroger 13y ago
There are many infix macros for Common Lisp. This one [1], for instance, allows you to write: #I( x^^2 + y^^2 ) And, naturally, you can macroexpand the macro. [1] ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/code/syntax/infix/infix.cl
- brudgers 13y ago
  The difference, if there is one, is that Racket provides an infix syntax as part of its definition, i. e. there is a standard notation. I''ve seen it used in the reference documentation for the -> operator when writing contracts.
  - kroger 13y ago
    Racket is a scheme, but this infix notation is unique to racket, i.e. it's not in the scheme specification. In fact, there are other proposals for infix notation for scheme, such as http://srfi.schemers.org/srfi-105/srfi-105.html http://srfi.schemers.org/srfi-105/srfi-105.html

danneu 13y ago

> I actually rather like... > I've found that I still heavily prefer... > I also often want... > I want all this so that I can... ... > That's why we need grammars. Well, that was a twist ending.

6d0debc071 13y ago

> A more heterogeneous notation can make for more concise code that's easier to scan and easier to read. [...] I want all this so that I can quickly scan and comfortably read my code. I actually find those harder to read. Generally, because I can indent Lisp code however the heck I like, I have a pretty good idea what's going on just from looking at the structure of the code and reading a few words here and there. It's a fairly common experience for me in other languages to be scanning back and forth across a line searching for that $%^$£%£ operator rather than (in the rare event I get really lost in a Lisp file) just going, "Highlight the next s-expression up, ah that's what's going on." Or "You know what? Indent my code for me in a different way." I wonder whether there's a divide between people who understand code initially by looking at the structure and people who understand code initially by looking at the operators in terms of who likes Lisp :/