Lisp as an Alternative to Java (2000)

Yup, as I type ( and { and [ and " and manually close them in every other language and inevitably turn that stuff off if the IDE has it enabled. vim default has enough support -- when I type ) et al., it highlights the matching opening. Typing '%' in command mode jumps to the corresponding open/close bracket. Occasionally if I know I'm done with a function, and have a bunch of closing parens to insert, I'll use slimv's ctrl+x+0 to close them all for me. I'm a fan of rainbow parens which makes things nicer to look at too, but really, this Lisp meme becomes true after not very long: https://www.thejach.com/imgs/lisp_parens.png Or at least one tunes them out, just like one does with the syntactic noise in other languages. Editing them is natural.

Speaking of noise, here's some out of context JS code from the first random file I opened in a really old project:

              }
            });
          }
        ).on('error', function(e) { console.log('Error: ' + e); response.json({error: 'data_fetch_error'}, {}, 400); }).end();
      }).then(function(next, urlstr) { 

Yup, all of those () and {}s and commas and semicolons and single quotes were inputted manually. I say to my editors, "just let me type".

For Lisp, "sensible editor support" to me means something like slime support that enables REPL development. Lacking that in editors besides emacs (or not knowing about the support for alternate editors) has probably hurt adoption, sure, but I don't think the presence or absence of other editing tools that most every editor has (like keyword highlighting and other colors, auto-indentation, auto-completion, auto-bracket insert, intelli-sense stuff...) is a factor.

The Java community is going further in this direction, with the norm being empty jars to provide interfaces for libraries, with the implementation being brought by the application. Micrometer, opentracing, and Jax work this way.

> Why would they say this if they weren’t implying that NPM users can’t program?

I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp.

> You tell me.

I'm not sure what there is to say. The ASDF extension in question allows you to write systems that get loaded when a specific combination of other systems gets loaded, so when there's some room for collaboration of multiple systems, all such code naturally belongs into that autoloaded system. It can assume the presence of all required systems and hook them up together. Is this something like what you're describing? Except for the "discovered Micrometer on my class path" part of course since you're not concerning yourself with any paths here (that feels a bit brittle to me) but the notion of doing something special when combining specific multiple libraries is supported on system loading level.

> I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.

How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient. (That's a snarky point, admittedly, but there are a lot of libraries in various languages that are just built-in functions in Lisp or Python or whatever, and there's a scale of effort there between built-in functions, built-in standard library, etc. that influences the pressure to make and share libraries. Like, I once wanted to get an approximate fraction, like Python's fractional's Fraction.limit_denominator, but in JS I had to bring in Google's Long.js and then steal a hundred lines of code from Python's implementation and elsewhere. There might be a library now.)

Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source, and then having armies of programmers forced to use it who inevitably end up making and sharing libraries and frameworks to make their lives better and eventually a desirable place to be for lots of things. J2EE and the JCP/JSRs were also masterclass social innovations to improve the ecosystem and take over enterprise and allow groups to agree on specifications if not implementations. Lisp's version of that is still absent. At best there's functionality that implementations add beyond the ANSI spec, and differences papered over with trivial-blah libraries, and occasionally some informal lobbying will get a feature implemented with the same protocol across each active implementation (package-local nicknames coming to mind as a recent one). Of course this situation isn't that different to a lot of other language ecosystems.

CL got quicklisp, much too late, but it's here now and provides a baseline experience to beat if someone wanted to try like has happened in Java with ant/maven/ivy/gradle/etc. CL is then just missing hordes of programmers, and is unlikely to get them without either big company backing, many more small companies using it (this seems to be the way it's slowly been improving in popularity in the last several years), or an unexpectedly popular application domain (perhaps with accompanying hardware) where using it and its tools provides the clear best-in-class experience, or even the only experience, good or not, as is the case for many things involving other languages.

The culture now seems to be "check quicklisp, if it's not there, roll your own, and share to quicklisp". Maybe some more effort needs to be made on "try to collaborate and improve if something is on quicklisp and not quite what you want but close" rather than making something brand new, but collaboration exists on quite a few projects, and Java has lots of overlapping libraries too, it's not that big a problem. If Lispers lost any of their "roll your own" enthusiasm, the logical endpoint when something's not in the quicklisp set is to give up and search for a library in another language. And if it doesn't exist there either? Your only option is to program it yourself or pay someone.

It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments. And that's totally fair, Java's a great ecosystem despite annoyances with the language (which a big IDE helps paper over). I just think painting the lack of an equivalent ecosystem as a consequence of "roll your own libraries!" culture is mistaken.

Actually yes. While there are a lot of different medical devices if you have an engineer who worked with that specific device before (not unlikely if you hire for that) will most likely have worked with the vendor library, but not with yours.

Yes, honestly, I love lisp, although my only claim to being a lisp programmer is that I'm the author of some emacs packages. But I have to admit that yes I've noticed a definite tendency for people in the emacs lisp community to be abrasive and difficult and not very friendly in open source work. I think perhaps more of them are in university-related jobs in europe and hence haven't experienced the wonderful fake friendliness of california tech companies.

No, it's a perfect comparison. If I do an art project, I might want to start from the very basics and want to do everything on my own. If I have work to do, a budget and a deadline, I use existing building blocks wherever possible.

I just imagine telling my boss I could do the job in a week in Python ... or I could use this amazing forgotten language that requires me to implement almost everything from scratch. But it will be totally worth it, some day, I swear!

You're right - at the single element level it's not that different.

But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs.

And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing.

The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.

> (...) although changing from print(x) to (print x) isn't that much of a deal.

Except it is.

One is just syntax you write to get compiler to emit code you can more or less predict at "write time" and the other is a data structure you can operate on and get to emit any code you want.

Most people I worked with on Common Lisp / Clojure projects never made the leap to treat the program as data structure. So it evidently is "a big deal".

The whole point of Lisp is to have your program be a data structure and then have a core language that is very good at manipulating data structures, so if somebody doesn't get it they are not really realizing benefits of Lisp and they would be better off in a poorer but more approachable language like Java.