STL

[svero]

Just for the record I think the STL is a big horrible mess. Not a fan.

[Kestral]

Just for the record I think the STL is a big horrible mess. Not a fan.
Agreed!

Once during the "technical guantlet" portion of a job interview one of the interviewers asked me "What do you think of STL?" and I answered honestly and he got really pissy for 5 minutes and then the interview was over :mad:.

[FlySim]

What do you guys use instead of STL - home brew?
I like STL OK except for the debugging, but Im always open to something better.

[ggambett]

What do you guys use instead of STL - home brew?
Homebrew List, Hash and String do 99% of what I need.

[mr n00b]

What do you guys have against the STL? It's extremely flexible, elegant and efficient, you'd be very hard pressed to come up with something _as_ good (you won't do _better_) yourself.

The designer of the STL, Alexander Stepanov, is one of the few programming geniuses out there (Andrei Alexandrescu is another). By genius I don't mean someone who's very very good at programming, there are plenty of those, but someone who revolutionized the way programming is done.

I wouldn't hire someone who thinks the STL sucks either. You don't have to like all aspects of it but to just dismiss it and say that it's crap is just ignorant.

/mr n00b

[Savant]

I agree. I would say that if someone doesn't like using the STL, that's one thing. To try and tell me that it's crap with a straight face will lead to a handshake and a "Well, thanks for coming in..."

[Jim Buck]

I think FlySim hit the reason why people don't like the STL - it's hard to debug your code that it wrapped up in STL structures. I don't think people are complaining about the utility or the efficiency of the STL. I, too, am against the STL in the area of debugging but think it's great for all the other aspects. It is very difficult, if not almost impossible, to set up variable watches quickly inside of a debugger.

[DrWilloughby]

I agree with Jim wholeheartedly. Perhaps this might belie my ignorance, but I don't see why the popular debuggers don't have built in STL support that makes these structures a little more transparent.

[Musenik]

STL is baroque like some classical music. Compared to the simple melody of the original C library, STL is simply too many notes for anyone who doesn't want to learn yet another programming language just to access some useful routines.

Like the baroque period, it will have its time. It will leave its mark. Occasionally someone will resurrect it for something good. But it's not the future.

[mr n00b]

STL is baroque like some classical music. Compared to the simple melody of the original C library, STL is simply too many notes for anyone who doesn't want to learn yet another programming language just to access some useful routines.

Like the baroque period, it will have its time. It will leave its mark. Occasionally someone will resurrect it for something good. But it's not the future.

Eventually C and C++ will probably fade into history and be replaced by something else but I don't see this happening anytime soon. However, as long as C++ is around the STL will be as well. The STL is probably more representative of the way programs will be written in the future than the rest of C/C++ with it's concept of generic containers and algorithms.

Also I think your analogy with baroque classical music halts considerably, some of the greatest music ever was produced in this period and hundreds of thousands of people still enjoy it daily, baroque music is still very much alive and kicking.

Btw, what is the future, in your expert opinion? Pure C?

/mr n00b

[mr n00b]

I think FlySim hit the reason why people don't like the STL - it's hard to debug your code that it wrapped up in STL structures. I don't think people are complaining about the utility or the efficiency of the STL. I, too, am against the STL in the area of debugging but think it's great for all the other aspects. It is very difficult, if not almost impossible, to set up variable watches quickly inside of a debugger.

Unfortunately I can't say if this is possible in all IDE:s, but in Visual Studio it's pretty easy to edit the file 'autoexp.dat' to display stl-containers and iterators in a much more debug friendly manner.

Microsoft has apparently also realized that STL-debugging is important to a lot of people so the latest version of Visual Studio is very much improved in this area.

/mr n00b.

[Michael Flad]

STL is baroque like some classical music. Compared to the simple melody of the original C library, STL is simply too many notes for anyone who doesn't want to learn yet another programming language just to access some useful routines.

Like the baroque period, it will have its time. It will leave its mark. Occasionally someone will resurrect it for something good. But it's not the future.

I don't get what you'r comparing here? STL and C library are really some completely different things and I think (just from what you've written) you haven't got enough information/experience regarding the STL to make these kind of statements.

STL isn't even very old, few years ago it wasn't even possible to compile on quite some compilers. It's almost completely the opposite of "STL is simply too many notes for anyone who doesn't want to learn yet another programming language".

[Kestral]

I wouldn't hire someone who thinks the STL sucks either. You don't have to like all aspects of it but to just dismiss it and say that it's crap is just ignorant.
I use STL all day every day, and have done so for many many years. Yes, the utility, portability, and efficiency are very important and hard to beat. Knowing how to use it (and when to use it) and *liking* using it are two different animals.

My biggest beef: every time I open up one of those header files it makes me wince. Typical STL headers use alien code formatting, the templates make them difficult to read, the naming is bizarre in places, they are sparsely commented, and what comments are there are often useless.

When you write a C++ code library your header files become the first place coders go to for information. If they are cracking a book to look something up then they are burning cycles needlessly. Sure, over time it all gets committed to memory, but why should it have to be?

I cut my STL teeth on the version that shipped with VC++ 4.0. You may recall that it had more than its share of bugs. Google for "STL memory leak" and you will get six figure results.

[mr n00b]

I use STL all day every day, and have done so for many many years. Yes, the utility, portability, and efficiency are very important and hard to beat. Knowing how to use it (and when to use it) and *liking* using it are two different animals.

My biggest beef: every time I open up one of those header files it makes me wince. Typical STL headers use alien code formatting, the templates make them difficult to read, the naming is bizarre in places, they are sparsely commented, and what comments are there are often useless.

I agree to some degree that the STL (i.e. some implementations of the STL) uses a somewhat strange formatting but it's not that hard to read, especially not if you're an experienced programmer, and since you've been using the STL since VC++ 4.0 you surely qualify as one. Fortunately however I find that it's extremely rare that I even have to open the STL headers.

Seriously, how often do you have to debug the code inside the STL headers?

When you write a C++ code library your header files become the first place coders go to for information. If they are cracking a book to look something up then they are burning cycles needlessly. Sure, over time it all gets committed to memory, but why should it have to be?

May I recommend the following excellent resource:

http://www.sgi.com/tech/stl/

Also, the STL is part of the C++ language so any decent C++ programmer should know at least the most common uses of it by heart, you don't open up a book each time you have to write a for loop do you?

I cut my STL teeth on the version that shipped with VC++ 4.0. You may recall that it had more than its share of bugs. Google for "STL memory leak" and you will get six figure results.

1. You have to keep the design of the STL and the implementation of STL apart, just because the VC++ 4.0 implementation suck doesn't mean that the STL sucks.

2. You're not still using VC++ 4.0 are you?

/mr n00b

[Kestral]

Also, the STL is part of the C++ language so any decent C++ programmer should know at least the most common uses of it by heart, you don't open up a book each time you have to write a for loop do you?
STL is a support library, written using C++, and is not a part of the "C++ language" per se. Stroustrup included it in the second edition of his book to promote its use (which was a good thing). STL (and templates themselves) did not exist for the first edition of his book.

There are undoubtedly thousands of perfectly decent Windows/MFC C++ developers out there who have written hundreds of prefectly decent Windows apps who have never had cause to write one single line of STL.

Lovely use of leading questions to insult, BTW.

[Jim Buck]

This is only the second time I've heard of autoexp.dat in my life, the first being from a co-worker a couple years ago. I would guess 99.9% of VS users have no idea about its existence. If it's not already front-row-and-center in an application like Visual Studio, then it may as well not exist. For STL to be useful from a debugging level, it needs to be built-in from the get-go into the IDE in much the same way that MFC stuff was built-in to VS 6.0.

[Musenik]

Knowing how to use it (and when to use it) and *liking* using it are two different animals.

My biggest beef: every time I open up one of those header files it makes me wince. Typical STL headers use alien code formatting, the templates make them difficult to read, the naming is bizarre in places, they are sparsely commented, and what comments are there are often useless.

When you write a C++ code library your header files become the first place coders go to for information. If they are cracking a book to look something up then they are burning cycles needlessly. Sure, over time it all gets committed to memory, but why should it have to be?

This is exactly what I'm talking about. Ergo, baroque. My original statement made no qualitative assessment of baroque music. It said the Baroque Period is long behind us.

I should think it's fairly obvious that higher level languages are the future. C will end up like Fortran. A lot of people still use it, but the torch has been passed. As long as we avoid talking about COBOL, we'll be fine. :-)

[mr n00b]

STL is a support library, written using C++, and is not a part of the "C++ language" per se. Stroustrup included it in the second edition of his book to promote its use (which was a good thing). STL (and templates themselves) did not exist for the first edition of his book.

Any ISO/IEC 14882 compliant C++ implementation must include the C++ standard library of which the STL is part. So the STL is most definitely a part of the language (please don't turn this into a philosophical discussion about what constitutes a programming language).

C++ is not defined by the latest edition of Bjarnes book.

There are undoubtedly thousands of perfectly decent Windows/MFC C++ developers out there who have written hundreds of prefectly decent Windows apps who have never had cause to write one single line of STL.

Sure, but the day they do need to use the STL (if ever) they should learn the basic concepts by heart as they've done with the rest of the language.

Lovely use of leading questions to insult, BTW.

Thanks!

/mr n00b

[Kestral]

First Round:

the STL is part of the C++ language so any decent C++ programmer should know at least the most common uses of it by heart

Getting Closer:

the day they do need to use the STL (if ever) they should learn the basic concepts by heart.

Final Round:

Consider an MFC programmer who one day chooses to use an STL container to do a very specific task that it is very well suited for. On that very day should she stop work for a few days to commit STL to memory as you decree? Or does she get the job done BUT subsequently get fired by mr n00b as "ignorant" because she didn't pass his "decent programmer" generalizations?

[James C. Smith]

I moved all those posts out of the "free source code" topic and into this separate topic so that all this SQL talk wouldn't eclipse the original discussion.

[cliffski]

STL is a big topic. I use vectors lists and strings from the STL quite a bit. I know that container class wise, they are less buggy than anything I'd write.
But generally I use simple code, I dont use maps, let alone functors, and all the fancy stuff.
On days when I use a reverse iterator, I feel like a right John Carmack.
STL is a tool, use it for what you need, ignore the rest.

[James C. Smith]

I would guess 99.9% of VS users have no idea about its existence.

Then I would say that 99% of VS users need to learn how to use their debugger. I only heard about this feature once and many, many years ago and I have used it every day since. It is an important feature but much more than just STL and MFC users.

[Savant]

Then I would say that 99% of VS users need to learn how to use their debugger.
I agree. I first heard about it years ago when I wanted to see if we could display our own data types and structs a little easier in the debugger. Lo and behold, there was a way!

[princec]

This is exactly what I'm talking about. Ergo, baroque. My original statement made no qualitative assessment of baroque music. It said the Baroque Period is long behind us.

I should think it's fairly obvious that higher level languages are the future. C will end up like Fortran. A lot of people still use it, but the torch has been passed. As long as we avoid talking about COBOL, we'll be fine. :-)
Praise be for Java then with its ultra-lovely libraries which are a joy to use :) I know svero will one day be brainwashed^H^H^H^H^H^H^H^H^H^H^Hcome round to my way of thinking and embrace the inevitable.

Cas :)

[PeterM]

Edit: Half-way through writing this, I had a change of heart. I've split the post into two sections...

If I were a complete C++ code nazi, which I only am every other day, I'd say the following.

For us desktop OS developers where several good free C++ compilers are readily available (GCC, Visual C++ Express and probably others), I think there is only one acceptable reason to roll your own containers instead of using the STL.

If someone wants to learn how to program their own containers, then it's ok. But when they're done they should throw their versions away and use the STL ones.

You can even use the STL on consoles where no virtual memory exists, providing you know what guarantees the various containers have about when and how they allocate and construct your objects.

Like it or not, STL is part of the standard, it's bug-free (nowadays), and probably better than anything you could write to do the same job.

One of the big stumbling blocks to STL adoption is exception adoption. If people want to use containers safely, they really need to know and use exceptions. But then all modern compilers should throw bad_alloc on failure in new or new[] anyway, so I guess everyone really needs to know exceptions.

Which are another topic in itself...

But since I'm not a C++ code nazi today, I'll say this instead.

I think programmers should ascend to the "toolset nirvana" where Cas resides. That's not to say that everyone should switch to Java - I mean it in a much more general sense.

Cas uses a toolset he knows and loves (presumably). He enjoys writing games with it, and he finds that generally it works out well for him.

I guess if you're not happy with your toolset, then have a look around and consider a switch. Chances are there are cleaner and more productive ones out there.

Even if you are happy with your toolset, it's probably a good idea to be aware of your options. You never know what the next big thing (or next short-lived fad) will be.

I would recommend that C++ users who don't use exceptions try them out for a couple of hours. Then make the switch, if they want.

Then I'd recommend that they try the STL, and maybe make the switch.

Pete

[jankoM]

Homebrew List, Hash and String do 99% of what I need.

Does anyone know any good multiplatform and possibly simple (minimalistic) "list/dynamic array/linked list", "hash/dictionary", "string" library that is not STL then? I am rather new to c++, but was working in python php for long time - and I feel that these three things are all I need for comfortable programing - the simpler the merier.

[PeterM]

Does anyone know any good multiplatform and possibly simple (minimalistic) "list/dynamic array/linked list", "hash/dictionary", "string" library that is not STL then? I am rather new to c++, but was working in python php for long time - and I feel that these three things are all I need for comfortable programing - the simpler the merier.Out of curiosity, why would you prefer not to use the STL versions?

[jankoM]

I was using it (a little)... ok I still do pushups with normal arrays but plan to swich to higher level containers yesterday.

Why do I ask? Because if some people are saying STL is horrible there must be (and I wan't to check out) the alternarives for at least the most obvious things I would use STL for.

Why would I use them? Because I like smaller things that I can look into guts and possibly understand them and have sence of controll over them and that do what I need and not much more.

Isn't asking questions and answering them stupid? I hope not, but probably it is. ;)

[PeterM]

Why do I ask? Because if some people are saying STL is horrible there must be (and I wan't to check out) the alternarives for at least the most obvious things I would use STL for.It's wise to have a look around and check out the alternatives. Other than using the STL or rolling your own containers, I'm not sure there is a common solution.

Why would I use them? Because I like smaller things that I can look into guts and possibly understand them and have sence of controll over them and that do what I need and not much more.If you're new to C++ you're very likely to make a lot of subtle bugs when writing your own containers. For example, do you know why it's not exception safe to return the previous top of a stack in the pop() method? How does the STL get around this problem?

Unfortunately C++ is a very hard language, and the gotchas are out to get you.

The STL however, is probably a lot simpler than you think, if you understand the underlying concepts. Check the SGI docs for that - Containers, Iterators, etc.

Apart from checking out the header files (yuck) and putting breakpoints in your code to see the internals (slightly less yuck) it will be hard to really know what's going on in the STL functions you call. But this is the same of all standard functions. When was the last time you needed to see the printf source code?

There was already a link to the excellent STL page at SGI - it's one of the best online guides to the STL. There is also http://www.cppreference.com/index.html .

Isn't asking questions and answering them stupid? I hope not, but probably it is. ;):o

[Dominique Biesmans]

Does anyone know any good multiplatform and possibly simple (minimalistic) "list/dynamic array/linked list", "hash/dictionary", "string" library that is not STL then? I am rather new to c++, but was working in python php for long time - and I feel that these three things are all I need for comfortable programing - the simpler the merier.

Check out the container classes in the prohecy SDK that you can find on
http://www.twilight3d.com/. It's been a while since I've used them, and I don't remember if there's a key-value pair container in there, but it's very minimalistic , lightweight and elegant.

[Dominique Biesmans]

A natural extension of the STL, and a good example of the power of generic programming [in C++] are the boost libraries (http://www.boost.org/).

[Musenik]

Praise be for Java then with its ultra-lovely libraries which are a joy to use :)
Cas :)

Ugh! Calling Java a high-level language is like calling Merlot a respectable wine. (Then again, I've enjoyed drinking some Merlot's, whereas I've never enjoyed reading Java code.)

To show what a great track record I've had in predicting the future... way back when, I once believed Modula-2 would end up succeeding C. I once believed Icon was the ultimate high-level language. Now I've got Python...

I've already said too much. Oh programmer Goddess, please keep my cross-platform build process safe from language and OS revisions!

[Backov]

I can see why people hate STL, actually.. I use it now, and have used it in the past, but I'm in no way an STL power user.

It's like XML - I know there's tons more to it, but I just don't need it.

What I use STL for:

Lists, Vectors, Strings, etc..

But, the reason I dislike it: It is basically replacing the platform specific stuff that I was using - Borlands VCL with the StringList, ObjectList, what have you.. And Cocoas NSStringList, etc.. Both very nice, powerful, elegant systems that I loved. STL in contrast is a huge PITA to use.

[Vectrex]

print these out :)

http://linuxsoftware.co.nz/cppcontainers.html
http://linuxsoftware.co.nz/cppiterators.html
http://linuxsoftware.co.nz/cppstrings.html

[PeterM]

Nice links! I especially liked the "choosing a container" flowchart.

Pete

[princec]

Ugh! Calling Java a high-level language is like calling Merlot a respectable wine. (Then again, I've enjoyed drinking some Merlot's, whereas I've never enjoyed reading Java code.)
You need to buy wine that costs more than a fiver ;) Have a read of some of my Java code - it's not too horrible at all compared to, say, any C++, ever 8)

Java occupies a pleasant middle ground between 3GL and 4GL code. Not too low level to be a complete pain (er, once you've got the OpenGL thing sorted); not too high level to be slow and inflexible. I'm a very lucky bunny indeed to have found code nirvana there.

Cas :)

[jankoM]

If you're new to C++ you're very likely to make a lot of subtle bugs when writing your own containers. For example, do you know why it's not exception safe to return the previous top of a stack in the pop() method? How does the STL get around this problem?

Uhmh... what is a stack? I know there is stackless python (taht powers eve online btw) but that is all I know of stacks. :)

The STL however, is probably a lot simpler than you think, if you understand the underlying concepts. Check the SGI docs for that - Containers, Iterators, etc.
I had no problems using STL. I use vector and map in my resource manager and it was thoughtless to use, I just had to find few basic mathods (push_back(), at()...) and didn't bother with the rest much.

Check out the container classes in the prohecy SDK that you can find on http://www.twilight3d.com/.
wow, great link. I will check in and out this. Besides that their implementations are really minimal this libs can also be very good to teach myself how some things are done. Thank you for the link!

[PeterM]

Uhmh... what is a stack? I know there is stackless python (taht powers eve online btw) but that is all I know of stacks. :)A stack is a container where you can add and remove things from the top, but not in the middle or at the bottom. The SGI page sums it up better than I can. :o

http://www.sgi.com/tech/stl/stack.html

If you were for example doing a 3D game, then a stack of matrices might be useful.

[Vorax]

I'm with Cas - Comparing Java's standard API's to STL is like spending a night in a 5 star hotel with versus sleeping on a bench - The net result may be the same, but the hotel is SO much nicer. Go ahead; pamper yourselves with some Java if STL is getting you down :D

[george]

i was once a c++/stl die-hard... but...

for god's sake, stop discussing this old-world (not necessarily old) platform (unless you are writing an operating system or driver) and get into the next-generation of programming with visual c#, delphi, java, etc. so that you can concentrate on creating a great product and actually making some money! try an alternative if you haven't already, i can almost guarantee you that you will be pleasantly surprised... i would never ever write another application in c++ ever again now that i have been enlightened with delphi/c#/java... say bye bye to all that archaic shit, that's all i can say.

TRY IT BEFORE YOU START THE FLAMING!!!

just mho...

[Rainer Deyke]

Out of the dozen or so programming languages I've actually used, Java and Delphi were by far the most painful. Both are old-school languages similar to some subset of C++ (i.e. statically typed, prodedural code with some level of object orientation), but neither is as flexible or powerful as C++. Which is not to say that I like C++.

[Vorax]

Out of the dozen or so programming languages I've actually used, Java and Delphi were by far the most painful. Both are old-school languages similar to some subset of C++ (i.e. statically typed, prodedural code with some level of object orientation), but neither is as flexible or powerful as C++. Which is not to say that I like C++.

Hungh?? Java is simply C++ less the pain points. If you know C++, you already know Java (syntax is almost identical). The biggest difference is in the API's you get out of the box with Java (think STL on steroids + simple to use and debug), garbage collection and cross platform capabilities. And.. Java is highly object oriented.

[Savant]

IMO, C# is the way forward. All the power of C/C++ without the pain.

[Sharpfish]

Well I'll be sticking with C++ (and the "pain" if that even matters once you know c++) if it means I can utilise 90% of the libraries out there. It is a "standard" and as much as C++ has it's downsides it is flexible, X-Platform, and makes fast native code that doesn't need additional download of runtimes or require systems to be updated with "latest version of X framework".

Sure It would be nice to make C++ a lot less convoluted (or use a "cleaner" language) but once you have wrapped your code/engine and learned/wrapped the api of choice then the interface can be as simplistic as you require.

But as I said the main reason is because if I choose to look at 3rd party libraries, chances are they use C++ primarily and I don't want to hunt down/write my own bindings everytime I want to test something out.

I'm more than happy with C++, but I like other languages also. Eventually there will probably be a move towards C# style languages but it will have to be a bigger standard than it is now for that to happen. And java is nice and all that but I hate having to clog up machines with the jre.. it just feels clunky. Better the dev deals with clunkyness and makes it easier for the end user than the other way around in my opinion - unless you really can not get on with C++ then sure use what you have to.

[Fabio]

IMO, C# is the way forward. All the power of C/C++ without the pain...and speed. ;)

Moreover, I would stay away from proprietary veryverysmall$oft languages and libraries as I'd stay away from slavery [ however, one of their tools, VC++, is more than decent.. but it compiles a standard language anyway (if you avoid all VC++ proprietary traps), so.. it doesn't make me risk to become a slave ].

[Robert Cummings]

Blitzmax is the way forwards. If you're insecure, you'll dismiss what I'm saying outright.

But blitzmax offers nearly all of c#'s power without the penalty of .net including cross platform game ready libraries.

The lists however, are way superior to any list in any other language I've used.

[Savant]

..and speed.
That's getting less true every day. The CLI compilers are getting better with each iteration of .NET. Within a year it won't make a lick of difference.

But blitzmax offers nearly all of c#'s power without the penalty of .net including cross platform game ready libraries.
That's really not true. BlitzMax is a root subset of the C# language at best. Have you been fully exposed to C# and .NET? I love BlitzMax, but C#/.NET is a world above.

The lists however, are way superior to any list in any other language I've used.
It can't touch .NET 2.0 for lists. The templated "List" container is outstanding and couldn't be simpler to use.

[Savant]

Of course, if you're talking about game development exclusively then a language designed specifically for that task (like BlitzMax) would seem to fill that need better than something more general like C#. However, since C# can handily compete directly with those specialized languages and STILL be excellent for other things (desktop utilities, applications, etc) - that moves it to the next level. It will even run on your web server as a replacement for PHP.

I'm also assuming that you've tried C# with Microsoft's 2005 IDE. The incredible intellisense, code completion, and refactoring abilities built into that IDE make coding in C# an absolute dream. The default BlitzMax editor is a sorry app that offers little over notepad.

[Robert Cummings]

I haven't tried C# for over a year.

I did enjoy it. Blitmax reminded me a lot of it, and I plumped for max as it's just the best tool for the job. I have not had much experience with C#'s lists.

C# also requires .net which is an extra download for a lot of people, and it's capabilities cross platform don't seem to be as good out of the box as max.

I would need to spend a lot of extra time on engine stuff.

I think I'm sticking with max for the moment, but I can't see C++ ever being something I'll go back to (unless I have to). C# really is good, but for me it's unsuited to casual game dev at the moment.

he default BlitzMax editor is a sorry app that offers little over notepad.Absolutely spot on. The user app 'Blide' seems the closest match to visual studio net's IDE (I've only tried the original and 2003's) and protean is a broken joke.

[merovingian]

Just to add gasoline to the fire...

I think STL, exceptions, template metaprogramming, and all the other power tools are just swell for personal projects or for small teams where everyone's a coding god, but...

On a large team, full of diverse people, with diverse coding skills (i.e. most of reality because software companies mostly balk at paying people what they're worth), and simply because of the O(n^2) communications issues that emerge, I would eschew them there. Heck, I'd even get nervous about multiple inheritance and, to some extent, abstract base classes.

Notice, despite its many failings, how Java sidesteps most of this. Ironic IMO.

[HairyTroll]

The lists however, are way superior to any list in any other language I've used.

-->in any other language I've used<-- Try Lisp. There is no language that beats Lisp when it comes to handling lists or trees etc.

Edit: Because I can't spell language.

[Vorax]

And java is nice and all that but I hate having to clog up machines with the jre.. it just feels clunky. Better the dev deals with clunkyness and makes it easier for the end user than the other way around in my opinion - unless you really can not get on with C++ then sure use what you have to.

That is a good point, but there are ways around it. It can be as easy as C/C++ for the user. Take a look at Ultratron (http://www.puppygames.net) by Cas, AlienFlux or Tribal Trouble (all on same page) - If you download and install Ultratron (6.6MB), you would have no idea it was Java. They all install just as cleanly as C/C++ and don't feel clunky at all.

[Musenik]

I like lisp. It's totally elegant in design. My personal problem is, it wants me to program more like a mathematician than an engineer. For me and others who barely scraped by in four semesters of calculus classes, it'll always be a write only language.

Now FORTH, there's a write only language for everyone!

[Michael Flad]

Java is a solution for the problem of to much needs for to little quality developers - and it's good at that because even less skilled developers are up to the task to solve at least some of the problems given.

[ggambett]

I don't use the STL and I don't particularly like it.

Having said that... I think it's my fault, not STL's. See, anyone can program in a procedural language, be it Assembler, C++ or Java. Most discussions about which of these is better are actually pointless because they are all the same, with slightly lower or higher levels of abstraction and slightly different amounts of syntactic sugar.

As I said, anyone who isn't particularly dumb can code in any of these languages. It's other paradigms which aren't for everyone - functional programming or logic programming for example. Having been exposed to both (Haskell in the university, Prolog at my old job) I can say these languages force you to think at a higher level. Saying that C++ is lower level than Java is true at a microscopic level, because all procedural languages are instances of a low-level programming paradigm.

So... the STL looks weird for me because I think programs at a low level, so yes, the vector and string types are useful, but all the metaprogramming stuff looks scary. But as I said at the beginning, that's because I'm not a good enough programmer to find it useful. Boost is an even better example of this.

I, for one, admire and respect the guys who master Lisp and other higher-level languages. Discussing if Java's or C++'s container classes are better is kinda naive and short-sighted from our part.

[ggambett]

Let me add that precisely because of what I said above I love C++ and Python in this immature programmer stage. While their main focus is procedural or OO programming, they do show some aspects of higher level programming, C++ through templates and everything built on them (STL, Boost) and Python for exposing some functional programming features (lambda expressions, functions as first-class objects,...). Just being exposed to higher level languages opens your mind and boosts (pun not intended) your productivity in the lower level languages, up to where these languages permit - and that's why I don't like Java : it forces me to make everything OO even if I don't want to.

[Vorax]

I don't use the STL and I don't particularly like it.

Having said that... I think it's my fault, not STL's. See, anyone can program in a procedural language, be it Assembler, C++ or Java. Most discussions about which of these is better are actually pointless because they are all the same, with slightly lower or higher levels of abstraction and slightly different amounts of syntactic sugar.

Not entirely - That's like saying a car is a car is a car when comparing different models - yes they have 4 wheels and look basically the same to the uneducated eye - but ask a professional driver what he thinks.


As I said, anyone who isn't particularly dumb can code in any of these languages. It's other paradigms which aren't for everyone - functional programming or logic programming for example. Having been exposed to both (Haskell in the university, Prolog at my old job) I can say these languages force you to think at a higher level. Saying that C++ is lower level than Java is true at a microscopic level, because all procedural languages are instances of a low-level programming paradigm.

Can't aruge with that - Prolog is an entirely different beast.


I, for one, admire and respect the guys who master Lisp and other higher-level languages. Discussing if Java's or C++'s container classes are better is kinda naive and short-sighted from our part.

Lisp is great, but in my experience tends to break down as the project gets large, not because of the language, but because of programmers - if everything was right from the start Lisp holds together, but if not (which is entirely typical these days) - it starts to fight you because it wants to be what you told it it should be in the first place - C, C++, Java, Delphi, etc ask you to think about their strengths, Lisp asks you to think about yours :)

[ggambett]

Not entirely - That's like saying a car is a car is a car when comparing different models - yes they have 4 wheels and look basically the same to the uneducated eye - but ask a professional driver what he thinks.
That's my point - a guy in an helicopter will beat your professional driver who can argue for hours about minimal differences between cars every single time. What I'm saying is, we're all car drivers, let's not forget there are things out there that aren't cars.

[Huge]

If you ever find yourself writing:

...
struct NODE *next;
struct NODE *prev;
...

It's time to use the STL. If you don't like it all, just take the low-hanging fruit. mmm, fruit, mmm.

[HairyTroll]

it wants me to program more like a mathematician than an engineer.

What, the following code that adds a 10x10 matrix of cubes to a 3D scene and then animates each using a rotate function is hard to grok? ;)

Ok, the point of this excercise was to do the above without requiring the use of any temporary variables to hold intermediate results.


(node-add-child root-node
(loop for i from 0 to 10
append (loop for j from 0 to 10
collect (node-add-primitive (graph-node (add-actor (make-instance 'MOB
:graph-node (new-node :name "box")
:action (new-rotate :dx 1
:dy 1
:dz 1))))
(new-box -1.0 -1.0 -1.0
1.0 1.0 1.0
(random 1.0) (random 1.0) (random 1.0)
:cx (* i 3) :cy (* j 3) :cz 0)))))