Hacker News Reader

Comment by eggy | Hacker News Reader

Before Python became ML's darling, there was Lush: Lisp Universal SHell by none other than Yann LeCun and Leon Bottouk[1], and I thought my Lisp knowledge was going to finally pay off ;) I've since moved on to J and APL. SBCL is amazing and aside from calling C directly, it is still very fast. Python is slow without its specialized libraries from the C-world, but SBCL produces short, readable code that is pretty efficient. There ECL[2] for an embedded Lisp, or uLisp[32] for really small processors like the ESP chips.

[1] http://lush.sourceforge.net/ [2] https://common-lisp.net/project/ecl/ [3] http://www.ulisp.com/

View on HN

Why did it not catch on, though?

Python was already well known as a "scripting" and server-side web development language in the early 2000s, but it's commonly mentioned that it really exploded in the 2010s, where it was the implementation language for several scientific packages, most notably the machine learning eco system.

It seems that the language really found a local optimum that adheres to many different people across disciplines.

My vote is it is due to python being included in most base distributions. Combined with a ridiculously loose concept of dependency management, it is trivial to tell people how to get started with many python projects.

This doesn't really scale well, but momentum has a way of making things scale. Especially when most of the popular libs of python are pseudo ports of other language libraries.

Hard disagree. Python is a nightmare to get started with from a dependency management perspective. Its use in exploratory programming and for writing quick hacks to solve immediate problems is so popular because you rarely care about backwards compatibility or future proofing the deployment.

I think it caught on because the syntax is clear, the execution model has relatively few pieces of foot gun trivia to memorize, a really nice repl, and most importantly, almost no one doing exploratory work needs anything faster.

As a software developer, I fully agree with you. Having watched many science teams embrace python due to not having to install the base system, though?

That is, your complaint is what I meant about it not scaling. It is terrible. But the momentum behind it is keeping it going, despite being laughably bad in that area.

> Python was already well known as a "scripting" and server-side web development language in the early 2000s, but it's commonly mentioned that it really exploded in the 2010s, where it was the implementation language for several scientific packages, most notably the machine learning eco system.

That's...somewhat misleading. Python was well known for its scientific stack as well as server-side web development and scripting from the early 2000s (or earlier; NumPy, under its original name of Numeric, was released in 1996, BioPython in 2000, matplotlib on 2003, etc.).

In the 2010s, it became known for its machine learning stack, which was built on top of the existing, already solidly established, scientific stack.

Python makes it pretty trivial to load compiled modules as third-party packages, and given the core language itself is already implemented in a similar way, at least for CPython, creating numerical packages as thin wrappers around pre-existing BLAS implementations was probably easier in Python than in Lisp.

It might seem stupid, but operator overloading and metaprogramming features make it fairly simple to emulate the syntax of other languages scientific users would have already been familiar with. Specifically, NumPy, SciPy, and matplotlib quite obviously tried to look almost exactly like MATLAB, and later pandas very closely emulated R. It's a lot easier to target users coming out of university programs in statistics and applied math who have been using R and MATLAB and teach them equivalent Python libraries. Trying to teach people who aren't primarily programmers to use Lisp is going to have a much steeper learning curve.

It really didn't explode in the 2010s, either. You're thinking of Facebook with pytorch and Google with TensorFlow making it dominant in deep learning, but the core scientific computing stack goes back way further than that. As for why Google and Facebook chose Python rather than Lisp, I think it was just already one of their officially supported languages they allowed internal product teams to use. Lisp was not. Maybe that's a mistake, maybe it isn't, but it's a decision both companies made before they even got into deep learning.

Lush's heyday was the 01990s, and it's pretty much only useful for "scientific computing", which has a big overlap with "machine learning". Also, it's a Lisp. Python has more readable syntax and was used for all sorts of things even before Numpy existed.

> 01900s

Preparing for Y10K? That's exceptionally long-termist.

Can't even make an octal joke with that 9 in there...

Hey, 9 is an octal digit in K&R C!

I think we have to distinguish between languages that use s-expressions and lisps. Almost all languages have some sort of preprocessor that make it look like lisp but that doesn't turn it into lisp. From what I vaguely remember, lush lacked some of the defining qualities of a lisp.

"Lush" stands for "Lisp Universal Shell". It has not just S-expression syntax but recursion, setq, dynamic typing, quoting of S-expressions and thus lists and homoiconicity, cons, car, cdr, let*, cond, progn, runtime code evaluation, serialization (though bread/bwrite rather than read/print), and readmacros. Its object system is based on CLOS.

Lush is uncontroversially a Lisp.

However, the part of this that's relevant to the point I was actually making is that Lush uses S-expression syntax, which is less readable than, for example, Python syntax.

if lush were uncontroversially a lisp, I would have used it for at least one side project. IIRC things weren't that clear (back then when I stumbled over it) when looking at it in detail, which is why I decided not to use it (but don't ask me now why exactly).

But I have to ask, because I am curious what Lisp feature, that if missing, has you dismiss a language built to do a specific task you might be interested in. What were you trying to do then? Thanks!

I'm curious too!

In my lessons about scheme (given by the french translator of TAOCP), I have the following essential characteristics:

- static binding

- closures (true)

- tail recursion

- garbage collector

s-expression or typing is a matter of choice, but, IMHO, if you lack one of the four previous items, it is not really a lisp.

Emacs Lisp doesn't have tail call optimization, just like the Lisp it was inspired by.

I'm definitely not an expert in that area, but this list seems kind of arbitrary to me. Especially with s-expressions being optional, which are probably the widest-known feature of the language. According to that definition, Haskell is a "true" Lisp but at least 2 Lisps are not. That makes no sense to me.

The last sentence was from me. The four items are from the SICP (not TAOCP, my mistake). They all are mandated by IEEE scheme standard.

I have encountered many functionnal languages when I was student (caml-light (the ancestor of ocaml), lelisp, gofer (a cousin of haskell), miranda, graal, FP systems, yafool).

The typing may be dynamic or static. The evaluation may be strict or lazy. They may have homoiconicity or a more suggared syntax. All theses choices are valid. These languages have in common the list of fundamental properties. IMHO, this list of 4 items encompass many aspects of SICP. When I evaluate a language, this list helps me understand the qualities and limitations of a language. For example, Perl5 does not have a true garbage collector. javascript does not have tail recursion. Knowing these limitations, I will not code the same way. In Perl5, I will take care of breaking unused circular data. In javascript, I will reorganise highly recursive algorithms.

Almost every language can do tail recursion (in most languages it will blow the stack though) but not every language does tail call optimization. This is a requirement for scheme but it is not for common lisp and many other lisps. So, I don't think this should be on the list.

JavaScript does have tail recursion in the spec, and JSC (Safari) implements it. Other runtimes have thus far refused to because it can impact on debugging I believe.

I feel that static/lexical binding is more of a Scheme thing, though. The Lisp community used to be kind of on the fence on that for a while, even though it ultimately chose to go the same way.

Edit: And to be frank, while dynamic binding may be a horrible mistake in bigger projects, it sometime gives you exactly the easy way out that you may appreciate under time pressure. It's a classical case of "it seemed to be a good idea at the time".

Other than global variables, lisp-2 use lexical scoping …

Whether a Lisp is a Lisp-1 or a Lisp-2 is orthogonal to whether its scoping is lexical or dynamic. There are lexically-scoped Lisp-1s (like Scheme), lexically-scoped Lisp-2s (like Common Lisp), and dynamically-scoped Lisp-2s (like Emacs Lisp). Someone's probably written a dynamically-scoped Lisp-1 at some point, but I can't think of one.

Does Russell's original Lisp count as a Lisp-1? I guess it probably had a common namespace for functions and values.

It's an interesting question; maybe he remembers. If it was a Lisp-1 when originally implemented, it became a Lisp-2 within the first year or two, using different properties of atoms (symbols, as we say now) to evaluate them in "function position" than when they weren't. I suspect he might have made that change before he got it working at all because of properties like FSUBR and FEXPR.

It was definitely dynamically scoped, though.

So it did. But not without controversy. And consequently, there's still defvar. Emacs Lisp is binding dynamically by default to this day, iirc.

It's extremely valuable in Emacs for the same reason it's questionable in other contexts. It lets one person reach out across any scope distance and tweak behavior. Which is exactly what you want when you're configuring your text editor. And exactly what you don't want when you're writing a program for other end users that multiple people are working on.

Emacs Lisp will, I expect, never ever drop 'defvar' dynamic binding. It would break the entire world -- it's relied on far too widely to revoke. Having lexical binding alongside as we do now is probably sufficient.

You mean dynamic scoping and lexical scoping. Dynamic binding is something different; a dynamically-bound subroutine call may call different functions depending on runtime state, for example because it's indirected through a function pointer, for example in the class vtable of a method call receiver.

I agree that it's useful to be able to locally override variables like deactivate-mark and case-fold-search. (This kind of thing makes tail-call elimination more difficult: any dynamically scoped variables must be restored when the "tail-called" function returns.) But there are some other such things in Emacs that can be similarly locally overridden and then restored, but aren't variables: (current-buffer), (point), and (mark), for example, which can be restored with (save-excursion ...). And it's common to have such locally-override-and-restore facilities without using linguistic dynamic scoping for it; PostScript has gsave/grestore, for example, which were copied by Win32 GDI SaveDC and RestoreDC, but that doesn't give C dynamic scoping.

I don't think SaveDC and RestoreDC are known to give rise to problems when "writing a prgoram for other end users that multiple people are working on".

I agree that elisp will never remove dynamically-scoped variables; it would break compatibility with all existing code. Even Common Lisp has "special variables" that behave this way.

I mean, yes, you're not wrong, but the terms within Emacs itself for these features are dynamic/local "binding":

https://www.gnu.org/software/emacs/manual/html_node/elisp/Dy...

https://www.gnu.org/software/emacs/manual/html_node/elisp/Le...

Thank you for the correction; I did not know that. I can complain about the elisp maintainers using an established term in this confusing way†, but I shouldn't have claimed that your use of it was wrong; if you're discussing a particular program, it's better to use the canonical terminology used when talking about that program, even if it conflicts with usages in other contexts.

______

† Older versions of the Emacs Lisp reference manual mostly did not do this, except for one occurrence of "dynamic binding" in the "implementation of dynamic scoping" section.

Dynamic scoping relies on a form of dynamic binding: namely the dynamic binding of a symbol to its current value.

That's outside the standard meaning of Alan Kay's term "dynamic binding," which originates in a different meaning of "binding", namely, "linking object files (into an executable or other form of memory image)". The Mesa linker, for example, was called the "binder". These conflicting meanings of "binding" make for a good pun or joke, but I think there are people trying to read this discussion in all seriousness to understand the linguistic issues, and the pun could confuse them.

It happens that in ordinary Lisps†, the function called by invoking a symbol does depend on the run-time value of a symbol (its function binding in a Lisp-2), and that's the sense in which an ordinary Scheme or (non-generic) Common Lisp function call can be said to be "dynamically bound", but that isn't the case in general. So even in that sense it doesn't correspond to the static/dynamic scoping distinction that they seem to be trying to discuss.

______

† I think this may be one of the points where Lush is atypical; I think its interpreter supports runtime rebinding of the function bindings of symbols, but its compiler doesn't. I'm not sure, though. I may not have used Lush this millennium.

The Lisp term "dynamic" means "stack-like LIFO discipline". "Dynamic scope" is a shorthand that refers to "indefinite scope with dynamic extent", where "dynamic extent" refers to the bindings being tied to stack-like frames, such that they are torn down then constructs terminate.

When we "declare dynamic-extent" an object, the compiler may stack-allocate it.

The C language redefined "dynamic" from "stack" to "heap". If you look into the BCPL manual (one predecessor language that inspired Ken Thompson's B), it uses "dynamic extent" to refer to the stack, which C renamed to "automatic storage":

"[T]he extent of a dynamic data item starts when its declaration is executed and continues until execution leaves the scope of the declaration." (1967 BCPL Manual, 7.2)

I agree. Thank you.

MACLISP, Interlisp, Emacs Lisp, AutoLISP, Franz Lisp, and Lisp 1.5 lack all of these except the garbage collector*. Common Lisp and International Standard Lisp additionally have static scoping and consequently closures. Those are essential characteristics of Scheme, not of Lisp.

______

* I'm assuming by "static binding" you mean static scoping; if you actually mean that the association between callsites and functions is statically computable, then it's not even true of Scheme.

I believe Python won because of its popularity in academia.

I am using J on and off, but I am not aware of a ML package for it. Are you writing all algorithms yourself or could you recommend a package?

I have a bunch of links to ML material for either APL or J. I don't know of any particular library for J. J is interpreted, so it is not as fast as other implementations. I am mainly using it to experiment on concepts and teach myself more ML in J because of the iterative nature of the REPL, and the succinct code. I can keep what's going on in my head, and glance at less than 100 lines, usually 15 lines, of code to refresh it.

There is a series of videos of learning neural networks in APL cited by others here on this thread.

Pandas author, Wes McKinney, cited J as an influence in his work on Pandas.

Extreme Learning Machine in J (code and PDF are here too):

https://github.com/peportier/jelm

Convolutional neural networks in APL (PDF and video on page):

https://dl.acm.org/doi/10.1145/3315454.3329960

A DSL to implement MENACE (Matchbox Educable Noughts And Crosses Engine) in APL (Noughts and Crosses or Tic-tac-toe):

https://romilly.github.io/o-x-o/an-introduction.html

> J is interpreted, so it is not as fast as other implementations

Which implementations are you comparing J to? To my knowledge, all of APLs, K, J are interpreted. BQN is compiled, but still very new. I also know that Dyalog was experimenting on a byte code compiler. I don't think there exists convincing benchmarks comparing those languages.

Yes, not clear on my part. I meant to other ML languages, not other array languages. It's amazing the speed you get from J as an interpreted language; it's been honed by a bunch of clever people over the last few decades.

There's a handful of resources around that look fun though I haven't dug into them yet.

There's this on the J wiki: https://code.jsoftware.com/wiki/User:Brian_Schott/code/feedf...

And there's this YouTube series for APL: https://youtube.com/playlist?list=PLgTqamKi1MS3p-O0QAgjv5vt4...

I'd also like to know. I'm considering writing some for fun in GNU APL right now.

Reply on news.ycombinator.com