Hacker News Reader

Comment by SFJulie | Hacker News Reader

I love how RMS always begin is war on language with "it does not have a LISP/scheme syntax".

University coders and their obsession of purity of syntax (map/purity) superior to actually dealing with the true problem of the hardware is looking (territory/practicality) is looking for me like an Aristolecian argument of superiority of the style over the «getting things done».

Well, as spotted in the answers, expect is a nice non university bred innovation (is it?) that is still a de facto standard in handling interactive session (stateful) with a simple syntax that helps getting things done with maintainable code.

It is ported in Perl, python ... and I think this is probably a point for what Tcl is worthy : getting things done.

Practicality beats purity.

And as of today it is still the most portable way to write embeddable graphical user interface that have good FFI.

View on HN

Lisp is close to syntaxless. What "lisp syntax" means is principled to the bones systems, including syntax. The fact that everything in lisp was in recursively defined lists meant you could reuse recursive thinking everywhere. An `infinite` tower of reuse. You get genericity, pattern matching, combinatorial generation for very low cost. It's not practical for people crunching data or opening files .. but whenever you need to attack something a little more complex the 'practicality' argument shift sides.

Well, if he meant "it doesn't have S-expressions", he should have said that. That's not an unreasonable expectation for a guy who is otherwise a pedant in almost all other areas of his life.

Fair point, and to be honest, it's a common problem in many places. People enjoying a property often fail to communicate it clearly with those who never did. Math, and I believe Lisp has many times more inherited math genes than other languages, is especially guilty of this. It's often a lethal cultural shock.

S-Expressions are fun. When I first learned a Lisp, Scheme in my case, I found them weird but could see the appeal.

When I learned Haskell afterwards, it was the opposite: I thought I'd miss S-Expressions, but I learned to like its more baroque syntax.

S-Expressions have the chief virtue of making even the most crude macro look no different from the most over-engineered builtin to the language from the user's point of view.

And they clearly separate the syntactical space in the language, so that new features (whether as macro or built-in) can always find a space. Compare to the cracks of C they had to fit C++ into.

Haskell might be even worse. The chief obstacle to adding OCaml or-patterns to Haskell (https://stackoverflow.com/questions/24700762/or-patterns-in-...) seem to be finding a syntax that's both pleasant and fits between the strands of the fine web in ascii space of already valid Haskell programs.

...And I never grew to like Haskell. The syntax makes all of your programs look very elegant, but there are no clear delimiters. The syntax for how functions are delimited isn't clearly explained by most sources. And I don't want to type my code and just hope that the magical compiler fairies deduce my meaning. That kind of programming attracts bugs like a man covered in honey.

I don't know what that means, but if the objection is to layout ("the off-side rule"), that's just an alternative to the braces and semi-colons that you'd typically use if it was machine-generated, for instance.

The objection isn't so much to the layout, as it is to the fact that I can't find any documentation as to what the layout is and how the compiler interprets it.

Interesting. I've never bothered to look up the formal specs, but it was never a problem that lead to an ambiguous interpretation of my programs. (I sometimes write programs that the compiler doesn't like. But seldom once that the compiler interprets different from me.)

I usually give types for my top level functions. It's good documentation, and also prevents most of these kind of issues. (For a similar example, human mistakes with operator precedence usually lead to compile-time type errors in Haskell, seldom to runtime problems like in C or C++.)

It's not a huge problem, but lack of understanding of how the compiler delineates blocks of code makes the code hard to reason about. I like to know what the compiler will do with my code, and what is and isn't valid through something other than trial and error. Scheme's perfect regularity makes that easy. Haskell... doesn't.

I am aware that the information exists somewhere, and I think I got a link a bit back, so I'll have to go track that down. But it is absolutely baffling that people don't discuss it more. Would you be able to write Python if nobody told you about the indentation rules? Of course not.

I'll have to find that link...

> And I don't want to type my code and just hope that the magical compiler fairies deduce my meaning. That kind of programming attracts bugs like a man covered in honey.

I wrote plenty of Haskell commercially (and for fun). Not once did we run into that problem.

> It's not practical for people ... opening files

Or in other words, being a "glue" language?

> It's not practical for people crunching data or opening files .. but whenever you need to attack something a little more complex the 'practicality' argument shift sides.

    (define (my-reader)
      (let ((c (read-char)))
        (when (not (eof-object? c))
          (display c) (newline)
          (my-reader))))

    (with-input-from-file "myfile" my-reader)

"not practical for people crunching data or opening files" in what way? It's been extensively used for crunching numerical and symbolic data, and I've no idea how opening files is an issue.

Lisps ain't particularly pure.. They are closer to the practical side of things.

RMS is of course a bit nuts, and perhaps living in some kind of ivory tower, but it's not the academic ivory tower.

I thought he literally lived in one of MIT's office/academic buildings rather than having an actual apartment?

Oh, I meant where he's living intellectually. But I think my perception of what classifies an academic is pretty skewed: I managed to code Haskell for money for the first five years of my career (now still sneaking it in at Google in my 20% time), and don't consider myself an academic at all.

Perhaps I also have a European bias here. After the war, the Americans got to play with their computers early on, and their academics ended up with Lisp. The European computer scientists had to wait, and thus had nothing better to do but think. They ended up with types and ML (the family that Haskell sprang from).

These days, it seems that the European tradition has firmly won in the most academic parts of computer science. Lisps are still around, and with Clojure have seen more mainstream success that ever before. But in Academia the only Lispers left standing seem to be the Schemers, and they have warmed up to static types, too. (They did some great work on contracts.)

Here he begins by saying that TCL, in effect, does have Lisp syntax (which "hackers" like) but that the regular non-hacker users will balk at it.

This part of his proclamation anticipates and softens the ironic impact of subsequently promoting a Scheme, further mitigated by in the same breath promising the availability of a parallel notation that will provide the blub syntax for non-hackers.

(Of course, he was right about a dual syntax approach being viable: today we have virtual machine environments with multiple languages. As a Lisp hacker, Stallman knew about the existing history of such practice, like CGOL for Common Lisp and whatnot.)

It wasn't RMS who wrote this post, it was a prank

It did later come out that Tom Lord wrote it, but not as a prank; he was working with RMS to build Guile, and this was the opening salvo in trying to build the case for it. RMS did post it under his own name.

Well, fake money is well done when it looks as good as the original :)

Just for saying I did not invent the lisp/scheme obsession directly from his web page[1] :

The most powerful programming language is Lisp. If you don't know Lisp (or its variant, Scheme), you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will see what is lacking in most other languages.

[1] https://stallman.org/stallman-computing.html

Lisp is still pretty damn practical. I can crank out working code far faster in Scheme than anything else. Because the mental model is so small, you focus more on your design than on getting it to fit your language.

And if you like TCL's command syntax, srfi-49[0], srfi-110[1], and srfi-119[2] all push scheme towards that to varying degrees.

0:http://srfi.schemers.org/srfi-49/srfi-49.html

1:http://srfi.schemers.org/srfi-110/srfi-110.html

2:http://srfi.schemers.org/srfi-119/srfi-119.html

Well RMS didn't go with a unix clone because it was what he wanted, but because he figured it was more likely to get to a working state. At his heart he is always an AI Lab guy, lamenting the demise of the lisp machine.

Tcl and Python (among many others) were also designed by "University coders". When it comes to language design, academic origins tend to have little bearing on how "practical" a language is.

In programming, that which you're calling the map is in fact the territory. The analog of a map is design documents: these indicate how the territory is going to be soon, or how it is.

In the physical world, we change the territory (e.g. alter the landscape, build). That's what is analogous to coding.

It is helpful for the territory and all of its manipulations to be clean and well-organized.

This is not just an "obsession" of "university coders".

The fellow who wrote Expect worked at NIST

Reply on news.ycombinator.com