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?
EPT
