Slashdot Mirror

> just remember that this opinion rant on The Guardian is coming from someone ...

This isn't just some dumb schmo off the internet. Maybe if you had written the Unreal Engine, or an optimized texture mapper in x86 assembly that supported dithering, written an whitepaper entitled The Next Mainstream Programming Language", AND been responsible for open sourcing the entire Unreal Engine then maybe we'd find you to be a little more credible. Tim is looking at the *big* picture, along with Valve. The more MS tries to be like Apple or Google the more game devs they piss off. Continued long enough it will reach critical mass.

> just like how Windows has had UAC for a decade now.

Riiight, because MS's solution is to *spam the user with modal dialog boxes*. When most people that crap off how is it solving the problem again???

What some professors do now at the University of Saarland (Germany) is to define three zones.
If you want to use the laptop for taking notes in class, you sit in the first rows, and if you want to do whatever else you sit in the last rows way back.
In the middle there is a DMZ without laptops at all.

The idea is to avoid getting distracted by flashy graphic stuff happening before you when you want to pay attention.

But FP requires explicit notation when the opposite is true, when sequence matters.

Well, not really, no. Laziness requires explicit sequencing, sure, but not all functional languages are lazy (e.g. SML/OCaml). And you still get a lot of the same benefits from them. What really matters there is functional purity - so long as it's there, it's easy to parallelize. In that sense, the functional approach of "pure by default", with all mutable state marked explicitly, is a Good Thing. It's even better when it's lifted to the type system, as it's done in Haskell - that's your explicit notation.

Now, obviously, it's best to use sensible defaults - i.e. explicit notation should be required for cases that are relatively rarer than those covered by default. And here's the interesting thing:

(from "The Next Mainstream Programming Language: A Game Developers Perspective", by Tim Sweeney)

For-loops in Unreal:
- 40% are functional comprehensions
- 50% are functional folds

So perhaps functional and pure is actually a reasonable default?

In all honesty this is from 1992 so they may very well have a new implementation, but it does sounds to me like the Haskell compiler at the time produced source code in the mother of all imperative languages.

There's no escaping from it - in the end, assembler is an imperative language. But here we get to that "what vs how" difference in approach between functional and imperative. That C code that is output is an implementation detail - it can even be different depending on the target platform it is generated for, and compiler options (number of cores, etc). Could I hand-code it for any given case? Yes, of course. Do I want to do that? Absolutely not.

Does that not show that many of the benefits of FP can be brought to imperative languages by just following conventions?

Sure. And you could also mention that gcc can optimize tail calls these days :) But conventions are brittle things, and optimizing compilers are only so good (both in imperative and in FP world). Even with an ideal compiler, it's all to easy to change an implementation of some small and seemingly unimportant C function, making it non-pure in the process, and have that purity change chain-propagate throughout your entire program, rendering it all non-parallelizable all of a sudden. Same goes for constness analysis (though C/C++ const is pretty useless as far as these things go, as it doesn't guarantee the client that no-one can change the value - merely that he cannot).

And as soon as you start adding "pure" and "const" and "immutable" to the language to move from convention to static checking, and using the idioms involving them heavily, you're effectively doing FP :)

(by the way, gcc is pretty much there - it has proper lexically closing nested functions and tail calls! ;)

And this is what actually happens to some programming languages today. D 2.0 has "immutable" and "pure" (and closures, and ad-hoc polymorphism), even though it's an imperative language on the whole. Thing is, it isn't really, anymore - the line is blurring, and blurring fast. It used to be that closures were considered an arcane feature in mainstream - and now C# and VB (of all languages!) have it and use it heavily, C++ is following with its own lower-level alternative, and Java gurus are ashamed that their own closures proposals are going to miss Java 7. Back to .NET, PLINQ effectively requires functional purity and lazy evaluation, and MSDN Library has articles in it which are essentially FP tutorials for C# and VB programmers. Just five years ago, who could've thought?

And well, that gives me hope that we'll see STM

game developers have long taken advantage of dedicated vector coprocessors with highly-specialized instruction sets and architecture made specifically for 3D gaming.

For an interesting perspective on parallelization in general, and FP use in particular, specifically in the game development field, it's worth reading through Tim Sweeney's presentation "The Next Mainstream Programming Language: A Game Developers Perspective". It specifically mentions referential transparency, STM, and Haskell quite a lot :)

For those who don't know who Tim is - he's the developer mastermind behind the Unreal Engine technology, ever since the very first Unreal game.

What's even more interesting is that the presentation is 3 years old now. So, on the subject of TFA: yes, it's definitely time, and has been for a while!

Tim Sweeney presented a paper recently on the topic of game engine design for multi core systems. Basically it amounts to changing from c/c++ to a functional language like Haskell for engine development so the language takes care of the task divisions needed. Code complexity is already a problem for engine development, managing threads is just gonna make that worse. When engine development time is as long as it currently is, taking a performance hit in code execution can be offset by a faster time to market.

I was never that impressed with the CMU approach. All that manual preplanning was an obvious dead end. And the giant mechanically stablized gimbal was just too clunky. It didn't help them in 2004, when they hit an obstacle placed by DARPA, and it didn't help them in 2005, when DARPA moved the racecourse from California to Nevada to prevent preplanning. The Air Force colonel in charge for 2005 said preplanning wouldn't work, and he meant it.

Computer vision of the natural world is finally about to take off, after three decades of frustration. It's probably possible to do much of the early vision processing in a current-generation GPU, which may make it affordable. Look for new apps that connect to cameras and pick out items of interest. Read that paper linked above.

As for the geographic location, I'm not sure it's as beautiful as you're making it out to be. Saarbruecken is possibly one of the ugliest cities in the former West Germany and much of the surrounding area is dotted with steel mills and coal mines (many closed now though). There is some nice forest land though.

I lived there for almost two years, doing my MS in graphics (although I was associated with the group at the MPI, not the one mentioned in the article). Interesting place to be for sure.

I was suprised to hear were I work they are dropping NFS in favor of SMB.
The reason I was given was that SMB has better permissions/access rights across all platforms.
-greg