rationalskepticism.org

stalidon wrote:What do you guys work at/study? I never completed uni, but I've been a programmer since the 80's

Heh, I am not that old, only been doing it since '97 or so

stalidon wrote:
I have a small IT company and been in the 'industry' for a long time. Let me tell you: if you want to keep working with interesting stuff like this, stay as far away as you can from the 'industry'.

Duly noted, but the monies are always welcome though
But seriously though, at least if you are working with a small team, there is always room to use something 'interesting', even if you can't go all the way by say, using Haskell, you can always trade a bit of the productivity of using the same tired old stuff for some entertainment, if you can keep the balance right.

VazScep wrote: That's seriously cool.

Yes indeed
shared_ptr has been part of boost for some time now, glad it got accepted.

VazScep wrote:
I guess my sniveling concern is adoption. Having first-class lambdas could open up C++ to a lot of new and enticing solutions to existing problems, before we start getting into the sorts of clever tricks you'll be able to play with classes, subtyping and templates. There could be a lot of libraries that would benefit from having their APIs extended or even rewritten to support the new constructs.

Well, there is a lot of people out there really pumped with all this new stuff, and if you look around, say for instance in github, you will see the place is choke-full of people creating new libs that solve problems already handled by well established ones, except that by doing it the c++11 way. Some of it is promising, some of it looks like shit, but it's only wait and see now.
About the old libraries, well that varies a lot. There has not been a lot of time since the spec got published, and there is no fully conformant compiler / STL implementation yet. Lot's of libraries in boost for instance have been updated to accept and work well with the new additions, but there are still rough edges and not every new feature has been exploited yet.
But still you have got other libraries like Qt which are still using pretty ancient c++ lingo, and still uses that infamous preprocessor called 'moc', for things that could be done just using the standard lib. I've read on their mailing list that they have committed themselves to supporting at least the new stuff which only requires superficial changes and which can be optional, but I guess they still have to support ancient platforms with no hope of ever seeing a c++11 compliant compiler, so I venture to say that no radical changes in the API are to be expected for years to come. Plus their codebase is pretty huge...

VazScep wrote:
I wonder to what extent this will mean that C++ styles and idioms will just become ever more diverse.

Well yes, right now you will find some cutting edge libs, and also some arcane c++98 ones which don't even use exceptions or the STL containers.
But at least a lot of thought has been put into backwards compatibility, so you could for example use the new fancy stuff and glue it with old interfaces. A lot of the STL containers give you access to the underlying pointer if you ask for it, and so does shared_ptr. I have done this a lot actually.

VazScep wrote:
Isn't this a problem even with vanilla C++, that you still have folk who treat it as C with some extensions?

Well I haven't come across one of those for a long time, but I guess that depends on the area of expertise you are working.
The examples I used to see were of folks doing it just because the visual studio C compiler sucked, so they compiled C code as C++.

VazScep wrote:
This is very much a problem which plagues Common Lisp, and I suspect it's one that the Java developers intentionally avoided by keeping their feature set on a tight leash.

Yes, but the Java guys haven't been always successful at that. Last I checked, their GUI situation was a mess, with AWT, swing, SWT etc still competing. But then looking at that side, the other languages do not fare better, except perhaps C#.

VazScep wrote:Nope. Maybe the Schemers would. Those were always the academic sort. But then again, Schemers are obsessed with their call/cc, which is almost as dangerous a construct as GOTO.

Most lisps have always allowed seriously nasty destructive side-effects. I think this is for a number of reasons: firstly, people were building machines that were Lisp all the way down to the hardware, and where the operating system was just a Lisp runtime and the scripting language was the Lisp REPL. The only sort of Lisp that can cope with that is one which can cope extremely well with state and global access to data, and which allows you to happily bring the system crashing down on itself just like you can with a good old UNIX box. This sort of thing also calls for a lot of reflection mechanisms. Just like you can see every program accessible to you at your shell and you can redefine shell commands, you should be able to see every Lisp function in your runtime environment and redefine symbols (and you should be able to look at their source code, and recompile them, and uninline them and relink them --- Common Lisp runtimes still perform many tasks that are normally reserved for the OS, and are typically more sophisticated).

The sort of crazy self-modifying power led to various crazy engineering. Brian Smith had wacky ideas about being able to reflect into what is conceptually your own interpreter, and then reflect again (an arbitrary number of times), redefine your semantics and reflect back down again into a new programming language. This fully working nonsense eventually became the Lisp MetaObject Protocol, a self-bootstrapping OO system that allows you to redefine the behaviour of classes and generic function dispatch in a way which would confuse Lewis Carroll (though the applications of this idea are pretty sweet, such as Allegro Common Lisp's seamless system whereby you can have billions of objects in your runtime which are automatically offloaded into databases when your memory fills up).

That one is a pretty sweet idea indeed.

VazScep wrote:
Basically, Lisp is a monster, for arguably good reasons. But for some bizarre reason, a lot of universities seem to teach only toy versions of it. I can't remember how many times I've encountered the claim that Lisp is not a compiled language, or the claim that every data structure in Lisp is a cons.

Well, to be 'fair' to them, that was their introductory course to programming, but you would rarely see it again later in the course. I don't think any of the professors had a vested interest in it, I don't remember seeing anything being published on the matter.

Well, if you're interested at all in formal logic, the original inspiration for ML and its earliest applications (such as Logic of Computable Functions) are still, IMO, some of the smartest and coolest examples of functional programming engineering and awesome uses of type abstraction and higher-order functions. I can throw some simple Haskell code your way if you're interested.

Sure I am, thanks