4 ms·

+1 on dynamic languages, not a fan for this and many other reasons Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning i

+1 on dynamic languages, not a fan for this and many other reasons Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning it can have very dense code but as long as you follow the types it is often fairly straightforward to figure out what a piece of code does. The worst part about all the things that can happen implicitly in C++ is that they can all have side effects! Oh fun. This is not just a pitfall of C++ either, Java/C# can have the same issue - one statement can trigger a whole plethora of side effects making a large brownfield development project one hell of a nightmare.

danieldk 16y ago
Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning it can have very dense code but as long as you follow the types it is often fairly straightforward to figure out what a piece of code does. As a Haskell fan, I have to say that there is a bag of hurt here as well: performance in the lazy evaluation regime. It can be very hard to predict/understand when thunks are evaluated and the effect it has on heap use. I am still hoping for a strict, pure language with monads to go mainstream enough to use it. The next Haskell will be strict - Simon Peyton Jones Source: http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt