Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Programming Language to Replace C++

Name: Anonymous 2010-08-11 21:49

I think we can all agree that C++ is a terrible language. So why is it still around?

When talking to most C++ users (game developers, systems programmers), I've found that most seem to recognize C++'s faults, but they don't really care. They aren't even the slightest bit interested in a new language that might solve its problems, even one that gives them all the power of C++ with none of the downsides. You can't even get them to look at something new.

Why is that? Why does everyone just 'live with it' without wanting to improve the situation?

Name: Anonymous 2010-08-21 13:30

Trying to spark more discussion here...

>>7
malloc also gives you GC pauses, by the way.
I hate it so much when people say this. malloc() does not have "GC pauses", but yes, it can be unpredictably slow. We get that. That's why we're smart enough to not call malloc() in the middle of our rendering loop.

In most languages with forced GC, you simply do not have the means to perform any non-trivial computation without invoking the garbage collector. In Java, simple container classes like Point2D, which should be value types, are allocated on the heap. JIT can elide *most* of these with escape analysis, but no promises, and no feedback either. Functional languages are absolutely the worst for this; in something like Haskell, seemingly innocuous function calls allocate thunks for lazy evaluation, or reconstruct lists as they process them.

Many embedded apps have very predictable malloc() performance because they never call free(). They allocate all needed memory on startup, and then work strictly within those bounds. When I did game development on mobile platforms before iPhone (BREW, Symbian) this is how we coded our games. You have to in order to make it safe, especially since different phones can have such wildly different available memory; this way you know that as long as the app starts, it will never run out of memory.

>>7
BitC
BitC is sort of neat... but I'm not excited about it for a bunch of reasons. They seems confused about what syntax they want to use for it. They started out with Lisp, but with no Lisp features (e.g. macros.) Now they are trying to transition to a very ML-like or Haskell-like syntax. It also forces garbage collection, but at least it has the means to avoid causing garbage collection, such as refs to value types.

Most importantly it appears stagnant. Based on the bar on the left, nothing has changed since November 2008. The language is not in a usable state.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List