News for hackers. Stuff that matters.
Re:Lisp's mysterious tuple problem by soberhoff on Wednesday July 12, 2017 @02:38PM (#14755251)
I don't think it's as easy as that. In fact there's probably no single reason accountable for Lisp's lack of popularity. Here's my own personal pet peeve: Declaring local variables creates a level of nesting. Local variables are a great tool for improving code clarity. Having to wrap your logic with `(let [value (...)] ...)` in order make a new local variable is unnecessarily painful.
Re:Lisp's mysterious tuple problem by kazinator on Wednesday July 12, 2017 @06:08PM (#14757100)
C only introduced the ability to mix declarations and statements in 1999, and not all compilers caught up with C99 right away.

By that time, C had long been a popular language, in spite of demanding that, just like in Pascal, local variables have to be defined at the opening of a new block scope, after which only statements follow.

This is actually a good idea; I avoid mixed declarations and statements in C programming.

Also, mixed declarations and statements are against the Linux kernel coding guidelines and are diagnosed. Yet countless people hack on the Linux kernel for fun and profit.

When I really need some tightly scoped local variable in C, I introduce a little scope with a new braced compound statement, just like `(let` in Lisp. This has the advantage that you determine where the scope ends, not only where it begins. You know: from line 27 this 75 line function, down to line 53, and that's it, not all the way down to line 75.

The mainstream dialect of lisp known as Scheme has a define construct which lets you create new scopes with local variables at the same level of nesting. (Scheme compilers transliterate these defines-s to nested let for you). Yet Scheme is not taking over the world. This aspect rarely even comes up as a topic.

Re:Lisp's mysterious tuple problem by papaf on Wednesday July 12, 2017 @04:48PM (#14756532)
Having to wrap your logic with `(let [value (...)] ...)` in order make a new local variable is unnecessarily painful.

You can have more than one value in a let and it typically does not cause problems. If you do find it causes problems, it is trivial to change the language and invent your own, expression for defining local variables.

Its fine to have your reasons for hating lisp, but if this is the only thing that puts you off, I recommend giving it another try.

Re:Lisp's mysterious tuple problem by soberhoff on Wednesday July 12, 2017 @08:02PM (#14757721)
I program in Clojure more than in any other language. That doesn't change the fact that I feel a stronger incentive to avoid local variables than in any other language I've used so far. Also if I wanted to tackle this issue with a macro I'd probably have to make an alternative to `defn`. That's a great way to invent a dialect of Clojure nobody else will be familiar with.
Re:Lisp's mysterious tuple problem by kazinator on Wednesday July 12, 2017 @09:26PM (#14758123)
In fact there's probably no single reason accountable for Lisp's lack of popularity.

There is this one: simple statistics. People have created an astonishing number of programming languages, of which only a vanishing minority are popular. If you pick a language randomly out of all of the ones that have been ever created, you will with a very high probability close to 1 land on something that is not used at all.

Given the age of the first versions of Lisp, it is astonishing that the descendants are still here and that there is a lot of resemblance.

Re:Lisp's mysterious tuple problem by soberhoff on Thursday July 13, 2017 @05:05AM (#14759810)
You're saying Lisp is amazingly popular when compared to esoteric hobby and research languages? That's not a particularly high bar.
Re:Lisp's mysterious tuple problem by lispm on Wednesday July 12, 2017 @08:24PM (#14757842)
In Common Lisp:

    (defun foo (a &aux b (c 1))
      (list a b c))
is

    (defun foo (a)
      (let (b (c 1))
        (list a b c)))
Re:Lisp's mysterious tuple problem by idyllei on Wednesday July 12, 2017 @04:05PM (#14756140)
The deal breaker for me is the unwillingness to rename outdated identifiers: `car` instead of `first` or `head` and `cdr` instead of `rest` or `tail`; the use of asterisks to show that a function differs in semantics (`let` versus `let*`); and the verbosity of using anything other than a pure list.

If I had to use a Lisp-like language, I'd choose Clojure so I can interoperate with the JVM. (I use Scala already, so I could interoperate with that, too.)

Re:Lisp's mysterious tuple problem by serichsen on Wednesday July 12, 2017 @05:07PM (#14756694)
Common Lisp has “first” and “rest” as aliases for “car” and “cdr” where it makes sense.
Re:Lisp's mysterious tuple problem by kazinator on Wednesday July 12, 2017 @06:15PM (#14757151)
I designed my own Lisp dialect that is very influenced by Common Lisp. It has the cadar functions down to five levels deep. They are awesome. I have about 17 years of Lisp coding experience. Only in the last few years, I have come around to using those cddr cadr and so on. They express the right thing when the subject is tree structure, rather than a flat list which contains items.

Suppose that we have used (cddr x) to test whether the list x continues after the second item. It is then unnatural to have (third x) to retrieve the third item! It is like "faulty parallelism" in your English essay. :)

If the condition (and (cdr x) (consp (cddr x))) holds, then the proper way to get that item is (caddr x). This is easy to verify: If cddr is a cons, then its car is given by tacking on an "a": caddr.

In any case, car, cdr and the rest are an absolute must in a Lisp dialect. They are instantly understandable; there is no good reason to break with this important convention. A Lisp dialect will not achieve anything by breaking cultural compatibility with other dialects in this regard; it will just be shunned by Lisp people yet still disused by everyone else. Although CAR and CDR come from IBM 704 machine language, which means nothing to pretty much anyone over fifty years later, the people who allowed these names to infect the higher level language weren't idiots. They discovered that the names just work and so used them. Borrowing some mnemonic that works from the IBM 704 is no worse than borrowing some equally arbitrary greek letter like lambda from a branch of mathematics. If the mathematics of anonymous functions had been called "Tau Calculus" we would be writing (tau (x y) + x y) instead of lambda; it's just a historic accident. All names are historic accidents: one person calls it water, another one aqua, a third one mizu.

I also love the star convention and have used it in many places. for instance mapcar* is a lazy mapcar: it can take infinite lists as its arguments and returns the resulting lazy list immediately. Leslie Lamport picked up on this star notation in LaTeX; that's where I first encountered it. When I got into Lisp years later it was like, hello, is that where Lamport got it from?

I don't like verbosity, so I made my dialect slick and ergonomic. It can "code-golf" side by side with the so-called "modern" scripting languages, while remaining clear.

Re:Lisp's mysterious tuple problem by lispm on Wednesday July 12, 2017 @08:25PM (#14757848)
Boah, Lisp has FIRST, SECOND, THIRD, .. REST since decades.