6 ms·

Lisp evangelists that miss the point about syntax

14 points by Confusion 17y ago

brazzy 17y ago
Common sense? In my language flamewar?
- zck 17y ago
  Unfortunately, it's less likely than you think.
- tayssir 17y ago
  I concede that Lisp's notation probably isn't common sensical; and that learning it is a significant investment for many programmers, who are hardwired to quickly understand the conventional notation. However, many important developments in math and science ran counter to common sense. In math, people with common-sense arguments resisted numbers which seemed "irrational", "imaginary" and "negative." (Supposedly, there were times when you could die over them.) Euclidean geometry seemed so obvious that people were scared to discuss non-euclidean ones. In science, even Newton had some self-ridicule about spooky action at a distance, like gravity: "That one body may act upon another at a distance through a vacuum without the mediation of anything else, by and through which their action and force may be conveyed from one another, is to me so great an Absurdity that, I believe, no Man who has in philosophic matters a competent Faculty of thinking could ever fall into it." http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Newton.27s_reservations http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gra...
  - brazzy 17y ago
    I did not mean to imply that Lisp's notation itself was against common sense - just that the article made a very good common-sense point about its expressiveness coming at a price that's often not worth paying, relative to the advantages it gives you over languages with less expressive but more goal-oriented syntax.
fexl 17y ago
As much as I like Lisp and even pure functional languages (such as my own Fexl), I still like that old-school loopy, branchy, bracey, break-ish, drop-down to the iron, procedural feel of straight-up C and even Perl. You won't get a language war from me, but there's a huge difference in "feel" between those two major language classes, and strangely, I kinda like both of them. Sure I can do some impressive reasoning in the functional realm, but even in the procedural realm I can do iron-clad reasoning and correctness-preserving transforms that (I hope) would make Dijkstra proud.
- arethuza 17y ago
  Maybe it was just me, but back in the day when I was paid to write Lisp I was pretty fond of the Common Lisp loop macro. So my Lisp code was pretty loopy...
- brazzy 17y ago
  It's no coincidence they feel different. The Lisp family of languages was based on theoretical mathematical considerations (Lambda calculus), with implementation as an afterthought. The Fortran family of languages was based on the hardware's capabilities, with theoretical considerations like expressiveness as an afterthought. We are fortunate to have reached an age where we have CPU cycles and RAM to spare so that languages that were not designed with performance-related restrictions in mind are becoming practical for a wide variety of applications.
  - fexl 17y ago
    I concur. Fexl can whip combinators around so fast it makes my head spin. But I still like writing C, even if it's only to write a Fexl interpreter. Consequently the whole purpose of Fexl is to be a thin functional "layer" on top of C. That way as a C programmer I can escape to functions to avoid all the gnarly horrors of memory management and such, and as a Fexl programmer I can escape to C to embrace the hard-edged bits and bytes. That way if you asked me whether I was writing the thing in C or in Fexl, I couldn't really give you a straight answer. ;)
    - 17y ago
cabalamat 17y ago
> The ability to create syntax comes at a cost and the existence of so many other programming languages shows one thing very clearly: not everyone is willing to pay that cost. The cost of Lisp is that the syntax is all the same. So a conditional looks the same as an assignment statement, looks the same as a function call, looks the same as a plus operator. Lisp syntax is bad, because many humans find it easier to scan source code if different constructs use different syntax (whether that is just because it is what they are used to, I don't know). But Lisp syntax is also good, because it allows macros. You could get round this problem by having two levels of a language, one with C-like syntax which compiles to Lisp-like syntax (which may itself be compiled). So this: if (a>b) c := foo(d); Might compile to this: (if (> a b) (:= c (foo d)))
- jules 17y ago
  Sexps are better than strings because they are more structured. It would be even better to represent code with separate data types for every construct instead of the relatively unstructured sexps.
  - stcredzero 17y ago
    Just having a special delimiter for code blocks helps tremendously. If you stop there, and don't add more syntax, you're just about at Smalltalk.
  - lispm 17y ago
    s-expressions are an external syntax. You can create any data structure you want from them, given the right reader. S-expressions are not INTERNAL to Lisp, only external. Thus s-expressions are defined on characters. Comparing s-expressions to strings makes no sense. The representation of code is a different issue. You could read an s-expression and represent it internally as a string.
- lispm 17y ago
  No, Lisp syntax is not all the same. 'if' has the syntax if test-form then-form [else-form] 'cond' has the syntax cond {clause}* => result* clause::= (test-form form*) 'case' has the syntax case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) LOOP has a full page of syntax. http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... What you think has 'no' syntax, is the syntax for s-expressions. S expressions are relatively trivial, but not every s-expression is a valid Lisp form. S-expressions are a syntax for DATA. The syntax of Lisp, the programming language, is described on top of s-expressions. Syntax is concerned with the structure of valid expressions of a language. So you have an additional layer of syntax which describes, on top of s-expressions, the syntax of Lisp. There is some basic syntax: * data like numbers, strings are valid Lisp programs * function calls are valid Lisp programs. Function calls have a non-trivial syntax with rest, optional and keyword args, lambda functions, ... * special forms like CATCH, FLET, IF, QUOTE, SETQ, ... all have their defined syntax * macro calls, here the macro has to implement the syntax specified in the standard. users can do with their macros what they want. For example (if (foo-p) (this) (that) (these)) is a syntax error, though it is a valid S-expression. Similar (loop for i below 10 (print i)) is also wrong. Correct would be for example (loop for i below 10 do (print i)) So, what you may want is to remove the data syntax (s-expressions) from Lisp and replace it with some other layer of syntax that is not based on prefix parentheses-heavy s-expressions. There are lots of languages that have different syntactical approaches. Lisp has its own, which makes it slightly unusual (the syntax is used to support the code-is-data paradigm), less popular, but also makes sure that it will find its users - those users who want a language with a flexible syntax (one that can be extended by the developer) on top of a simple data syntax.
stcredzero 17y ago
So why not create syntax that catches 99% of the cases for which you intend the language to be used This just indicates the author is clueless about the substantive use of a DSL. The only way to implement this is to vastly reduce the scope of that "intend." Basically equivalent to, "all you really need is Blub." 80% would be reasonable. But the last 20% is going to encompass some powerful stuff.
- Confusion 17y ago
  I'm not really sure why you bring up DSL's, unless you consider something like Python or Perl a DSL as well. In that case: are you saying that, for instance, Perl is only useful for 80% of the cases for which that language is intended to be used?
  - stcredzero 17y ago
    Nope. You can "do it all" in any Turing-complete language. But you can often do it more elegantly with a DSL. Once a language reaches a certain threshold of power, making a DSL is indistinguishable from ordinary coding. It's obvious the author hasn't a Clue about that.
    - Confusion 17y ago
      The point of the article was that creating a sufficiently powerful language, that doesn't offer easy ways[1] of extending the syntax, does not warrant the criticism that the language has 'too much syntax'. If anything, it demonstrates the power of being able to create syntax. I don't understand how your comment relates to that point. [1] Of course you can "do it all" in any Turing-complete language, but theoretical possibilities are often much less interesting than practical impossibilities. In Python or Java, creating new syntax is so hard it might as well not be possible.
      - stcredzero 17y ago
        Exercise for the student -- find the contradiction here: The point of the article was that creating a sufficiently powerful language, that doesn't offer easy ways[1] of extending the syntax, does not warrant the criticism that the language has 'too much syntax'. Evidently, you are as inexperienced with DSLs as the author. Of course you can "do it all" in any Turing-complete language, but theoretical possibilities are often much less interesting than practical impossibilities. In Python or Java, creating new syntax is so hard it might as well not be possible. Insufficient knowledge is probably why you mistook the sense of the statement you are replying to by 180 degrees.
alec 17y ago
"So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax?" Because then I've got a syntax that works for 99% of the use cases you've already thought of, and that doesn't overlap very well with the use cases I have or that either of us will come up with in the future.
anamax 17y ago
As I commented, get back to me when you've got a non-lisp syntax that doesn't result in bugs from precedence/associativity errors. If infix was actually "natural", there'd be only one set of precedence/associativity rules and there wouldn't be bugs due to folks getting it wrong. With very few exceptions, folks use parentheses to try to protect themselves from their ignorance of their language's precedence rules. (C++ has over 10 levels of precedence.) Even then,they occasionally get it wrong. And, it's worse than that on teams because different folks have different knowledge (and illusions) of the precedence rules.
l0stman 17y ago
You can't expect people to be reasonable when it comes to language flamewar. Personally, I think weak advocacy is worse than no advocacy at all. So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax? Although it's possible to create new syntax in Common Lisp via reader macros -- I don't think lispers recommend to extend the syntax. But when you miss a language feature, instead of fighting against the language, you could implement it. I don't remember exactly who said it in one the SICP video lecture, Harold Abelson or Gerald Sussman, but he said something like Lisp is not good at solving a particular problem. What Lisp is good at is extending the language to solve a class of problems. The problem with syntax is that it's difficult to use correctly with macros. It's no wonder that most introduction books to C warns against the pitfalls of using macros. Even the simple ones could bite you if you're not careful. Consider: #define DOUBLE(x) (2*x) /* should be (2*(x)) */ #define MAX(a, b) ((a) < (b) ? (b): (a)) Even the last one is not immune against multiple evaluation problems if you try to evaluate MAX(a++, b). In Lisp you could avoid this by using gensym and local bindings. That being said, C macros and Lisp macros are completely different beasts. And I recommend reading ``On Lisp'' for advanced use of Lisp macros.
kls 17y ago
Barring the complaints about syntax and the assumptions made in the article, I would still say the one reason someone should learn LISP is that most likely one will have an entire career of writing logic the "other way", I am not disparaging the "other way", just stating that it is far more prevalent and if you are learning something for personal growth LISP will give you a more diverse perspective than using a language that is an evolution of the "other way".

14 points by Confusion 17y ago

brazzy 17y ago

Common sense? In my language flamewar?

zck 17y ago
Unfortunately, it's less likely than you think.
tayssir 17y ago
I concede that Lisp's notation probably isn't common sensical; and that learning it is a significant investment for many programmers, who are hardwired to quickly understand the conventional notation. However, many important developments in math and science ran counter to common sense. In math, people with common-sense arguments resisted numbers which seemed "irrational", "imaginary" and "negative." (Supposedly, there were times when you could die over them.) Euclidean geometry seemed so obvious that people were scared to discuss non-euclidean ones. In science, even Newton had some self-ridicule about spooky action at a distance, like gravity: "That one body may act upon another at a distance through a vacuum without the mediation of anything else, by and through which their action and force may be conveyed from one another, is to me so great an Absurdity that, I believe, no Man who has in philosophic matters a competent Faculty of thinking could ever fall into it." http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Newton.27s_reservations http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gra...
- brazzy 17y ago
  I did not mean to imply that Lisp's notation itself was against common sense - just that the article made a very good common-sense point about its expressiveness coming at a price that's often not worth paying, relative to the advantages it gives you over languages with less expressive but more goal-oriented syntax.

fexl 17y ago

As much as I like Lisp and even pure functional languages (such as my own Fexl), I still like that old-school loopy, branchy, bracey, break-ish, drop-down to the iron, procedural feel of straight-up C and even Perl. You won't get a language war from me, but there's a huge difference in "feel" between those two major language classes, and strangely, I kinda like both of them. Sure I can do some impressive reasoning in the functional realm, but even in the procedural realm I can do iron-clad reasoning and correctness-preserving transforms that (I hope) would make Dijkstra proud.

arethuza 17y ago
Maybe it was just me, but back in the day when I was paid to write Lisp I was pretty fond of the Common Lisp loop macro. So my Lisp code was pretty loopy...
brazzy 17y ago
It's no coincidence they feel different. The Lisp family of languages was based on theoretical mathematical considerations (Lambda calculus), with implementation as an afterthought. The Fortran family of languages was based on the hardware's capabilities, with theoretical considerations like expressiveness as an afterthought. We are fortunate to have reached an age where we have CPU cycles and RAM to spare so that languages that were not designed with performance-related restrictions in mind are becoming practical for a wide variety of applications.
- fexl 17y ago
  I concur. Fexl can whip combinators around so fast it makes my head spin. But I still like writing C, even if it's only to write a Fexl interpreter. Consequently the whole purpose of Fexl is to be a thin functional "layer" on top of C. That way as a C programmer I can escape to functions to avoid all the gnarly horrors of memory management and such, and as a Fexl programmer I can escape to C to embrace the hard-edged bits and bytes. That way if you asked me whether I was writing the thing in C or in Fexl, I couldn't really give you a straight answer. ;)
  - 17y ago

cabalamat 17y ago

> The ability to create syntax comes at a cost and the existence of so many other programming languages shows one thing very clearly: not everyone is willing to pay that cost. The cost of Lisp is that the syntax is all the same. So a conditional looks the same as an assignment statement, looks the same as a function call, looks the same as a plus operator. Lisp syntax is bad, because many humans find it easier to scan source code if different constructs use different syntax (whether that is just because it is what they are used to, I don't know). But Lisp syntax is also good, because it allows macros. You could get round this problem by having two levels of a language, one with C-like syntax which compiles to Lisp-like syntax (which may itself be compiled). So this: if (a>b) c := foo(d); Might compile to this: (if (> a b) (:= c (foo d)))

jules 17y ago
Sexps are better than strings because they are more structured. It would be even better to represent code with separate data types for every construct instead of the relatively unstructured sexps.
- stcredzero 17y ago
  Just having a special delimiter for code blocks helps tremendously. If you stop there, and don't add more syntax, you're just about at Smalltalk.
- lispm 17y ago
  s-expressions are an external syntax. You can create any data structure you want from them, given the right reader. S-expressions are not INTERNAL to Lisp, only external. Thus s-expressions are defined on characters. Comparing s-expressions to strings makes no sense. The representation of code is a different issue. You could read an s-expression and represent it internally as a string.
lispm 17y ago
No, Lisp syntax is not all the same. 'if' has the syntax if test-form then-form [else-form] 'cond' has the syntax cond {clause}* => result* clause::= (test-form form*) 'case' has the syntax case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) LOOP has a full page of syntax. http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... What you think has 'no' syntax, is the syntax for s-expressions. S expressions are relatively trivial, but not every s-expression is a valid Lisp form. S-expressions are a syntax for DATA. The syntax of Lisp, the programming language, is described on top of s-expressions. Syntax is concerned with the structure of valid expressions of a language. So you have an additional layer of syntax which describes, on top of s-expressions, the syntax of Lisp. There is some basic syntax: * data like numbers, strings are valid Lisp programs * function calls are valid Lisp programs. Function calls have a non-trivial syntax with rest, optional and keyword args, lambda functions, ... * special forms like CATCH, FLET, IF, QUOTE, SETQ, ... all have their defined syntax * macro calls, here the macro has to implement the syntax specified in the standard. users can do with their macros what they want. For example (if (foo-p) (this) (that) (these)) is a syntax error, though it is a valid S-expression. Similar (loop for i below 10 (print i)) is also wrong. Correct would be for example (loop for i below 10 do (print i)) So, what you may want is to remove the data syntax (s-expressions) from Lisp and replace it with some other layer of syntax that is not based on prefix parentheses-heavy s-expressions. There are lots of languages that have different syntactical approaches. Lisp has its own, which makes it slightly unusual (the syntax is used to support the code-is-data paradigm), less popular, but also makes sure that it will find its users - those users who want a language with a flexible syntax (one that can be extended by the developer) on top of a simple data syntax.

stcredzero 17y ago

So why not create syntax that catches 99% of the cases for which you intend the language to be used This just indicates the author is clueless about the substantive use of a DSL. The only way to implement this is to vastly reduce the scope of that "intend." Basically equivalent to, "all you really need is Blub." 80% would be reasonable. But the last 20% is going to encompass some powerful stuff.

Confusion 17y ago
I'm not really sure why you bring up DSL's, unless you consider something like Python or Perl a DSL as well. In that case: are you saying that, for instance, Perl is only useful for 80% of the cases for which that language is intended to be used?
- stcredzero 17y ago
  Nope. You can "do it all" in any Turing-complete language. But you can often do it more elegantly with a DSL. Once a language reaches a certain threshold of power, making a DSL is indistinguishable from ordinary coding. It's obvious the author hasn't a Clue about that.
  - Confusion 17y ago
    The point of the article was that creating a sufficiently powerful language, that doesn't offer easy ways[1] of extending the syntax, does not warrant the criticism that the language has 'too much syntax'. If anything, it demonstrates the power of being able to create syntax. I don't understand how your comment relates to that point. [1] Of course you can "do it all" in any Turing-complete language, but theoretical possibilities are often much less interesting than practical impossibilities. In Python or Java, creating new syntax is so hard it might as well not be possible.
    - stcredzero 17y ago
      Exercise for the student -- find the contradiction here: The point of the article was that creating a sufficiently powerful language, that doesn't offer easy ways[1] of extending the syntax, does not warrant the criticism that the language has 'too much syntax'. Evidently, you are as inexperienced with DSLs as the author. Of course you can "do it all" in any Turing-complete language, but theoretical possibilities are often much less interesting than practical impossibilities. In Python or Java, creating new syntax is so hard it might as well not be possible. Insufficient knowledge is probably why you mistook the sense of the statement you are replying to by 180 degrees.

alec 17y ago

"So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax?" Because then I've got a syntax that works for 99% of the use cases you've already thought of, and that doesn't overlap very well with the use cases I have or that either of us will come up with in the future.

anamax 17y ago

As I commented, get back to me when you've got a non-lisp syntax that doesn't result in bugs from precedence/associativity errors. If infix was actually "natural", there'd be only one set of precedence/associativity rules and there wouldn't be bugs due to folks getting it wrong. With very few exceptions, folks use parentheses to try to protect themselves from their ignorance of their language's precedence rules. (C++ has over 10 levels of precedence.) Even then,they occasionally get it wrong. And, it's worse than that on teams because different folks have different knowledge (and illusions) of the precedence rules.

l0stman 17y ago

You can't expect people to be reasonable when it comes to language flamewar. Personally, I think weak advocacy is worse than no advocacy at all. So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax? Although it's possible to create new syntax in Common Lisp via reader macros -- I don't think lispers recommend to extend the syntax. But when you miss a language feature, instead of fighting against the language, you could implement it. I don't remember exactly who said it in one the SICP video lecture, Harold Abelson or Gerald Sussman, but he said something like Lisp is not good at solving a particular problem. What Lisp is good at is extending the language to solve a class of problems. The problem with syntax is that it's difficult to use correctly with macros. It's no wonder that most introduction books to C warns against the pitfalls of using macros. Even the simple ones could bite you if you're not careful. Consider: #define DOUBLE(x) (2*x) /* should be (2*(x)) */ #define MAX(a, b) ((a) < (b) ? (b): (a)) Even the last one is not immune against multiple evaluation problems if you try to evaluate MAX(a++, b). In Lisp you could avoid this by using gensym and local bindings. That being said, C macros and Lisp macros are completely different beasts. And I recommend reading ``On Lisp'' for advanced use of Lisp macros.

kls 17y ago

Barring the complaints about syntax and the assumptions made in the article, I would still say the one reason someone should learn LISP is that most likely one will have an entire career of writing logic the "other way", I am not disparaging the "other way", just stating that it is far more prevalent and if you are learning something for personal growth LISP will give you a more diverse perspective than using a language that is an evolution of the "other way".