digitalmars.D - [OT] Siemens Space experiment for using Haskell instead of C++ for
- Paulo Pinto (17/17) Sep 13 2014 Just discovered this talk while watching the CUFP 2014 talks.
- po (9/12) Sep 13 2014 Why they were using C++ for that type of software is beyond me,
- Paulo Pinto (18/28) Sep 13 2014 Some form STL did exist, but it was still being discussed for inclusion
Just discovered this talk while watching the CUFP 2014 talks. What is interesting for the D users, are the slides related with the C++ issues that caused the decision to move away, between 03:00 and 05:30. https://www.youtube.com/watch?v=Wu8eJh6OqhI#t=181 Basically the usual points how real enterprise C++ looks like, where no one cares about "Effective C++" and similar practices. - uninitialised memory, memory leaks - no use of safer idioms like RAII, usage of deprecated idioms - low level pointer arithmetic, copy pasted in 100 places - off-by-one errors - undefined behaviours - static initialization order fiasco - race conditions - valgrid and purify could not be used everywhere Issues that D, specially in safe blocks, takes care of. -- Paulo
Sep 13 2014
Basically the usual points how real enterprise C++ looks like, where no one cares about "Effective C++" and similar practices.Why they were using C++ for that type of software is beyond me, I'd rather use Haskell if latency & throughput aren't my main concerns. The paper he referenced in regards to prototyping is from 1994. I'm not even sure if C++ has STL at that point. Which makes it pretty well meaningless. In the end all this really says is that legacy C++ is terrible(which it is), it doesn't really apply to C++14. Also the tooling advantage C++ has over Haskell or D is pretty wide--
Sep 13 2014
Am 13.09.2014 17:27, schrieb po:Some form STL did exist, but it was still being discussed for inclusion in the standard. C++ compilers bundled their own collection classes based in common root class or magic macros. It was however already possible to get initial versions of the STL from SGI, the STLport and a few others. Some compilers with initial template support, bundled these instead of their own.Basically the usual points how real enterprise C++ looks like, where no one cares about "Effective C++" and similar practices.Why they were using C++ for that type of software is beyond me, I'd rather use Haskell if latency & throughput aren't my main concerns. The paper he referenced in regards to prototyping is from 1994. I'm not even sure if C++ has STL at that point. Which makes it pretty well meaningless.In the end all this really says is that legacy C++ is terrible(which it is), it doesn't really apply to C++14. Also the tooling advantage C++ has over Haskell or D is pretty wide--I don't do C++ at work since 2005, but do get to replace C++ systems by This is the archtype of enterprise C++ code I get to see. Probably by the time C++17 gets approved is when some of these IT departments (or managers) will allow the use of C++11 compliant compilers. So far, the only workplace I could enjoy C++ being done properly, was during my stay at CERN. Tooling is a big factor, yes. -- Paulo
Sep 13 2014