Hacker News Reader

Comment by flavio81 | 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.

View on HN

> 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.

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.

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.

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.

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.

>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.

Reply on news.ycombinator.com