Hacker News Reader

Comment by gnulinux | Hacker News Reader

C++ has a whole scripting language embedded into itself. They're trying to reinvent lisp, of course a much less efficient lisp.

View on HN

> They're trying to reinvent lisp, of course a much less efficient lisp.

yes, please show us all those high performance libraries written in lisp

It's OK.

Lispers live in a parallel universe, where performance issues are mere distractions from the higher level thinking.

Not every performance issue needs lower level optimization. Most performance issues can be solved by (1) optimizing algorithms and (2) abstracting lower level code in FFI C functions. C++ helps for 2 but not for 1 because if you don't have a clear high-level understanding of your algorithm, system, pipeline, it's harder to optimize or maintain that optimized code.

> C++ helps for 2 but not for 1 because if you don't have a clear high-level understanding of your algorithm, system, pipeline, it's harder to optimize or maintain that optimized code.

I strongly disagree. C++ has very nice tools for abstraction: higher-kinded types, dependent types (to some extent), lambdas & function objects, overloads, etc. It's a pain to design a data flow in C, but in C++ for instance it can just be something like this : https://github.com/RaftLib/RaftLib/wiki/Linking-Kernels or this : https://ericniebler.github.io/range-v3/.

Genuinely curious here, I don't know much Lisp, but dont Lisp macros tend to be powerful in the sense that they expand to more statements for runtime, whereas the purpose of C++ constexpr is to compile it down to one constant at runtime?

Lisp macros expand at compile time. You can also generate code and execute it with eval like in many other languages like python.

Lisp macros expand at compile time, but there's nothing special about the code running in them. Nothing at all stops you from doing arbitrary evaluation in one.

Speed also isn't as much of an issue, because macros (and the functions they call) can be compiled before execution.

Aah, k, thank you!

You can do arbitrary computation with lisp macros. But the magic you do it exactly the same way you do runtime computation.

Can you show us some examples of this efficient lisp that's faster than anything already constexpr-ed? :P

I didn't say "faster", I'm not claiming lisp is faster than C++, that's factually wrong. C++ is investing VERY heavily in metaprogramming since they finally figured out metaprogramming is important. Guess what, we knew this since 1960s and had an even better and elegant way of doing metaprogramming. It took ~60 years for us to realize the importance of a key feature of lisp and now we decided to make a hacked-on implementation of it. I'm personally pretty ok with C++, and it's not like this is community's fault given C++ originated from C. I'm just saying that the concept of "doing arbitrary computation in compile time" has been known since the dawn of computer science, and we had an extremely elegant and efficient way of doing it.

Then I misunderstood the original comment, apologies.

I agree with the utility of the approach. Given the narrow space the language can move, they actually placed the feature really well.

Starting with C, we almost achieved what lisp can do in a few thousand lines of code in, what, 20 years. I don't consider this a success, especially since C++ standard is now one of the longest, subtlest technical documents in the industry. We created a monster.

> less efficient lisp

But C++'s variety of parentheses is larger!

If LISP can do it with just one kind of parentheses that means it's more efficient. Can't argue with that...

I'm not following you. Lisp can do it with just two sort of syntactic atoms: symbol and parenthesis. To me, it seems like lisp is an order of magnitude more elegant than C++ where you need to hack-in every additional feature by (1) standardizing a syntax after making sure it doesn't break anything (this takes years of committee meeting and convincing tons of angry people with opinions) (2) handling that special syntax in lexer+parser+static analyzer+code generator; whereas in lisp every new feature would be part of the program itself, so essentially you just need to implement some parts of static analyzer and code generator.

Lisp is certainly more elegant than C or C++. The axiomatic nature makes for beautiful programs, and small teams of bright people have had notable successes using Lisp.

But in practical use, being axiomatic can be an enormous weakness. After all those much-derided committee meetings for C++, there is a standard, and having a standard allows people to collaborate without every team having to invent their own conventions and teach those conventions to everyone they work with.

Old style C macros can be seen as an ugly way of providing lisp-like power. One of the problems with macros is people abuse them to do crazy non-standard things, and in doing so make code really opaque to others. So in C, having to invent a custom language to do something is a bug. In Lisp, it's a feature. That distinction has a lot to do with why the world is running so much C and C++ code even though a Lisp is more elegant.

What's that saying? "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Apparently applies to the compilers now, too!

Reply on news.ycombinator.com