Comment by nly | Hacker News Reader

Comment by nly | Hacker News Reader

Parent Full thread

Saying it's converging on a Lisp is flexing a little bit of artistic license. It's fair to say C++ is becoming increasing accommodating to whatever you want to make of it if you're willing to compromise and roll with it. For sure, it's one of the very best and most practical languages for writing extremely efficient implementations of algorithms.

I highly recommend watching Alex Stepanovs A9 lecture series, "Efficient Programming with Components" [0], where he covers the humble min() function, and variants thereof, for at least ~20 hours. During this time he also takes a minor digression in to writing a memory pool for linked-list nodes, while pointing out similarities in the design to a Lisp. It's extremely 'instructive', as he would say, in understanding how he writes C++ code. The sheer amount of code will horrify you, it may even seem unproductive, but I think his objective was really to get everyone thinking about the beauty of the algorithms and the details rather than the objective. His concern for performance, correctness of code, and composition of algorithms is interesting and something I haven't seen presented in real time, in C++, in such a manner before. One example for instance, are occasions where he insists on writing functions backwards, from the return statement up.

If you want a higher level overview on his opinions of C++ and programming etc. The less intense series, "Programming Conversations" [1], is worth a more casual watch.

[0] https://www.youtube.com/playlist?list=PLHxtyCq_WDLXryyw91lah...

[1] https://www.youtube.com/playlist?list=PLHxtyCq_WDLXFAEA-lYoR...

> It's fair to say C++ is becoming increasing accommodating to whatever you want to make of it if you're willing to compromise and roll with it.

It's also one of the few languages in common use that allows using a wide range of abstraction levels, whatever is desired - I'm not aware of any other language that lets you write inline Asm, procedural, OOP, and functional-style code, all conceivably in the same source file.

>I'm not aware of any other language that lets you write inline Asm, procedural, OOP, and functional-style code, all conceivably in the same source file.

Gambit-C.

http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly... SBCL: The Ultimate Assembly Code Breadboard

I think this was on HN earlier too. It's slightly different from what I had in mind, however; generating and then running Asm from Lisp is not quite the same as being able to embed instructions inside any function that manipulate the contents of lists directly, which can be easily done in C/C++.

Here is an example of doing exactly that: http://benchmarksgame.alioth.debian.org/u32/program.php?test...

Note that the C++ is half the code and 6 times as fast. This supports my general impression that you can torture decent performance out of a Lisp compiler, but the result will be ugly, and you'll rarely match C.

I see the ratio as 28.39 sbcl to 10.61 for g++, closer to 3 on the 64 bit version.

At any rate, I was addressing generating and then running Asm from Lisp issue.

Now you are aware of another, Common Lisp (as implemented by SBCL):

http://www.sbcl.org/sbcl-internals/index.html

You should underline that the ASM part is extremely implementation dependent. There is absolutely no language feature, or even a convention, to have inline ASM.

Also I'd posit that inline ASM is a lot easier to reason about in C++ than it is in Lisp, given to the rigid type structure. You're bound to shoot yourself in the foot in Lisp, even more than in C++.

Inline ASM is implementation dependent in C++ too, isn't it?

Yes, but the two big names in C++ compiler technology—GCC and Clang—are largely compatible [1]. This is not the case with Lisp.

[1] http://clang.llvm.org/compatibility.html#inline-asm

> Also I'd posit that inline ASM is a lot easier to reason about in C++ than it is in Lisp, given to the rigid type structure.

I believe it's also a matter of how these languages were designed; Lisp started out as exclusively high-level, while C++ came from C which came from Asm. In other words, the features in C++ almost all have direct mappings to how it could be done in C, and going from C to Asm is also quite direct. In contrast, Lisp -> Asm is a huge conceptual leap.

I think the much-maligned complexity of C++ is because it grew in this step-by-step fashion and exposes all these levels of abstraction so you can easily reason about the tradeoffs involved and understand the code the machine will eventually be running. More importantly, you don't have to use all of them, but this is what makes the language so flexible and accommodating to a wide audience.

(Personally I prefer C/Asm more because I don't operate at such high abstraction levels often, and when I do, the features of C++ are not a good fit for what I want to accomplish. I have used closures in C and done functional-style there, but it doesn't seem like I need to do this often enough to move to C++ or a Lisp.)

Lisp had close ties to ASM early on - car and cdr refer to particular parts of a register in a 1950s era IBM computer, 20 years before C existed.

Those are no "ties to ASM" in the sense "easy to embed ASM in this language".

Those are merely implementation details of early Lisp leaking to the language naming.

If that were true it would have been awfully difficult to write operating systems in Lisp, yet OSes were written in Lisp (and the companies that famously did so played a part in the founding of the Free Software Foundation).

Still it is a common feature in Lisp systems to offer inline assembler or inline C.

He did say "languages in common use". CL in spite of its name is still a bit uncommon.

the true scotsman again?

This is true, and I personally find it canbe a tarpit for becoming incapacitated by design choice. There's an extreme temptation, because its so easy, to attempt to either go deep, or build out a se of abstractions. Both can be huge time sinks if attempted foolhardy.

Have you heard of Rust? It has all of the above and more - it has compile-time memory safety/safe concurrency (without garbage collection forced on you), algebraic data types, type inference, pattern matching, etc.

Reply on news.ycombinator.com