
Carmack talks practical use of Haskell, Lisp in game prog at Quakecon keynote - macmac
https://www.youtube.com/watch?feature=player_detailpage&v=1PhArSujR_A&t=130
======
mkilling
It struck me how well Carmack's ideas about running all actors in the game
world in parallel map to Clojure's agents[1].

Clojure introduces a bunch of interesting ideas on how to handle parallel
programming. "Perception and Action" by Stuart Halloway is a great talk to
listen to if you're interested[2].

[1] [http://clojure.org/agents](http://clojure.org/agents) [2]
[http://www.infoq.com/presentations/An-Introduction-to-
Clojur...](http://www.infoq.com/presentations/An-Introduction-to-Clojure-Time-
Model)

~~~
macmac
In fact one of Rich Hickey's very first demos of Clojure was ants.clj which
uses agents to simulate the ants. While not a game but rather a simulation it
includes many elements that would also be present in a game. A literate
version of ants.clj may be found here: [https://github.com/limist/literate-
clojure-ants/blob/master/...](https://github.com/limist/literate-clojure-
ants/blob/master/literate-ants.org)

------
msie
It's inspiring to hear how he struggles learning a new language and having
trouble doing things not related to his work.

~~~
oacgnol
He's one of my favorite people to follow on Twitter [1] because of this; he
regularly tweets about stuff he's learning, especially new languages. It's
quite inspiring and uplifting to see a such a figure in the industry still
make time to learn on his own and candidly share his thoughts.

[1]: [https://twitter.com/ID_AA_Carmack](https://twitter.com/ID_AA_Carmack)

------
BgSpnnrs
I strongly recommend listening to his Quakecon keynote in full. It meanders
over a huge variety of topics and I personally find him a very engaging and
easy to listen to orator.

~~~
Sprint
Absolutely! I uploaded it as single segment at
[https://www.youtube.com/watch?v=o2bH7da_9Os](https://www.youtube.com/watch?v=o2bH7da_9Os)
, will archive it to archive.org shortly.

~~~
sherbondy
Is there any chance you could extract the audio and put it online somewhere? I
am currently finishing a cross-country bike trip, and would absolutely love to
listen to his keynote, but only have a phone on me currently. It would mean a
ton!

~~~
Sprint
Sure thing!
[http://archive.org/details/Quakecon_2013_-_Welcome_and_Annua...](http://archive.org/details/Quakecon_2013_-_Welcome_and_Annual_Keynote_-
_John_Carmack/) includes the AAC track extracted from the video as well as a
mono 32kbit/s VBR Opus in Ogg to save you bandwidth. Enjoy!

~~~
Sprint
Sorry, that ogg was borked. At least I cannot play it anywhere. Will replace
it with a standard Ogg Vorbis one.

------
_random_
Glad to see him think that strong static typing is the way to go.

~~~
gnuvince
There's only so many times you can get an error in your programs before you
begin thinking that static typing might offer non-trivial benefits.

~~~
derefr
I have a feeling that all the people still arguing in favor of dynamic typing
at all, are tilting at the windmill of static languages without type
inference. Nobody really thinks those are good languages any more :)

~~~
brandonbloom
> all the people still arguing in favor of dynamic typing at all, are tilting
> at the windmill of static languages without type inference

Some of us who argue in favor of dynamic typing have a much more nuanced and
informed view...

I, for one, am of the mind that the there are precisely _zero_ production-
caliber statically typed environments that possess a sufficiently powerful
type system for the kinds of problems I tackle on a regular basis. Haskell
doesn't count, since you need to turn on about a dozen GHC language extensions
in order to incorporate the last 20 years of research. There's also quite a
bit of design warts that newer academic languages are starting to iron out. In
particular, I don't think monad transformer stacks are a reasonable solution
to computational effects.

That's not to say you can't write _any_ program in an environment where the
type system is constraining you. You can. You simply implement a "tagged
interpreter", which is something that's so simple to do, people do it all the
time without realizing. Either you have a run-time map or you pattern match on
an sum type data constructor, then loop over some sequence of those things
with a state value threaded through. Poof! You've got a little interpreter.

I find that this happens _a lot_. And, I also find that a lot of problems are
easier to reason about if you create a lazy sequence of operations and then
thread a state through a reduction over that sequence. Now, in Haskell, I've
got a type correct interpreter for an untyped (unlikely turing-complete)
language! Sadly, I can't re-use any of the reflective facilities of the host
language because my host language tries to eliminate those reflective
facilities at compile time :-(

I'm in favor of optional, pluggable, and modular type systems. I think that a
modern dynamic language should come with an out-of-the-box default type system
that supports full inference. If, for some reason, I build a mini interpreter-
like thing. I should be able to reuse components to construct a new type
system that lets me prove static properties about that little dynamic system.
This level of proof should enable optimizations of both my general purpose
host language and my special purpose embedded "language".

Additionally, I require that type checking support _external_ type
annotations, such that I can separate my types from my source code. In this
way, type checking becomes like super cheap & highly effective unit tests: The
`test` subcommand on your build tool becomes an alias for both `type-check`
and `test-units`. You just stick a "types/" directory right next to your
"tests/" directory in your project root. Just as a stale unit test won't
prevent my program from executing, neither will an over-constrained type
signature.

~~~
mietek
_> Haskell doesn't count, since you need to turn on about a dozen GHC language
extensions in order to incorporate the last 20 years of research._

I don't follow. Turning on a language extension is as simple as adding a
single annotation to your source file. Is this a problem?

Are you objecting to "the last 20 years of research" not being part of the
definition of the Haskell language standard? This is a little off the mark, as
Haskell was conceived in 1990, and the latest version of the standard is from
2010.

Moreover, Haskell is evolving rapidly precisely due to the use of language
extensions. Research is done, papers are written, and extensions are added —
then validated through practical use, and either kept or removed.

 _> There's also quite a bit of design warts that newer academic languages are
starting to iron out. In particular, I don't think monad transformer stacks
are a reasonable solution to computational effects._

Granted, monad transformer stacks can get unwieldy. Fortunately, writing in
this style is not required. Monad transformers are just library code, so it's
not necessary to invent a new language to replace them.

~~~
brandonbloom
> Haskell was conceived in 1990, and the latest version of the standard is
> from 2010

Haskell was released in 1990, but the designs started on Haskell itself in
1987 and were heavily based on prior languages; standardizing on a common,
agreeable subset. The fact that there is a 2010 version of the spec provides
zero insight into how much the language has evolved over that 23 year period.
That's not to say it hasn't evolved, just that it's silly to pick on my
obviously hyperbolic trivialization of 20 years of progress.

> Haskell is evolving rapidly precisely due to the use of language extensions

Sure. And the fact that it is _still_ rapidly evolving, especially in the type
system department, is proof that there are interesting classes of problems
that don't fit in to Haskell's type system in a sufficiently pleasing way.

Evolution is a good thing & I have a ton of respect for both Haskell & the PL
research community. See the rest of my post for how I'd prefer an advanced
language/type-system duo to work in practice.

------
macmac
At 1:44:00
[https://www.youtube.com/watch?feature=player_detailpage&v=o2...](https://www.youtube.com/watch?feature=player_detailpage&v=o2bH7da_9Os&t=6258)
it sounds like he is actively looking for an opportunity to use Scheme as an
embedded language in a game. Does HN know of any examples of such use?

~~~
JabavuAdams
Naughty Dog is the canonical example. They were founded by two ex-MIT AI Lab
guys. They designed a couple of in-house languages for Crash Bandicoot, and
Jak & Daxter.

In the early days of the PS2, they supposedly derived a benefit from having a
higher-level language that could be compiled for any of the PS2's various
processors (EE, VU0, VU1). I think that at the time, you couldn't do VU
programming in C.

In the end, they had to revert to industry standard C/C++ due to hiring
issues.

~~~
georgemcbay
While their games used to be even more Scheme-based than they are now, AFAIK
they do still use PLT Scheme (at least as far up as the Uncharted games,
haven't read too much on the tech under The Last of Us) for the sort of
traditional scripting one would use UnrealScript or QuakeC for.

~~~
noelwelsh
PLT Scheme, or Racket as it is now known, is in use in the Last of Us:
[http://lists.racket-
lang.org/users/archive/2013-June/058325....](http://lists.racket-
lang.org/users/archive/2013-June/058325.html)

A bit of insight into the use of Racket here (scroll down):
[http://comments.gmane.org/gmane.comp.lang.racket.devel/6915](http://comments.gmane.org/gmane.comp.lang.racket.devel/6915)

------
Vekz
It blows my mind that this is his first foray into functional languages. Makes
my imagination wonder what the current state of the gaming and programming
industries would be like, had he built Wolf 3D in a functional language and
inspired everyone else from there.

~~~
Tloewald
Did you listen to the end? He wonders aloud what might have been if QuakeC had
been QuakeScheme.

It's not his first foray into functional languages though. It's his first
attempt to write production scale code in a pure functional language.

------
_ZeD_
while listening to the structuring of the haskell version, with a "world" and
an "actor" for each element, and the interaction as message-passing, I would
think Carmack would find using erlang very satisfing as another alternative :D

------
nabilhassein
Is there a transcript?

~~~
macmac
Not that I know of besides the one auto generated by YouTube.

