Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

Post reply on HN
Print view View original

11–20 of 126 posts

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#11

Post by dmos62 »

nonbirithm wrote: post #3

I kind of wish there was a lisp with the "recompile on error and continue" feature of Common Lisp but without a massive standard library. A standalone SBCL program seems to be around 40MB at minimum. It feels like it would be doable if only CL wasn't designed with the kitchen sink included. Recently I've gotten into Janet[0] and really like the language, although I do miss CL's recompilation magic at times. It feels…

> recompile on error and continue

I'm not familiar with this. Anyone care to explain?

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#12

Post by FPGAhacker »

mindB wrote: post #10
FPGAhacker wrote: post #6

Earlier quoted context omitted.

You might find Fennel interesting: https://github.com/bakpakin/Fennel It's a lua based lisp. Technomancy of clojure fame has taken a shine to it and become a large contributor.

If it's the same project I'm thinking of, Janet is actually by the same developer as fennel. Janet was kind of his followup project to fennel.

That's interesting, you are right, same person.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#13

Post by momokoko »

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful.

But they did not achieve widespread adoption.

Widely used languages need to apply to a wide range of use cases. For example the fat arrow(=>) class syntax that binds this.

    class Foo {
      bar = (baz) => {
        // do something
      }
    }
For entry level JavaScript developers working in React, this made one of the most common hangups go away for them due to the automatic binding of `this`. But for a some other situations, that might end up an anti-pattern.

That's always the issue with small, clean implementations. They work when they only apply to one domain. Once they need to be used for different things, they then need to add new features. It is no different for software, blenders, bicycles etc. Once something is used for multiple domains, it now needs to become larger and more complex. Its basically a rule of nature.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#14

Post by xenophonf »

lispm wrote: post #5
nonbirithm wrote: post #3

I kind of wish there was a lisp with the "recompile on error and continue" feature of Common Lisp but without a massive standard library. A standalone SBCL program seems to be around 40MB at minimum. It feels like it would be doable if only CL wasn't designed with the kitchen sink included. Recently I've gotten into Janet[0] and really like the language, although I do miss CL's recompilation magic at times. It feels…

SBCL's programs are 40MB because they contain all dev tools and the code is native code, which is also large. There are a bunch of Common Lisp implementations which are smaller (CLISP), can create small applications (Lispworks), can be embedded (ECL) or can compile to smallish C code (mocl).

Just clang on my system is around 80MB, so when you consider that an SBCL image includes a compiler, a linker, and a loader—and if you have Quicklisp installed, a build system and a package manager—40MB starts to look like a bargain!

I personally wonder if CL's "computer program as an image" instead of the Unix process-oriented architecture will see a comeback in this modern era of virtualization and rump kernels and containers. In theory a Docker image for an SBCL program would be just the Lisp image itself plus the small handful of standard POSIX libraries on which the Linux version of SBCL depends (e.g., libc, libm, libpthread, etc.)

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#15

Post by protomyth »

momokoko wrote: post #13

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. But they did not achieve widespread adoption. Widely used languages need to apply to a wide range of use cases. For example the fat arrow(=>) class syntax that binds this. class Foo { bar = (baz) => { // do something } } For entry level JavaScript developers working in React, this made one of the most common hangups…

Pascal was pretty popular. Turbo Pascal sold a lot of copies for good reasons.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#16

Post by threatofrain »

> Once a language gets beyond a certain complexity — say LaTeX, Common Lisp, C++, PL/1, modern Java — the experience of programming in it is more like carving out a subset of features for one’s personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning.

This is how I felt about Racket, and I felt I had to do an opinionated pruning before I could use it for teaching, but the problem is that the docs don’t have such a boundary for learners so you feel tempted to rewrite the docs.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#17

Post by stcredzero »

momokoko wrote: post #13

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. But they did not achieve widespread adoption. Widely used languages need to apply to a wide range of use cases. For example the fat arrow(=>) class syntax that binds this. class Foo { bar = (baz) => { // do something } } For entry level JavaScript developers working in React, this made one of the most common hangups…

But they did not achieve widespread adoption.

That's always the issue with small, clean implementations. They work when they only apply to one domain.

Sorry, but this is pure BS with regards to Smalltalk. I worked for a Smalltalk vendor for 5 years, then consulted in the language for several years after that. I had a front row seat to these issues. Having a small language does not make it suitable for only one domain. The primary reason for Smalltalk not achieving widespread adoption was due to a series of decisions which, in retrospect, were highly anti-adoption. It started with no operator precedence in the language design, which acted to alienate engineers and scientists. Then the industry went through a "we're the boutique language of the Fortune 500" phase with $5000 and $10000 per-seat licenses.

It is no different for software, blenders, bicycles etc. Once something is used for multiple domains, it now needs to become larger and more complex. Its basically a rule of nature.

That just doesn't work for software. The reason why Python is so popular with certain scientific communities isn't at all specific language features to support them. It's general utility plus specific libraries. The reason why Smalltalk got popular at one time in finance and energy trading didn't have anything to do with specific language features or libraries. It was purely rapid development!

There is something which a small language can be prone to: fragmentation. It was so easy to roll your own Smalltalk. This, combined with a toothless language standard meant that the community got balkanized into multiple communities with incompatible code.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#18

Post by gmfawcett »

threatofrain wrote: post #16

> Once a language gets beyond a certain complexity — say LaTeX, Common Lisp, C++, PL/1, modern Java — the experience of programming in it is more like carving out a subset of features for one’s personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. This is how I felt about Racket, and I felt I had to do an opinionated pruning before I could use it for teac…

Last I checked, Racket literally has sublanguages defined for teaching and learning: "Beginning Student", "Beginning Student with List Abbreviations", etc.

https://docs.racket-lang.org/htdp-langs/index.html

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#19

Post by sdegutis »

momokoko wrote: post #13

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. But they did not achieve widespread adoption. Widely used languages need to apply to a wide range of use cases. For example the fat arrow(=>) class syntax that binds this. class Foo { bar = (baz) => { // do something } } For entry level JavaScript developers working in React, this made one of the most common hangups…

For what it's worth, that class-field syntax proposal never settled well with many JavaScript and React developers, and now that Hooks are out, a significant number of us have abandoned class syntax altogether in favor of functions with hooks. (There are other proposals that add to the class syntax that overall just don't seem to mesh well together and seem to create as many issues as they solve, like #private_variables, and the @decorators.)
Post reply on HN