In this section of Carmacks 2013 quakecon speech, he talks about a programming language called Haskell, and remaking wolfenstein with it. He mentions how this language leads to robust code that will be solid, even years down the road. He went so far to say that people who get into it now will be kicking everyone’s ass in 5 years.
He is VERY long winded, so Ive highlighted some of the important points below the youtube video.
Some of the most important points he makes: Haskell uses Strong + Static typing (as opposed to weak and dynamic). Carmack supports this.
He supports objects being able to look at others but not affect them. (You might be wondering how can a game work like this, well I transcribed his explanation but its a bit chaotic. The basic idea is you create an ‘event’ and this gets passed to the objects that need to know. Quite simple really.
His words not mine (warning: geek speech chaos) + Show Spoiler +
The objects are passed in a reference to a static copy of the world, and themselves And they return their new version at the end. They cant break anybody else, cus they cant touch anything else. Its not allowed by the compiler.
The obvious question is how do you shoot somebody if you cant affect them. What you do is you say, well, im firing my gun, I hit him, the world says I do, I wanna make him die. So you have to make an event of some kind, that gets communicated to the other entity.
In Haskell, its just a partially evaluated function that takes an entity as a parameter and returns another entity. Eg, you can have a ‘Do Damage’ function, you partially evaluate it with your 5 points of damage that is going to be dealt, and then you pass it (parse?) and its just going to take the last function parameter as the entity and you set that up on its own personal list. So every entity sets up a list of all the things they are going to do to anybody, and then at the beginning of the next frame you gather everything together, distribute it all to the entities, and then; The first thing they do, you’ve got the world, you’ve got the list of events that affect them, apply them all, one after another, generating a new copy of themselves, and then They do their thinking and processing, creating the final version that goes back into the world.
He supports code that runs from top to bottom, easy to step through.
He says learn Haskell by doing several small projects first before starting a big one. And he says in 5 years time you will be kicking everyones ass because you will have such a solid core code base. Carmack says he recently spent 6 months fixing problems in his idtech 4 or 5 that would have never surfaced if he had written them in Haskell in the first place. And this is not an isolated case, he has been dealing with many problems like this over the years.
Strong typing The more type restrictions that are imposed by the compiler, the more strongly typed a programming language is. These arent bad restrictions though, they help you not make mistakes. Haskell is very strongly typed. This leads to creating code that is doing what you expect it to do.
Static type checking Static type-checking means that code is checked for type errors very very early, right down at the source code level at compile time. Because static type-checking operates on a program's source code, it allows many bugs to be caught early in the development cycle. Dynamic type checking (the bad way of doing things) happens at runtime, not compile time. This means things can slip through the net that don’t cause any immediate problems, but can come back to bite you a long time later.
I have been studying Haskell since hearing this speech and its interesting so far. I would love to hear from CecilSunkure and all you other programmers, you know who are.
Firstly it would require total rewrites, older programmers are stuck in their ways and finally Haskall is really hard. No problem for Carmack but considering good programmers are hard enough to come by you're just limiting the pool even further.
Its tempting to do something in Haskall and I could see talented Indies doing so but I doubt AAA will go near it.
Apologies for being brief but I'm ducking inside on my tablet to avoid some rain on holiday and typing with my normal verbosity on this thing is tough
i agree with the above in terms of what will actually happen.
personally i do like the concept of a strong/statically typed language that uses some sort of 'messaging'/event system to communicate between objects. regardless of how most app bros write objective-c i'd say thats a decent example but im not referring to any one language.
what you say can be accomplished with other things as well, and people use what they want. most people are not good enough or motivated enough to learn Haskall. I would if my workload goes under 80 hours and i have time.
Haskell is awesome. I took a functional programming course last year and have been obsessed with it since. I didn't realize Carmac was working with it. My understanding (however limited) is that things like game states are difficult to represent functionally. It seems like he's got an interesting approach.
I always like to give big ups to "Learn you a Haskell for Great Good." Great book that's really sort of silly and witty but also super helpful for starting out. I met the author Miran last year when he came to Vancouver to do a talk about Snap (a Django like web framework for Haskell). Super charismatic and unique guy. He ended up doing a demo on a starcraft match database website. :D
http://www.haskell.org/hoogle/ is also super useful. It's a search engine for the language. Can be helpful considering the GHC can often throw error statements at you that are barely understandable.
However cool it all is I think it will take a long time to make an impact. The biggest struggle I've had is finding bigger problems or projects to do functionally or in Haskell. Translating it to real world problems and solutions can be confusing and often no where near as good as just knocking it out in C. I think there is a lot of value in people looking for new problems that are conducive the being solved functionally.
It is always funny to me when you see people that work in "fringe" parts of IT how they can say this will be the next thing in 5 years. It may work nice for writing a game (I checked that they have a library that provides openGL bindings) but if you try to write any type of enterprise applications that the rest of us makes at work. Then it is not about having a nice language but having a nice language that has a gigantic pool of developers worldwide and environment already in place, testing, monitoring, deployment, having a hw that can actually run it are all a huge factor in what you pick - hence why 20% of the stuff in the world runs on Java even when the language is shit compared to anything else that is on JVM (scala)
I aslo wonder how Haskell compares to Erlang where you have OTR and the awesome virtual machine, while this seems like just regular pretty functional language. Could be interesting to play with it, but I think if you want to create some distributed madness go Erlang, if you want enterprise bs you have to do java / c, and if you are the lucky 1% that can do something cool you can play with Haskell but no one will ever convince me, it will land me my next job in 5 years.
Haskell is a different language that the common Object Oriented languages, and that's because it is a Functional programming language and this type of languages are starting to have some usefullness. Surely, legacy systems won't be re-programmed to a new functional language but new programs may be written in those languages.
In addition, if you want to learn something new other than the common Object Oriented languages you could try out Scala. As Haskell, it is a functional programming language, that has many applications and it is easy to program complex systems.
Disclaimer: I haven't used Haskell or search for applications in Haskell, so maybe there are plenty of them too. I am only aware of Scala applications.
Strong / static typing is not the most important part about Haskell or functional programming in general. The most important concept is functional purity, that is lack of side effects and hidden state. The result of pure functions must depend only on their arguments, and cannot depend on or change any implicit external or internal state. For example, in C terms, you cannot have a function int random() that will give you a new number every time you call it. You have to pass it the current state of the RNG, and it will give you the number and the new state that you give it next time. This may seem cumbersome, but there are constructs that allow you to neatly abstract away this state-passing while still maintaining purity (monads, data structures that are everywhere in Haskell).
Another concept is mutability, or rather lack thereof. There is no notion of a "variable" in a (pure) functional language, there are only values. If you write x = 5, this means that x is 5 and nothing else. Writing x = x + 1 is nonsense.
As a consequence, there can be no mutable data structures. You cannot just "add" something to a list. You can only produce a new list, which will have all elements that the old one had and with new one added. If you extrapolate this to more interesting objects, you cannot e.g. set a title of a window. You have to create a new window with the new title, and replace the old one.
This doesn't seem very efficient or even practical at first, but when you program in this style for a while you realise the one most important benefit: your programs fucking work. Those limitations result in removing whole classes of very common mistakes simply because the language does not allow you to make them. Null pointer exceptions, uninitialized variables, index counters missing the array size by +1 or -1, ambiguous function interfaces that allow you to modify arguments, ambiguous object ownership, all that crap that you spend days trying to debug is magically gone.
But you have to pay for this of course. The cost is mostly performance, and (in Haskell specifically) difficulty in assessing how the program will actually be executed and how much memory it is going to take. In functional programming you do not give the complier a sequence of steps to follow. You sort of explain what things are using equations, and then the compiler figures out how best to run those computations. It can do it in parallel, or in any order, you are not supposed to know or assume anything.
One more thing is that most of the popular languages are sort of converging to the same idea of functional purity and immutable data structures (mostly because this *really* helps when programming highly concurrent applications), only from different starting points. Like in C# you have those very functional-like collection methods - Select, Aggregate etc. - added on top of a traditional imperative language where you can otherwise do a lot of "bad things", and Haskell starts from another extreme where everything is pure, and you have to find ways to represent state or mutable data.
On August 28 2013 03:16 artynko wrote: It is always funny to me when you see people that work in "fringe" parts of IT how they can say this will be the next thing in 5 years. It may work nice for writing a game (I checked that they have a library that provides openGL bindings) but if you try to write any type of enterprise applications that the rest of us makes at work. Then it is not about having a nice language but having a nice language that has a gigantic pool of developers worldwide and environment already in place, testing, monitoring, deployment, having a hw that can actually run it are all a huge factor in what you pick - hence why 20% of the stuff in the world runs on Java even when the language is shit compared to anything else that is on JVM (scala)
I aslo wonder how Haskell compares to Erlang where you have OTR and the awesome virtual machine, while this seems like just regular pretty functional language. Could be interesting to play with it, but I think if you want to create some distributed madness go Erlang, if you want enterprise bs you have to do java / c, and if you are the lucky 1% that can do something cool you can play with Haskell but no one will ever convince me, it will land me my next job in 5 years.
Learning a functional language is extremely helpful even if your plan is to stick with Java, C# or whatever. Just wrapping your head around those concepts creates such a breakthrough in your understanding of how to structure programs that you start feeling like Neo when he had suddenly started seeing the Matrix code - you start to see so many things that you had previously just taken for granted, so many potential errors and dangerous code parts that you never realised could be avoided simply because you were stuck in the "imperative" way of thinking. It really takes you to another level as a software developer.
I think he has some valid points. Functional languages are, in my opinion, gonna be used more and more. Especially because of immutability, purity and better concurrency than languages that use shared memory model like java or C.
Of course, you cant program without defining state, but i watched some talks about functional programming and my understanding is that it allows you to define state and its changes more clearly and restrictively.
About Haskell.. we used it at our undergraduate course on functional programming and its good language. You can even program web apps in it. Check Snapp framework for details. Problems is, it is not widely used in companies. On the other hand, I think functional languages on JVM (Scala, Clojure) are being adopted and are gonna be adopted widely in future. Because they provide benefits of immutability and other functional features into java ecosystem and companies with huge code bases can slowly integrate their old java code into code written in scala or clojure.
Also if you want to learn more about functional programming I recommend http://learnyouahaskell.com/ (as other guys mentioned) and Coursera online courses Functional Programming Principles in Scala. The course is taught by Martin Odersky, who invented Scala and helped to introduced generics into Java.
i agree functional languages/constructs will become more mainstream (just look at scala) but haskell isnt at all easy to learn (coming from somebody who knows the usual java/C languages), i had so much problems figuring out haskells type system compared to other functional languages. agree with the posts that conceptually at an abstract level things make a lot more sense but of course we sometimes dont know how the computer actually handles it performance wise, which is absolutely a legit criticism. i think carmack is also safely assuming computers and these languages will just get plain faster with time. when java first came out, it was obscenely slow but now they've patched up the language to be quite fast
@OP: hes actually talking about haskell forces concepts that will kick everyones ass years down the road, not haskell itself. Hes talking about pure functions and the like. Its also a problem with current languages, that functional languages tend to fix.
On August 28 2013 11:46 CptCutter wrote: @OP: hes actually talking about haskell forces concepts that will kick everyones ass years down the road, not haskell itself. Hes talking about pure functions and the like. Its also a problem with current languages, that functional languages tend to fix.
For me the problem with functional languages is that you can't do "proper" architecture using it (or we don't know how to do it yet) For example I did a fairly decent sized production software that was written in Erlang (another functional language) it was awesome for what it did, it had probably 10 times less lines of code that if I have written it in anything conventional, but at the end when I was trying to juggle 30 different actors I was starting to feel that a miss the nice architecture I would had had in OO language. I still love the concepts that a functional language brings mainly immutability and the way concurrency is handled there. When Java 8 comes I will jam that one down my teams throats faster then light (oh closures & functional collection manipulation) but still if anyone asked me if they should learn something like Haskell I would say hell no, learn Scala
Functional languages are very interesting to work with, and the code usually becomes very pure which is nice, especially from an academic standpoint. However, it's just not comfortable and productive to work with professionally for many reasons. Among them: When you're used to more "standard" programing, you need quite a lot of effort to produce the same functional code. Another issue is the lack of experience. If you're a haskell guru, that's really cool, but chances are you will not be the only programmer working on a project and finding people who are interested in using haskell for the project will be hard.
On August 28 2013 16:34 artynko wrote: For me the problem with functional languages is that you can't do "proper" architecture using it (or we don't know how to do it yet) For example I did a fairly decent sized production software that was written in Erlang (another functional language) it was awesome for what it did, it had probably 10 times less lines of code that if I have written it in anything conventional, but at the end when I was trying to juggle 30 different actors I was starting to feel that a miss the nice architecture I would had had in OO language. I still love the concepts that a functional language brings mainly immutability and the way concurrency is handled there. When Java 8 comes I will jam that one down my teams throats faster then light (oh closures & functional collection manipulation) but still if anyone asked me if they should learn something like Haskell I would say hell no, learn Scala
what do you mean by architecture?
On August 28 2013 17:11 Tobberoth wrote: Functional languages are very interesting to work with, and the code usually becomes very pure which is nice, especially from an academic standpoint. However, it's just not comfortable and productive to work with professionally for many reasons. Among them: When you're used to more "standard" programing, you need quite a lot of effort to produce the same functional code. Another issue is the lack of experience. If you're a haskell guru, that's really cool, but chances are you will not be the only programmer working on a project and finding people who are interested in using haskell for the project will be hard.
it is a pain in the ass. but it sure is nice looking at that nice elegant code you just written even if its just 3 lines. haskell is the most anal of any functional language i've used though
On August 28 2013 11:46 CptCutter wrote: @OP: hes actually talking about haskell forces concepts that will kick everyones ass years down the road, not haskell itself. Hes talking about pure functions and the like. Its also a problem with current languages, that functional languages tend to fix.
Wait so what's the problem exactly?
Pretty much, in a functional language, using a function will always give you the same output, no matter what context you run it. The function only depends on input variables and gives back output data, no side-effects. You can take a program, insert a function somewhere in the middle, and the program won't change since again, no side-effects. In more standard languages like C, Java etc, you're perfectly free to implement side-effects in your functions, such as editing variables in a higher scope, changing global objects, editing the input parameters... basically, you can easily make a function which changes output depending on context, maybe even giving you a different output if you use it immediately after you've used it.
On August 28 2013 16:34 artynko wrote: For me the problem with functional languages is that you can't do "proper" architecture using it (or we don't know how to do it yet) For example I did a fairly decent sized production software that was written in Erlang (another functional language) it was awesome for what it did, it had probably 10 times less lines of code that if I have written it in anything conventional, but at the end when I was trying to juggle 30 different actors I was starting to feel that a miss the nice architecture I would had had in OO language. I still love the concepts that a functional language brings mainly immutability and the way concurrency is handled there. When Java 8 comes I will jam that one down my teams throats faster then light (oh closures & functional collection manipulation) but still if anyone asked me if they should learn something like Haskell I would say hell no, learn Scala
what do you mean by architecture?
The standard approach that everyone uses to separate stuff in oo, services, daos, domain object, facades having all the oo patters at yours disposal, when I was doing Erlang I had problems with how do I want to connect all the different parts of the application together, when I coded it in similar fashion as I was used from OO it usually did create either circular references or some horrible unclear dependencies. In the end I ended up with a tree like structure that resembled something you would create using OO and the standard tiered architecture but the "levels" of the tree didn't always contain processes that belonged together and the tree had way more levels . Then when I returned back to this code after couple of months I was completely lost and had no idea where the different processes belong and how deep in the tree they are. If you compare this to OO even when I look at my old code and want to add new stuff there I know where to start, you just look for the service in question and go on from there. It just feels like there is no knowledge how to do stuff in functional languages the "right" way compared to OO where we already know how to create something that is manageable and every developer will understand it when he sees it for the first time
I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
On August 28 2013 19:39 3FFA wrote: I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
Unless you have some experience with functional languages though, it will probably look like some black magic spell though, functional code usually looks very different from what you might be used to.
On August 28 2013 16:34 artynko wrote: For me the problem with functional languages is that you can't do "proper" architecture using it (or we don't know how to do it yet) For example I did a fairly decent sized production software that was written in Erlang (another functional language) it was awesome for what it did, it had probably 10 times less lines of code that if I have written it in anything conventional, but at the end when I was trying to juggle 30 different actors I was starting to feel that a miss the nice architecture I would had had in OO language. I still love the concepts that a functional language brings mainly immutability and the way concurrency is handled there. When Java 8 comes I will jam that one down my teams throats faster then light (oh closures & functional collection manipulation) but still if anyone asked me if they should learn something like Haskell I would say hell no, learn Scala
what do you mean by architecture?
The standard approach that everyone uses to separate stuff in oo, services, daos, domain object, facades having all the oo patters at yours disposal, when I was doing Erlang I had problems with how do I want to connect all the different parts of the application together, when I coded it in similar fashion as I was used from OO it usually did create either circular references or some horrible unclear dependencies. In the end I ended up with a tree like structure that resembled something you would create using OO and the standard tiered architecture but the "levels" of the tree didn't always contain processes that belonged together and the tree had way more levels . Then when I returned back to this code after couple of months I was completely lost and had no idea where the different processes belong and how deep in the tree they are. If you compare this to OO even when I look at my old code and want to add new stuff there I know where to start, you just look for the service in question and go on from there. It just feels like there is no knowledge how to do stuff in functional languages the "right" way compared to OO where we already know how to create something that is manageable and every developer will understand it when he sees it for the first time
interesting, i've never had that problem, but i dont know anything about erlang, most of my experience is in ocaml and haskell. ocaml/F# has a number of object features while haskell isnt oo but is pretty clear about structure through modules and its type system, but its very expressive type system can be an absolute pain to learn... its compiler error messages are almost never helpful.
personally i feel that if the code feels more natural to be imperative or OOP or functional then it should probably be in such a language...
On August 28 2013 19:39 3FFA wrote: I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
On August 28 2013 19:39 3FFA wrote: I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
From what I remember when I was looking at it yesterday Java -> "astring".substring(1); Haskell -> tail "astring" or drop 1 "astring"
Mainly what is cool about functional languages is the way you can do cycles with pattern matching so this java code private void output(String a) { while (a.lenght > 0) { sysout(a); a = a.substring(1); } }
can be rewritten like this, you suddenly don't mess up with the 'a' object and it is very clear when the end of the "cycle" is output([]) -> ok output(a) -> prinnt(a), output(tail(a));
then when you type somwthere ouput("keke"), it will look at the various heads for the output function and patter match the value so the first one (outuput([])) is only matched when there is blank array as argument so it skips that one and uses the other one to print the first character, and then recursively calls itself again with the remaining characters
Really it sounds to me like Haskell is just enforcing some good programming practices, which can be achieved by good programmers in C++ (as seen by my link). To me the solution to a lot of problems is to just have good programmers use C++, instead of forcing bad programmers to write better code. But of course good programmers are rare and hard to come by.
I read up on some haskell after reading the OP and it's quite a fascinating language, definitely my favorite functional language so far (tried F# and scheme in the past). It's the first language where writing recursive functions makes perfect sense to me (because the syntax is beautiful), and it blew my mind when I realized haskell compiles to machine code and can, in theory at least, be faster than C++ if you write it really well.
It's a downright shame that side-effect handling takes such a weird form... pure programming is cool, but the syntax for IO and such things in haskell just becomes really confusing and uncomfortable.
On September 03 2013 05:53 CecilSunkure wrote: Ha, funny that you focused much on object to object messaging, which I just moments ago finished posting some slides for a lecture I gave at my university. http://www.randygaul.net/2013/09/02/powerful-c-messaging/
Really it sounds to me like Haskell is just enforcing some good programming practices, which can be achieved by good programmers in C++ (as seen by my link). To me the solution to a lot of problems is to just have good programmers use C++, instead of forcing bad programmers to write better code. But of course good programmers are rare and hard to come by.
its not fair to either language to talk about it simply like that, i recommend at least dabbling in some haskell to understand the viewpoint where carmack is talking from. hes not saying haskell is all that and everything, but looking at certain problems and code from a different viewpoint can be enlightening
On September 03 2013 15:35 Tobberoth wrote: I read up on some haskell after reading the OP and it's quite a fascinating language, definitely my favorite functional language so far (tried F# and scheme in the past). It's the first language where writing recursive functions makes perfect sense to me (because the syntax is beautiful), and it blew my mind when I realized haskell compiles to machine code and can, in theory at least, be faster than C++ if you write it really well.
It's a downright shame that side-effect handling takes such a weird form... pure programming is cool, but the syntax for IO and such things in haskell just becomes really confusing and uncomfortable.
it is a really cool and fascinating language, but for the same reasons impractical for the all but a fraction of the industry. sure is interesting to write things in it though. also the IO is weird yes, but if u get used to monads its quite natural, plus there are ways you can cheat around it
i thought F# can compile to machine code? i've used ocaml quite a bit, haskell isnt optimized that well with respect to overhead (theory can only go so far by itself), so ocaml is still generally faster, and F# is also very fast (maybe even faster?), since currently F# is still very close to ocaml
Hmm, I can find no resource on compiling F# to native, Visual F# obviously compiles to CIL. Not that it's such a huge deal, compiling to native isn't the massive speedgain it used to be since everything does just-in-time compilation nowadays.
This is especially true if you know how to exploit strict evaluation and various Haskell quirks about optimization. Where Haskell definitely falters is space usage simply because lazy evaluation means that a lot of computation is left "suspended", waiting to be executed at a yet-to-be-determined time.
The way that side-effects are handled in Haskell is necessary insofar as side-effects destroy referential transparency which is where Haskell gains much of its properties. Its purity guarantees are even stronger than OCaml/F# (which allow "un-scoped" mutation via ref cells and/or objects) which allows for even greater allowance to rely on types to guide development.
One example of how you can rely on types more in Haskell than traditional languages is the encoding of domain-specific languages whose own type properties are checked by Haskell at compile-time. For example, here is a definition of a small calculator language with integers, booleans, addition, greater-than-or-equal comparison, and conditionals (*1):
{-# LANGUAGE KindSignatures, GADTs #-}
data Exp :: * -> * where IConst :: Int -> Exp Int BConst :: Bool -> Exp Bool Add :: Exp Int -> Exp Int -> Exp Int GTE :: Exp Int -> Exp Int -> Exp Bool If :: Exp Bool -> Exp a -> Exp a -> Exp a
The type Exp a denotes expressions whose underlying Haskell value are a (i.e., it is a polymorphic type). Examples of terms constructed in this little language are:
Notably, the definition of Exp above prevents from writing ill-typed terms in this sub-language. For example:
*Main> Add (IConst 0) (BConst False)
<interactive>:8:17: Couldn't match type `Bool' with `Int' Expected type: Exp Int Actual type: Exp Bool In the return type of a call of `BConst' In the second argument of `Add', namely `(BConst False)' In the expression: Add (IConst 0) (BConst False)
That is, the definition of the Add term requires two Exps that evaluate to Haskell Ints. Similarly
If (BConst True) (IConst 0) (BConst False)
is also ill-typed because If requires that the two branches produce the same type of value.
Note that if you tried to implement this in Java naively (*2), e.g.,:
public class Exp { } public class IConst extends Exp { public int i; } public class BConst extends Exp { public boolean b; } public class Add extends Exp { public Exp e1; public Exp e2; } public class GTE extends Exp { public Exp e1; public Exp e2; public boolean b; } public class If extends Exp { public Exp b; public Exp e1; public Exp e2; }
There is nothing stopping you from having an instance of an Add term whose two sub-expressions are booleans rather than integers. You would need to check either at construction or when the expression that the expressions are indeed of the correct type.
Finally, to close here's an example of how you'd use this little language in Haskell. The eval function takes a built-up up Exp, evaluates it, and returns the corresponding Haskell value:
eval :: Exp a -> a eval (IConst i) = i eval (BConst b) = b eval (Add e1 e2) = eval e1 + eval e2 eval (GTE e1 e2) = eval e1 + eval e2 eval (If b e1 e2) = if eval b then eval e1 else eval e2
Running this function on each of the (good) examples above produces the proper Haskell value:
(*1): This example uses an advanced feature of Haskell called Generalized Algebraic Datatypes or GADTs. A GADT is a datatype whose constructors' return types can be freely chosen.
(*2): This example can be encoded using Java generics and C++ templates. However, more complicated examples of GADTs are not possible using Java generics and C++ templates as-is. Both languages require additional features, i.e., type parameter constructors, to emulate the full functionality of GADTs.
Most programmers are too lazy or stupid to see the benefits in using good programming languages. Until then, Java, C++, PHP, etc. will continue to reign supreme. The non-remedial will look into Standard ML, Haskell, OCaml and Scheme, to some extent. The three former-most in that order. The latter-most is just fun and has a lot of good documentation, but I've fallen out of favor with weakly typed languages.