Hacker News Reader

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions.

Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to change it because it simply works!

You're trying to justify a new wave of "modern" languages with a very weak argument... just call it for what it is: you want "cool", hyped languages to succeed despite the fact they offer nothing that the CL standard did not 20 years ago.

This type of response is also why Common Lisp isn’t more popular. :)

Having a standard has little to do with how people write code, which is what I meant by idiomatic conventions.

Elixir is not a “cool, hyped” language in the sense that you mean. Elixir is basically a wrapper around Erlang and OTP, which is an old technology (much older than ANSI Common Lisp), that provides several improvements in terms of developer tools and frameworks. It’s not just the next “cool” thing. It’s an incremental improvement on an old and tested technology to bring that technology to more developers. It has also been embraced by the Erlang community.

> This type of response is also why Common Lisp isn’t more popular. :)

What does a response from a blunt commenter like me has to do with the success of CL? Do you mean CL users are prone to responding like me? I would say users of any language that's being dismissed as being old would react similarly.

> Elixir is basically a wrapper around Erlang and OTP

Yes, I know, I was going to say that Elixir itself is nothing new as it's just Erlang with a more palatable syntax on top... nothing really new, Erlang is about as old as Common Lisp.

I'm not dismissing Common Lisp. I've actively searched for and applied to jobs that advertised using Common Lisp.

I just don't see the Common Lisp community rallying to make it more cohesive (and thus more popular and attractive), which is fine, but it means it won't get used outside of enthusiasts bringing it into niche pockets of companies. I have the same complaints with F#, which is one of my favorite languages, because there are just too many libraries/frameworks that are just one-off side projects of a single developer. (There are of course separate reasons for F#'s lack of uptake.)

If the entire Common Lisp ecosystem is as good as people say it is, then I don't see why it couldn't go through a path like Erlang did with Elixir and even so without a syntax change (just a nice bundling of the ecosystem and tooling) instead of just relying on war stories of its use and telling people they just don't get it.

it might be that convincing people to switch to common lisp is a lot like convincing people to switch to linux from windows. is it possible that there might be people who do not care much about ready-made tools or frameworks and enjoy engineering solutions from a more fundamental level? i think those people definitely exist and i personally rather enjoy hearing their war stories

In fairness, the CL spec being quite old, has a fairly dated type system.

Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this

this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1]

[0] https://github.com/JuliaGPU/CUDA.jl

[1] https://github.com/takagi/cl-cuda

> this is not the job of compiler writers

Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together.

> in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0].

This is mostly false.

First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust.

Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary.

If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').

why do you presume that's what the GP meant? your post is much more detailed than his

anyway, i know very well that julia has a great standard numerical library. it is a language catered to that community so it better have a rich standard library. my point is that functionality does not need to in the standard library in order to be useful or impactful. i don't think i need to prove my point but take numpy (or any other famous numerical package from the python ecosystem) as an example

>Second of all, CUDA.jl is a very weird thing to point to for your example

i work in machine learning so it is a very important package for me

> If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that

and CL is not. point is that you need to learn LLVM in order to dig deeper, if you so wish

The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to).

Versus Python, I didn't even get to use Python 2 before I started getting nagged and harangued by various exceptions in the terminal about how I had to migrate to Python 3.

And it depends what you're doing with CL, how well it works for you. As an algorithm designer, I use literally no libraries. I don't glue anything to anything. I just use the batteries that come included with Common Lisp (SBCL is great), forget about connecting to the internet, forget I/O, forget graphics and GUIs and OOP, and just focus on coming up with as many ideas as I can per minute, until I crack the algorithmic problem. Just with the austere tools that come included in SBCL: xor (#'logxor), popcount (#'logcount), #'sort, #'svref, #'pop, #'push, #'make-array, #'dotimes, 'lambda, 'labels, 'let, 'do, the basics.

I can't think of any code rot either. As long as it is built against the standard it tends to just work.

I also find the idea of using no libraries a big thing in more advanced users of CL. The more advanced of a user the more it makes sense that you can just implement it yourself (with only the functionality required) and know it works without having to leverage a library. Then again, the idea of CL is that things that tend to be bigger/harder to solve problems in other languages can be done simpler in CL because you can break the problem up different and have an easier to understand or implement solution.

I'm not exactly a Lisp fan (I'm firmly in the statically typed camp), but this is a weak argument. Common Lisp specifically is one of the most cohesive experiences one can find out there, the language has had a long time to mature, it's ANSI standardized and the ecosystem is largely built on top of that cohesive base.

mmh Elixir definitely has its gems and I need to try it for real. Where I can see it's lacking: no compile-time type warnings (unless you're using a new language on top or using a third-party library, but then we should compare more thoroughly), no compilation with a keystroke function per function. No static executable (even though deployment options are getting better in Elixir (we had to wait though)). Some compilation times, when you change one file and Elixir needs to compile a dozen. We are not inside a live image. I tried Alchemist mode for Emacs: no function signature? No "eval this expression"? Can you switch projects from inside a REPL, or you have to start a new one? No cross-reference capacities built-in? (who calls this function, this macro, who sets, etc) No inspect? No trace? No interactive debugger and no stepper? If only available with LSP and VSCode, then it's strictly inferior. Elixir is less performant in crunching numbers. Less to no GUI framework choice (WxWidgets). No industry-grade theorem prover? (ACL2) Unfit for quantum computing? Unable to program Intel chips? (Barefoot Networks) No computer algebra system? No music composition suite (Opus Modus)?

CL's ecosystem might be better than one thinks: https://github.com/CodyReichert/awesome-cl & https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...

There was one cohesive tribe in the 00s centered around the quasi-annual European Common Lisp Meeting. I miss that and wish I could find the same thing again now. Maybe it exists somewhere online?

The ELS community is still going strong. They have done a great job with continuity and moving forwards. That's a related but different tribe though.

can you write compilers in elixir ? how does its interactive programming compare to that of Lisp ?

I don't claim that Elixir is the language to end all languages. My comment was more about the holistic ecosystem that keeps improving. There's one common development and project management tool (Mix). There's one package manager (Hex). There's OTP, Ecto, Phoenix, Liveview, etc. There's the Elixir Forum for questions.

I'd use F# for writing compilers.

Interactive programming is probably better in Common Lisp and also Smalltalk descendants like Pharo. But Elixir has some great interactive tooling. I think this is an excellent presentation that summarizes the capability (not necessarily saying other languages don't) in terms of real world applications: https://www.youtube.com/watch?v=JvBT4XBdoUE

> I don't claim that Elixir is the language to end all languages.

i don't know much elixir. i was asking because those things interest me and they are what drove me to common lisp. for my purposes i need an industrial fast interactive language that is self hosted and well tested in the wild. i want a fast language that is well suited to make custom symbolic computer algebra procedures, custom differential algorithms, custom probabilistic programs, and custom data processing solutions. i think that common lisp best fits the criteria for my use case