www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Siemens Space experiment for using Haskell instead of C++ for

reply Paulo Pinto <pjmlp progtools.org> writes:
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
parent reply "po" <yes no.com> writes:
 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
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 13.09.2014 17:27, schrieb po:
 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.
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.
   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 Java and C# ones, every now and then. 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