Hacker News Reader

>Common Lisp is about on a par with Python in what it has built in, inferior in its ecosystem

about 20x+ faster than Python, too; speed in the same order of magnitude than C.

>and for some modern stuff (threads, sockets)

pretty amazing you bring out threads in this comparison, when Python doesn't even support true multithreading.

>Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code.

It's the other way around. Lisp macros allow to eliminate boilerplate and produce clearer code. This is obvious to any lisper.

For reference, I'm not holding up Python as a good language, I'm holding it up as a comparable one. Python is warty and creaky, but more mainstream than CL, so it's a fair comparison.

A good language would be Go.

>Python is warty and creaky, but more mainstream than CL, so it's a fair comparison.

How can it be a fair comparison, when Python isn't even a real functional language? (lambdas have been intentionally crippled, there is a separation between statements and functions, not everything is an expression, and so on...)

Because that doesn't matter. It's "about on a par" as I said. More in some places and less in others.

As a Common Lisper (among others) interested in language design, I've just started reading up on Go, after I've been told it's "simple, robust, safe, well-designed".

Purely subjectively, alot of what I'm seeing in Go so far looks to me like a "2nd system design" for C programmers. I'm hoping that the concurrency model is where it shines through with some good new ideas and implementations because I've been relatively unimpressed with the rest of it so far. That's not to say it's bad per se, but I've seen nothing in it that makes it stand out from other languages design-wise, and it feels rather warty to me so far...

Purely my own subjective opinion.

> looks to me like a "2nd system design" for C programmers

That seems fairly accurate.

> I'm hoping that the concurrency model is where it shines

I'd say that channels aren't quite the magic thing they are made out to be and goroutines aren't that amazing. The real win of go for me is three things:

1. Evented runtime with a synchronous interface. "Go is my favorite epoll library"

2. A standard lib that has great http support (things like keepalive and connection pooling and http2)

3. A build and test toolchain that makes coverage and race detection and memory and CPU and lock contention profiling trivial.

Go was designed by strong programmers as a “good enough” language aimed at the combination of two goals:

1.) Letting good programmers get things done without feeling too many constraints, and without hating the output of #2.

2.) Enabling decent programmers understand the output of #1, while still getting things done themselves.

It is an extremely practical language ‘project’, in that it doesn’t pretend that all programmers are great, or average, and it tries to help the two subsets work together.

Nothing about go the language is objectively good. The language design is spartan and procedural. The type system is a train wreck. The headline "goroutines" usually have to give way to the arcane arts of locks and mutexes. Google has poured hundreds of millions of dollars into the language and compiler. The ecosystem is objectively good, but the language is not.

For a point of comparison, let's look at StandardML as a language that I believe is objectively good, but with an ecosystem that is objectively not good. The type system is amazing. The syntax is as simple as go (designed to be easy for students to implement), but more powerful. Unlike "goroutines", CML (concurrent extensions to SML) are sound and actually work. Most of the headliner features debated in go 2 are already present (with ones like parametric polymorphism having extremely elegant solutions baked in). The compilers (eg, polyML or mlton) even spit out extremely fast code.

Without a Google-level backer, SML just sits there kept alive by a small group of academics who work on the parts that interest them and their research. If even a fraction of Google's resources dedicated to Go were put into the SML ecosystem, golang would have never come to be.

My point is that why a language succeeds or fails is seldom related to the actual merits of the language itself. Almost every one of the most popular languages has one or more corporate backers with deep pockets who made it what it was then maintained it going forward. Consider that Rust at its core is a complex, C-like syntax on top of SML, but had a company willing to pour millions into developing the language.

Lisp lost what backers it had due to the AI winter killing them off. Nobody else stepped up, so the language languishes.

... and OCaml gives you most of the benefits of SML plus a reasonably sized ecosystem.

Agree fully on your review of Go.

IMO, Go as a language is one of the worst languages ever created. You can argue about its runtime, but the language itself is horrible.

> It's the other way around. Lisp macros allow to eliminate boilerplate and produce clearer code. This is obvious to any lisper.

I don't have any particular experience with Lisp macros, but my experience with the closest equivalent in every language I've experienced them in is very different from your experience. For the person who wrote the system, it's a clean and expressive way that eliminates boilerplate. For everybody else, though, it's an underdocumented mess of magic incantations with some mental notes of "don't try to combine these things together, it will blow up," and if you ever have to debug a problem in the macro itself, you're going to find it to be a royal pain.

>I don't have any particular experience with Lisp macros, but my experience with the closest equivalent in every language I've experienced them in is very different from your experience.

Yes, because the way metaprogramming is achieved in other languages is very different than the way it is done in Lisp, thanks to s-expressions.

>and if you ever have to debug a problem in the macro itself, you're going to find it to be a royal pain.

Yes, because you're not dealing with Lisp macros.

If i'm looking at a Lisp source code, and there's a macro invocation, and I want to see what this macro is going to do to the code,i just press a key, and I can immediately visualize, in-place, how the source code gets transformed.

A big part of the standard library of Common Lisp itself is implemented as macros too, it's no big deal. Dealing with others' macros has no particular difficulty in Lisp; or in any case, no additional difficulty to dealing with others' functions.

From what I understand, the Rust procedural macro system should basically be similar in structure to Lisp macros, much closer than any other language I've used. It still has all of the aforementioned problems, in my experience.

Racket (which admittedly is a particular Lisp) has a very useful tool which lets you view each basically debug macro expansion by viewing each code transformation. This tool is even built into Dr. Racket so it doesn’t need any complex setup.

I’ve written both procedural Rust macros and Racket. Racket is far easier to debug and write macros compared to Rust despite their macros having similar features (in particular source locations and doing macro evaluation as a compilation step rather than at runtime).

Macros are just another form of abstraction, like functions. And like functions, they can be poorly named or poorly designed. Somehow the possibility of suboptimal use is frequently paraded around as an argument against macros, but seldom heard as an objection to functions.

(Also, macro systems like Racket's syntax-parse facilitate the creation of macros that fail gracefully with nice error messages.)

When the problem domain needs a novel control structure, and I can't write a macro, I have to try to expand the macro in my head and then you have to read boilerplate and infer what I meant.

> about 20x+ faster than Python, too; speed in the same order of magnitude than C.

I think this is exactly into parent thread's point: yes the performance can be great but you need to tail the code for the hardware, which is niche and the beautiful abstraction might never hold anymore

>but you need to tail the code for the hardware, which is niche

Not really.

You just need to declare the data types (Common Lisp supports type declarations) and tell the compiler you want the code to be fast, which reads just like that:

(declare (optimize (speed 3)))

You also need to use the same tactics you would use in C to gain speed: Use arrays instead of lists, use threads. All of this is easily doable in Lisp and IMO while it takes more effort than writing typical Lisp code, it is easier than using C and the end result is more elegant and debuggable.

This is not hardware dependent, mind you.

This is really depending on your view, but the moment you step outside of lists and use arrays, you are keeping modern CPU architecture in mind. And all of a sudden all those wonder car/cdr/cons concepts as well as things built upon it no longer holds, which, again depending on the view, actually harms the abstractions in Lisp, and we are actually back at the same page with all the other programming languages.

Also, when you are promoting something, it might not a good idea to compare against Python when it comes to speed, but when talking maintainability, only C is talking as a target here.

>Lisp's one big selling point is macros.

Maybe not quite as big of a selling point, but lisp has also always been the best environment for writing programs that need to modify themselves at runtime. Homoiconicity removes the limitation that code must be known and constructed at compile-time.

I can see good uses for that if you're programming a Mars rover.

On the other hand, you lose the concept of "known versions" with that, and I wouldn't want it anywhere near audited code.

And in most circumstances it suffices to stop and restart.

Yeah, it is definitely niche. However it is super cool to be able to do optimizations like constant propagation and loop unrolling using information that would never be available at compile time. For instance if you have a function that evaluates an argument and branches based on the value, and if for some other reason your program knows that after a certain condition the argument will always have the same value, it can just optimize away that branch while the program runs.

Now that is kind of contrived, but one real world example I ran into happened when I was writing a program to render 2d plots of complex functions. If you hardcode the equation of the function into the source code, the compiler can optimize it (important, since this function gets called for every pixel in the image being rendered) but the program is limited to rendering that one function. If you let the user enter that function at runtime in the form of a text string, your program has to essentially act as an interpreter by creating an AST from the string then walking the AST repeatedly for every single pixel, so obviously much more costly. The ideal solution is to have an environment where code can be seamlessly compiled at runtime and executed without extra ceremony or semantics that would be out of place in compile-time known code. In C you would have to attach a JIT to your program and manually write to an executable page etc, whereas in lisp the system handles all of that for you.

Another example happens with config files: Config file data is used for conditional branching, but since it only becomes known at runtime, your progarm ends up with a lot of branches that would get optimized away if the config info had been known at compile time. You could just make all the config data compile-time known by having a something like a massive config.h full of #defines, but this is obviously not user friendly at all and makes it necessary to recompile every time you want to change a setting. If your code is able to introspect and optimize itself based on data that only becomes available at runtime, this tradeoff is eliminated.

>And in most circumstances it suffices to stop and restart.

Only if your program is small and/or does trivial stuff.

In ordinary languages, there's a significant loss of time to achieve the following, once a bug is found:

- stop the running program

- correct the offending function

- recompile the program

- restart the program again

- interact with the program until you achieve the same conditions that caused the bug

- confirm that the bug doesn't happen again.

On a lisp system the steps are:

- correct the offending function

- re-compile the function (this takes milliseconds); this can even be done while other threads are running.

- restart the stack frame where the error condition was found, and immediately confirm that the error doesn't happen again.

The difference in productivity is remarkable.

It is inaccurate to call things like threading a Wild West of implementation-defined stuff. It is true these things aren’t de jure standard, but most important stuff has de facto standard portability libraries in Common Lisp. For threading, use BORDEAUX-THREADS. For filesystem operations, use UIOP. For module definitions, use ASDF.

This. We even have an almost de-facto standard library for easy parallelization (lparallel) and software transactional memory (stmx).

Absolutely agree regarding metaprogramming