7 ms·

In case you missed it, John discussed his functional programming adventures in Haskell at QuakeCon 2013... well worth a listen. "So what I set out to do was ta

by Arjuna 12y ago

In case you missed it, John discussed his functional programming adventures in Haskell at QuakeCon 2013... well worth a listen. "So what I set out to do was take the original Wolfenstein 3D, and re-implement it in Haskell." [...] "I've got a few conclusions coming from it. One of them is that, there's still the question about static vs dynamic. I know that there was a survey just coming out recently where the majority of programmers are still really not behind static typing. I know that there's the two orthogonal axes about whether types are strong or weak, and whether it's static or dynamic. I come down really pretty firmly, all my experience continues to push me towards this way, that strong, static typing has really significant benefits. Sometimes it's not comfortable, sometimes you have to build up a tight scaffolding to do something that should be really easy, but there are real, strong wins to it." https://www.youtube.com/watch?v=Uooh0Y9fC_M#t=4876 https://www.youtube.com/watch?v=Uooh0Y9fC_M#t=4876 (Starts at approximately 1:21:16 in case the direct link doesn't work correctly.)

vog 12y ago
At at beginning he says that he is kind of sold on most Haskell, but doesn't know if lazy evaluation is so great. I wonder why he didn't try OCaml then. He doesn't even mention this possibility, he just goes on to compare Haskell to Lisp. Regarding issues with lazy evaluation, there may be some truth to it. This reminds of a great article by Robert Harper: https://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/ https://existentialtype.wordpress.com/2012/08/26/yet-another...
nickbauman 12y ago
I used to think that way too. I've met programmers who still don't write unit tests and are not test driven and remain brilliant. Carmack is one of these guys. I think the static / strong typing thing works well with them because they never developed the practices. If you're test-driven, you're basically building up your own, domain specific compiler as you go not having to play by a language-specific static type systems rules. Dynamic typing make writing code this way really easy. Static typing doesn't. In the end I want the types of my system to work they way my system needs to. I could care less about the type system of merely a language (as applied to my system). And types are just one way to enforce correctness. Lately I find with languages in the Lisp family, these other types of tools feel much more productive, easier to reason about and flexible to me than type systems. When I believed in static typing I felt very busy, but I was mostly spending my time making the compiler happy, rather than the other way around.
- illumen 12y ago
  Nicely put. I'd also argue that the divide between dynamic, and static typing systems has fallen down. Almost completely. Java/C# and even Haskell have dynamic typing. They even sort of have a scripting feel. However, you can also statically type dynamic languages, and dynamic languages are getting static typing too. For example, JavaScript with asm.js. Lots of type inference is done by IDEs and lint systems now. Even with python, static type checking is very possible (both at the C level, and at the python level).
  - moron4hire 12y ago
    I don't know about the other languages, but while C# may have dynamic typing, it's extremely uncommon to see it in use. It's introduction was to make certain types of interop easier. It was not intended to be a general-purpose programming feature.
- sbergot 12y ago
  Except that to perform the level of checks that a compiler does with a good type system, you would have to write a large amount of tests. Code is a liability, and testing code is no exception. Writing tests in static languages is still required. You just have to write a smaller amount of them. What's more, type checking is enforced in a more systematic way. With tests, you have to rely on people to write them. If a type system is well designed, people will use it to model their code, and the type checking is done automatically. What's more, types should not be reduced to the type checking phase. Types are a way to provide a high level model/structure. You still need this if you are working in a medium/large project. With static types, this model have nicer semantics, and is more useful.
  - nickbauman 12y ago
    Ok try this: Go model a square and a rectangle in your favorite statically typed language. You will find that square extends rectangle and setting the length on a square also sets the width. So far so good? So if I have a collection of rectangles which contains an unknown number of squares of which I set the width on each of them. You can't answer the question as to whether the result is correct or not. And I have just destroyed your type system's purpose by using polymoronism, expectoration and dispossession, the three-legged stool of static typing OO, with a very simple and well-defined domain subset of geometry. Of course it's contrived but since I've been programming (which is longer than I care to say here, because it really dates me) this is basically where I'm at with static type systems. AS long as I've spent with them I find they're not as useful as they should be. I haven't tried Haskell (I probably should) but I'm getting too much done with dynamic languages, especially Lisps, to look back right now. Too much power to look away. Tschau!
virtualwhys 12y ago
and for the whole picture vis-a-vis game dev: "I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language. To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields. We have cross-platform issues, proprietary tool chains, certification gates, licensed technologies, and stringent performance requirements on top of the issues with legacy codebases and workforce availability that everyone faces." [0] Which may be why we haven't heard a peep from Carmack on the subject since. Could see pure FP languages entering performance critical domains like game development in the not too distant future, but for now the state of the art isn't quite there. [0] http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
- m_mueller 12y ago
  I'm doing HPC work for a few years now and I'm familiar with FP concepts, use it (albeit never purely so far) in non performance critical code where maintainability and testability is more important. My question: How could it even work in performance critical domains? Most of the time memory bandwidth is the limiting factor, thus copying memory and cleaning up unused memory are very expensive. With pure FP, all I can do is hope the compiler won't create all the copies I'm instructing it to do and optimize it back to procedural in-place update. When that doesn't work all I can do is reimplement it procedurally. How does anyone think that this programming concept can be applied for high performance domains? What am I missing?
  - Athas 12y ago
    A possible solution would be to devise a language with a type system that tracks allocation, such that a garbage collector is not needed, and that all allocation deterministic, and yet safe. Some work has been done on this already, in the form of region inference systems, although they have to my knowledge only been used to compile functional languages to run without a garbage collector, and not been exposed in the user-visible type system. The MLkit compiler for Standard ML is the most prominent region-user I am aware of.
fulafel 12y ago
Notice that he stresses there are benefits, but nowhere does he say that the costs necessarily outweigh the benefits.

by Arjuna 12y ago

vog 12y ago

At at beginning he says that he is kind of sold on most Haskell, but doesn't know if lazy evaluation is so great. I wonder why he didn't try OCaml then. He doesn't even mention this possibility, he just goes on to compare Haskell to Lisp. Regarding issues with lazy evaluation, there may be some truth to it. This reminds of a great article by Robert Harper: https://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/ https://existentialtype.wordpress.com/2012/08/26/yet-another...

nickbauman 12y ago

I used to think that way too. I've met programmers who still don't write unit tests and are not test driven and remain brilliant. Carmack is one of these guys. I think the static / strong typing thing works well with them because they never developed the practices. If you're test-driven, you're basically building up your own, domain specific compiler as you go not having to play by a language-specific static type systems rules. Dynamic typing make writing code this way really easy. Static typing doesn't. In the end I want the types of my system to work they way my system needs to. I could care less about the type system of merely a language (as applied to my system). And types are just one way to enforce correctness. Lately I find with languages in the Lisp family, these other types of tools feel much more productive, easier to reason about and flexible to me than type systems. When I believed in static typing I felt very busy, but I was mostly spending my time making the compiler happy, rather than the other way around.

illumen 12y ago
Nicely put. I'd also argue that the divide between dynamic, and static typing systems has fallen down. Almost completely. Java/C# and even Haskell have dynamic typing. They even sort of have a scripting feel. However, you can also statically type dynamic languages, and dynamic languages are getting static typing too. For example, JavaScript with asm.js. Lots of type inference is done by IDEs and lint systems now. Even with python, static type checking is very possible (both at the C level, and at the python level).
- moron4hire 12y ago
  I don't know about the other languages, but while C# may have dynamic typing, it's extremely uncommon to see it in use. It's introduction was to make certain types of interop easier. It was not intended to be a general-purpose programming feature.
sbergot 12y ago
Except that to perform the level of checks that a compiler does with a good type system, you would have to write a large amount of tests. Code is a liability, and testing code is no exception. Writing tests in static languages is still required. You just have to write a smaller amount of them. What's more, type checking is enforced in a more systematic way. With tests, you have to rely on people to write them. If a type system is well designed, people will use it to model their code, and the type checking is done automatically. What's more, types should not be reduced to the type checking phase. Types are a way to provide a high level model/structure. You still need this if you are working in a medium/large project. With static types, this model have nicer semantics, and is more useful.
- nickbauman 12y ago
  Ok try this: Go model a square and a rectangle in your favorite statically typed language. You will find that square extends rectangle and setting the length on a square also sets the width. So far so good? So if I have a collection of rectangles which contains an unknown number of squares of which I set the width on each of them. You can't answer the question as to whether the result is correct or not. And I have just destroyed your type system's purpose by using polymoronism, expectoration and dispossession, the three-legged stool of static typing OO, with a very simple and well-defined domain subset of geometry. Of course it's contrived but since I've been programming (which is longer than I care to say here, because it really dates me) this is basically where I'm at with static type systems. AS long as I've spent with them I find they're not as useful as they should be. I haven't tried Haskell (I probably should) but I'm getting too much done with dynamic languages, especially Lisps, to look back right now. Too much power to look away. Tschau!

virtualwhys 12y ago

and for the whole picture vis-a-vis game dev: "I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language. To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields. We have cross-platform issues, proprietary tool chains, certification gates, licensed technologies, and stringent performance requirements on top of the issues with legacy codebases and workforce availability that everyone faces." [0] Which may be why we haven't heard a peep from Carmack on the subject since. Could see pure FP languages entering performance critical domains like game development in the not too distant future, but for now the state of the art isn't quite there. [0] http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

m_mueller 12y ago
I'm doing HPC work for a few years now and I'm familiar with FP concepts, use it (albeit never purely so far) in non performance critical code where maintainability and testability is more important. My question: How could it even work in performance critical domains? Most of the time memory bandwidth is the limiting factor, thus copying memory and cleaning up unused memory are very expensive. With pure FP, all I can do is hope the compiler won't create all the copies I'm instructing it to do and optimize it back to procedural in-place update. When that doesn't work all I can do is reimplement it procedurally. How does anyone think that this programming concept can be applied for high performance domains? What am I missing?
- Athas 12y ago
  A possible solution would be to devise a language with a type system that tracks allocation, such that a garbage collector is not needed, and that all allocation deterministic, and yet safe. Some work has been done on this already, in the form of region inference systems, although they have to my knowledge only been used to compile functional languages to run without a garbage collector, and not been exposed in the user-visible type system. The MLkit compiler for Standard ML is the most prominent region-user I am aware of.

fulafel 12y ago

Notice that he stresses there are benefits, but nowhere does he say that the costs necessarily outweigh the benefits.