51–60 of 276 posts
Earlier quoted context omitted.
Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
How would you write f((x y)z) in Haskell?
Earlier quoted context omitted.
This was back in 1983 where most (all?) other languages did not have first-class procedures. If you can imagine programming without them and then being exposed to that, it would be a big deal. We take them for granted today.
Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...
The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…
8 - It has consistently lost in the marketplace in the last 20 years. We had most top CS grads in North America groomed on SICP at one point in history. You'd think many of them would want to use Lisp in production. Many of them did. Now MIT uses Python to introduce programming, and Lisp code bases tend to be (horrifying) legacy systems. Virtually no startups base the core of their business on Lisp anymore, and it's not because the technical founders aren't aware of it.
(Lots of skunkworks Clojure projects are out there bearing load though.)
Earlier quoted context omitted.
This was back in 1983 where most (all?) other languages did not have first-class procedures. If you can imagine programming without them and then being exposed to that, it would be a big deal. We take them for granted today.
Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
That's a pretty subjective opinion... I don't have much trouble with lisp but Haskell makes my eyes bleed. Of course I'm not a Haskell programmer, so it stands to reason that those who are find its syntax enjoyable. To each their own...
For code that non-haskellers have to work with I would just write everything out which is what lisp does and probably results in better code. Otherwise there still is a balance, I think. Like
Lispy:
n n n Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature . If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.
Earlier quoted context omitted.
You left out a rather glaring objection: 7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page. [0] http:…
Yeah, this seems to be a common objection, but in my experience of actually having used a lisp (Clojure) in production, this was never a problem. Sure, you'll likely still end up with some technical debt, but no more than the Java project's we had at the same company. And not because of macros. When people first learn about macros, they go crazy trying to do all kinds of things that weren't possible without macros. B…
I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.
Earlier quoted context omitted.
Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.
Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
But golergka said that Lisp's syntax is the clearest, not the smallest. And while that's probably something that depends on one's knowledge and past experience, I think there's something to it. The parens mean that it's unambiguous, and there is very little work on the reader's part to figure out where an expression begins and ends.
There's no operator precedence to keep in mind, no special whitespace rules, etc. It's about as minimal as you can get while still being completely explicit about syntactic constructs.
I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.
The fact that we have "any language where functions are first class citizens" owes a lot to Lisp research.