5 ms·
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
by nly 13y ago
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_WDLXryyw91lahwdtpZsmo4BGD https://www.youtube.com/playlist?list=PLHxtyCq_WDLXryyw91lah...
[1] https://www.youtube.com/playlist?list=PLHxtyCq_WDLXFAEA-lYoRNQIezL_vaSX- https://www.youtube.com/playlist?list=PLHxtyCq_WDLXFAEA-lYoR...
- userbinator 13y ago> 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.
- betterunix 13y agoNow you are aware of another, Common Lisp (as implemented by SBCL): http://www.sbcl.org/sbcl-internals/index.html http://www.sbcl.org/sbcl-internals/index.html
- reddit_clone 13y agoHe did say "languages in common use". CL in spite of its name is still a bit uncommon.
- lispm 13y agothe true scotsman again?
- reikonomusha 13y agoYou 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++.
- dbaupp 13y agoInline ASM is implementation dependent in C++ too, isn't it?
- reikonomusha 13y agoYes, 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 http://clang.llvm.org/compatibility.html#inline-asm
- lispm 13y agoStill it is a common feature in Lisp systems to offer inline assembler or inline C.
- nly 13y agoThis 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.
- billsix 13y ago>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.
- iopq 13y agoHave 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.
- wglb 13y agohttp://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly... SBCL: The Ultimate Assembly Code Breadboard
- userbinator 13y agoI 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++.
- wglb 13y agoHere is an example of doing exactly that: http://benchmarksgame.alioth.debian.org/u32/program.php?test=mandelbrot&lang=sbcl&id=1 http://benchmarksgame.alioth.debian.org/u32/program.php?test...
- username223 13y agoNote 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.
- wglb 13y agoI 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.