Re: Complexity of new hardware

On Sat, Apr 25, 2009 at 2:53 PM, Rachel Blum <[email protected]> wrote:
> In turn extending your compile times... which is really not that high on my
> list of priorities. Writing a front end for your DSL that works with e.g.
> LLVM seems like the better choice, if you *have* to write your own DSL
> compiler.

I've found LLVM is a great compiler backend, and a pleasure to work
with. I've only found a handful of cases where compiling to LLVM IR is
more difficult then to C, and I feel there are an equivalent amount of
circumstances where the opposite is true. It's particularly
pleasurably using the C++ API.

> Ultimately, that's the first step into a model of "calcifying"[1] software.
> You start with an extremely malleable language, and it gradually hardens
> over time. (By compiling, providing annotations to the compiler, etc...)
>
> Haskell seems to be the farthest along that way, for now.  If there are any
> other recommendations, I'd love to hear them.

It seems to me that you are only referring to the advantages of Type
Inference in haskell, as other then that most software will "calcify"
to a degree, however I do agree that type inference can be a very nice
feature in a language, and helps to keep the whole application stable
as it enlarges. But with that in mind I feel that the family of ML
languages are also very suitable, and eager evaluation seems better
suited for game development.

> As far as I'm concerned, C++ is nearing a breaking point. We constantly cram
> new features into it (sorry, I meant "we extend the number of supported
> paradigms" ;), and design is by committee. Which leads to an extremely
> powerful and overly complex language that's almost unreadable. On top of
> that, the tool set is falling more and more behind.

As I mentioned, C++ was not designed for making games, it's very
suitable systems language, and for many systems in game development, I
do find it enjoyable, however it starts to break down while combining
systems into a large application, and additionally leads to a lot of
repeated and glue code, which is often ad-hoc and bug-ridden. That
combined with the very poor toolset makes it less then ideal to write
entire games in.

> At least for private projects, I've almost completely abandoned it - work
> has a slightly higher inertia ;)

I don't know if you're private projects are game related. But at the
moment there seems to be a much bigger issue then inertia in the work
environment, which is the lack of a viable alternative in our field.

Nicholas "Indy" Ray

------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list