5 ms·
so, c++ becomes greater?
by tapirl 8y ago
so, c++ becomes greater?
- gnulinux 8y agoC++ has a whole scripting language embedded into itself. They're trying to reinvent lisp, of course a much less efficient lisp.
- jcelerier 8y ago> 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
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- ur-whale 8y agoIt's OK. Lispers live in a parallel universe, where performance issues are mere distractions from the higher level thinking.
- gnulinux 8y agoNot 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.
- jcelerier 8y ago> 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 https://github.com/RaftLib/RaftLib/wiki/Linking-Kernels or this : https://ericniebler.github.io/range-v3/ https://ericniebler.github.io/range-v3/.
- brobdingnagians 8y agoGenuinely 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?
- pmarin 8y agoLisp macros expand at compile time. You can also generate code and execute it with eval like in many other languages like python.
- Filligree 8y agoLisp 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.
- brobdingnagians 8y agoAah, k, thank you!
- deleted 8y ago[deleted]
- gnulinux 8y agoYou can do arbitrary computation with lisp macros. But the magic you do it exactly the same way you do runtime computation.
- Koshkin 8y ago> less efficient lisp But C++'s variety of parentheses is larger!
- 0-_-0 8y agoIf LISP can do it with just one kind of parentheses that means it's more efficient. Can't argue with that...
- gnulinux 8y agoI'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.
- mrfredward 8y agoLisp 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.
- OskarS 8y agoWhat'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!
- quickben 8y agoCan you show us some examples of this efficient lisp that's faster than anything already constexpr-ed? :P
- gnulinux 8y agoI 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.
- quickben 8y agoThen 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.
- gnulinux 8y agoStarting 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.