HN Theater @HNTheaterMonth

> Zig's use of comptime is fairly revolutionary in a c-like language

Not revolutionary. Before Zig came out, which was 2016, there was Jonathan Blow talking about and arguably repopularizing it. Lots of people (who knows how many developers) and languages were influenced by him too.

2014, Jonathan Blow, who made lots of videos and gave lots of talks, before going on to officially promote Jai (2016). And it appears he was playing around with prototypes much earlier and talking about it (from 2014).

https://youtu.be/UTqZNujQOlA (Demo: Base language, compile-time execution)

⬐ pverghese

Not very useful to us when Jai has not been released to the public. I would like it to, but currently Zig is more complete than Jai, atleast with respect to it being able to be used by everyone

⬐ Tozen

By the time Zig reaches 1.0, Jai may have too or have been publicly released. And Jai's constraints on getting access to their Beta, appears to have been loosening over time.

Jonathan Blow’s programming language allows almost anything to execute during compilation as well. It’s neat. Here’s an old video where he demonstrated this: https://youtu.be/UTqZNujQOlA

⬐ WalterBright

That's true. His implementation also allows compile time function execution to make system calls.

D disallows that in order to prevent malicious source code from being distributed and tricking people into compiling it. There is a mechanism to sent output to stdout, input can be read from a file residing on the compiler's system, and that's it.

It's also why CTFE doesn't allow pointer monkey business, like coercing an integer into a pointer and dereferencing it.

⬐ SubjectToChange

If you're compiling malicious code, haven't you already lost? I don't see how preventing pointer manipulation at compile time (or anything else, really) improves security unless people never run the executable they compiled.

⬐ lalaithion

It means that you need to do

    $ sandbox "foobarc malicious.foobar -o executable && ./executable"

instead of

    $ foobarc malicious.foobar -o executable
    $ sandbox ./executable

Which isn't totally intuitive.

⬐ WalterBright

Yes, I don't really want to have to recommend to people that they have to run the compiler in a sandbox.

⬐ SubjectToChange

And what if you are compiling more than a single file? What if the project or library you are compiling uses make/cmake/gn/etc?

The point is that restrictions on compile-time programming only protect you in trivial cases. And I can't think of many reasons to fully compile code without the intent of running the executable.

⬐ usefulcat

Testing. If you wanted to test that your compile-time code is correct, I'd imagine the typical--if not only--way to do that would be to compile it. Certainly that's true for constexpr in c++.

⬐ johannes1234321

you could compile it to verify, but you usally compile it using a build system to set include paths right etc. that build system could include a `rm -rf $HOME 2>/dev/null` or similar already.

⬐ SubjectToChange

Testing code requires executing it. This is true for compile-time code or run-time code.

⬐ WalterBright

Quite a lot of the tests in the D compiler suite are compile time only. It makes for running the test suite much faster.

To test ImportC, which inherits D's ability to execute functions at compile time, I've been using a lot of _Static_assert() constructs.

https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e...

⬐ WalterBright

If you want a compiler that is designed to enable ransomware injection into your system merely by compiling a file, that's fine with me. But it won't be D.

⬐ SubjectToChange

I don't expect D to change the way it does things. But I think your security concerns lack merit.

It doesn't make sense to produce an executable, not execute it, then go audit the code. Just audit the code in the first place. And like I mentioned earlier, virtually no project is purely static code. They include shell scripts, make files, and tons of other things. Working with untrusted code is dangerous, period. Making compile-time programming a little safer is just passing the buck.

⬐ WalterBright

> It doesn't make sense to produce an executable, not execute it, then go audit the code.

If you're auditing the code by examining it with an IDE, it could certainly get compiled.

⬐ SubjectToChange

Many IDEs automatically start the produced executable too.

Again, I don't understand why you'd want to wait until you have an unwanted/untrusted executable to begin auditing code.

⬐ junon

Do you audit every repository you clone and build?

⬐ WalterBright

People expect to check source code before running it. They do not expect to have to check it before compiling it.

Malware works by taking advantage of peoples' expectations.

⬐ SubjectToChange

People expect to check source code before running it. They do not expect to have to check it before compiling it.

Why are they compiling untrusted code? To see if it's syntactically correct? If the code you're compiling is using a build system, you're already compromised.

Compilation of untrusted code should always be sandboxed, regardless of compile-time programming capabilities.

⬐ gpderetta

Given the way modern IDEs work, unrestricted compile time evaluation would make it dangerous to even open potentially malicious code.

⬐ rurban

In Perl we only discourage IO at compile-time, because this only runs at the build system, not the client. And IO is mostly side effects only, and not restorable. Everything else is free. In perl this is simpler done, everything inside BEGIN{} blocks.

Sounds like what Jonathan Blow demoed in his new programming language JAI: https://youtu.be/UTqZNujQOlA?t=2024 Execute a invaders game with OpenGl while compiling and embedding the score in the code (Just a demo, the idea is to replace makefiles with compile time execution, etc.)

Jonathan Blow is working on at least part of this (sorry, the only links I could find were to his videos about it)

https://www.youtube.com/watch?v=UTqZNujQOlA

⬐ jzila

This talk is way too long and not very information dense. I jumped through it a little and liked what I saw, but I was wondering if anyone had a link to a white paper or an overview that could summarize the language features.

⬐ jblow

The talk is just over an hour. The second hour is Q&A.

⬐ readerrrr

Just some thoughts:

#run can run anything, if you don't trust the codebase you have to check everything for malicious calls. ( #run format c: as a joke :-/ when you compile )

check functions seem to have limited use. They can't check for input that isn't hardcoded( or can they? ). A runtime check might be more valuable.

I don't remember if it was mentioned; I think having C like implicit conversions is a bad idea. If types don't match exactly, cast or give an error.

defer is interesting, do you get an error if you try to return an object which is also defered getting deleted?

⬐ lobster_johnson

> #run can run anything, if you don't trust the codebase you have to check everything for malicious calls.

That weakness already exists today in any project that relies on a build system (GNU Make, Autoconf, Ant/Maven, whatever), which is pretty much most of them.

⬐ coffeeaddicted

About the trust thing - you probably don't often compile code without running it afterwards even now. A format call might be hidden in any library you use.

⬐ readerrrr

You are right. I usually wouldn't check the code if it is from a credible source anyway.

That was just the first reaction I got, wow this can run anything.

⬐ krig

Maybe the word check is a bit confusing, but the purpose of the feature is compile-time checking. Runtime checks would be implemented differently.

To clarify the probable mindset of the language designer: For games, runtime checks are pretty much useless - at runtime, the game is released and it's too late to do anything (ideally, discounting patches). So you want to catch everything you can at compile time. At the same time, performance is crucial. You need to be able to do everything the game needs to do within a 16ms time window. This means hardcoding / compiling in as many calculations as possible. Hence the focus on being able to do a lot at compile time.

⬐ fineIllregister

At 1:45:00:

> Do you really want a white paper?

⬐ Laremere

The story behind this is that Jon Blow is tired of making games in C and C++. He wants something better, but not necessarily something that is higher level. This demo goes over an initial prototype of the language. Shown are that he was able to relatively quickly get something up and working. The language operates well, but still has a lot of unknown things about it.

In the demo he shows the basic running of the language. Then he shows it's realistic to write games in the language by running a space invaders like game. He then also shows the power of using the language as the pre-processor (very lisp like) in that he is able to run arbitrary code during the compilation process, such as checking that your printf statements have the proper number of arguments, or having it so you need kill so many space invaders or your compile fails. He also showed that it runs on linux as well as windows.

⬐ CmonDev

Sounds like C++ with better syntax sugar. Is it really compiling already? That's impressive.

⬐ Gracana

Yep! It compiles to C, and then the Windows C compiler takes over.

⬐ CmonDev

OK, so not a real compilation. Still great though.

⬐ to3m

This is dealt with in the talk about 40 minutes in - it is described as a proper compiler, targeting either C or its own bytecode (which it uses for the compile-time execution).

⬐ supercoder

Why not use LLVM ?

⬐ pjmlp

Maybe because Windows reigns as development platform for game developers and LLVM still doesn't support it properly.

⬐ archagon

The language simultaneously compiles to bytecode and C. LLVM is potentially planned for the future.

⬐ mostly_harmless

personal plug: I've also been working on a programming language in my spare time, called "OWL"; My language is, coincidentally, also meant to be a cleaned up C++ for game development. It is an object-oriented systems language, without a garbage collector where it's most notable features are:

* classes are reference types to avoid slicing (but may still be stack allocated)

* classes are reference counted

* arrays are sized

* semicolons are optional

* tuples are first class types. (essentially acting as anonymous structs)

* basic one-way compatibility for importing C headers

The compiler can be found here: https://github.com/bsurmanski/wlc

currently it compiles for both Linux and Windows, requiring LLVM as a dependency.

a game written in OWL for Ludum Dare 30 can be found here: https://github.com/bsurmanski/ld30

⬐ nly

The way he feels about C++, highlighted in his first video[0], "this ship has taken us pretty far, but now it's done sailing", is pretty much the opposite of how I feel C++ is going to play out in the next few years. C++17 will no doubt be a make-or-break specification with regard to being surpassed by other languages, but with its critical mass of incumbency, and the rate at which tools and compilers are moving now (thanks Clang), I just don't see anything topping it in the near future. C++11/14 does feel like a different language to '03, and I've personally got no doubt that C++17 will feel better again. Promisingly, almost all of the work going in to the language atm is about making major strides in improving developer experience and reducing complexity.

The work Jonathon has put in to his language in such a short time is super-impressive, and the ideas and their implementation seems solid, but I think he's really underestimating the time frames required to get something like this up from the pioneering stage to production ... remember that C++ was compiling to C in 1983. There are other interesting languages taking this approach even today. Vala and Nimrod both spring to mind. At the end of this third video he talks about modern pioneering spririt versus those from the heyday of the space race... well here we are 50 years later, and it turns out that space travel is still hard. I don't think programming is any different.

[0] https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=UUCuoqzrsHl...

⬐ thinkpad20

Note that I haven't watched the whole video, just skipped through it. That said, not to be negative, but what does this language offer over Rust? If the goal is to create a new language with an emphasis on safety and fine-grained memory control, along with a nice module system and high-level constructs like easy first-class functions, it seems like Rust already covers that. What does the language offer that's new?

⬐ eco

I'm still watching it but I was thinking the same thing but about D.

- Module system

- Optionally avoiding complex build systems (rdmd or dub)

- Fast build times

- Type inference

- Nested block comments

- Owned memory (Unique, Scoped, RefCounted)

- All variables initialized by default

- Anonymous or strong enums

- Specify enum type (inferred by default)

- Order independent symbols

- Scope guard statements (more powerful in D though)

- Locally defined functions

- Built-in dynamic arrays

- Parameterized types (doesn't work in his language yet but he says it's coming)

- Compile time function evaluation (only side-effect free code though so no playable space invaders at compile time)

- Complex checks using compile time function evaluation

- Generate code at compile time and mix it into the program itself

I like where his language is headed but I'm not convinced we aren't already there. I guess I should go back and listen to his other talks to see why he's unsatisfied with Rust or D.

⬐ mbrubeck

This thread on the Rust subreddit compares Blow's language ideas to Rust:

http://www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_i...

He specifically says that Rust "cares too much about safety" and that satisfying its safety guarantees adds too much friction to development. Some of the Rust programmers in the thread acknowledge that the safety/friction trade-off for games may be different from, say, OS kernels or web browsers.

He also notes that Rust is new and still needs to prove itself, which I don't think anyone will disagree with.

⬐ wtetzner

> He also notes that Rust is new and still needs to prove itself

That's true, but I don't think making a new language avoids that problem.

⬐ MrDom

He beats that horse to death in the other two videos, which can be found at the link below.

https://www.youtube.com/user/jblow888/videos

⬐ thinkpad20

I appreciate the response, but it'd be nicer to get a quick summary than a link to a pair of nearly two-hour videos.

⬐ gnuvince

For Rust, the short of it is that Blow finds its ideas too new and untested to dive into it. There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes.

⬐ bjz_

> There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes.

But closures have different semantics to functions, both in representation and in execution. The semantics of his language becomes even more confusing when he says that items at the top level are position independent, where as it seems that those in a function scope are, and yet they share the same syntax. There is a simple fix though. Just keep a uniform syntax for position independent items, but allow them to be declared at any scope. That is exactly what Rust does.

⬐ gnuvince

Yeah, I don't disagree, I'm just relating what he said in videos 1 and/or 2 about Rust.

Personally, I'm all for having different syntax for different semantics.

⬐ hayksaakian

offhand, one problem the author mentioned with rust was writing unsafe code. he went into detail in either the first or second video (I don't remember).

⬐ chipsy

Blow wants to optimize for (developer) speed and simplicity over memory safety - roughly, "Go's simplicity, minus garbage collection" instead of what he calls "big idea" languages. Which I would never go for myself, but he's very adamant on this point; he dismisses most new ideas in PL theory entirely in favor of focusing on the engineering problem of smoothing out basic issues seen in his existing C++ development environment, where, to paraphrase him, "everything is junk and it demoralizes me". In that respect there's plenty we could learn from this project and its whole-process agenda, even if it isn't introducing sexy new methods. There are very few PL projects that aim only to work on boring everyday problems.

⬐ lobster_johnson

I don't think Blow is against big ideas as such -- his language has some big ideas on its own -- but he certainly seems to prefer familiarity and simplicity over mind-altering language-theoretical weirdness.

One aspect of familiarity, incidentally, is being able to hire junior devs. I see that as being a problem with Go -- and, in the future, Rust -- not to mention rocket-scientist languages like Haskell, Ocaml or even Scala, or indeed C++. Go is "simple", but not really that simple, not compared to Ruby or Python. (Of course, this might not be an issue for Blow, whose company is already using C++.)

While Blow was originally talking about safety not being a paramount issue, I believe he has mentioned ownership-lifecycle management, possibly something like Rust's borrowing, as being on his mind.

⬐ fuligo

The fact that he since the last video came out he not only built the lexer, parser and C-translator for this, but that he also made a complete bytecode runtime blew my mind. This guy is one hell of a productive programmer!

⬐ evincarofautumn

Once you’ve done it once or twice, throwing together a simple programming language is actually just a weekend project, provided you have clear goals.

⬐ deevus

The defer keyword seems pretty cool.

I assume it creates a stack of calls to execute just before exiting scope. Personally I find it a cool little syntactic sugar.

⬐ gnuvince

Go has the same functionality, you should check it out. It's great, but I feel it's a "halfway solution": you open your file and then immediately add a `defer f.Close()` statement afterward, so you don't forget to close it in all exit paths of the function (i.e. early returns in branches), however you still need to remember to type the defer.

⬐ bjz_

He does actually mention Go as the inspiration.

Anyway, I still much prefer RAII for this - not only for guarding against your own forgetfulness, but also to make sure a rogue refactor or patch doesn't break anything.

⬐ ufo

In functional languages you often see functions like with_file that use a closure to denote the file lifetime:

    with_file(fun file ->
        use_file(file)
    )

I wonder if there is a way to code something similar that works with "defer". This would free you from needing to "remember" to add the defer and would have the advantage of allowing you to use `return` and `break` statements which don't work if you wrap them inside an inner function.

The only thing I can think of is Python's with statement. Since its language syntax it allows for `return` and `break` but I wonder if there is a way to play nice with defer instead of requiring you to use another "block level" syntax construct for every file you use.

⬐ Too

Sounds like the finally-keyword in most languages?

⬐ bjz_

We used to do this in Rust, but have found RAII much better for this. Dealing with multiple resources open at once can quickly become painful. See http://blog.skylight.io/rust-means-never-having-to-close-a-s...

⬐ adamnemecek

I haven't watched the whole thing but does the language have a name?

lycos1: you are shadowbanned and have been for the last 3 or so years.

⬐ aurora72

Looks like a language with no name :)

⬐ _random_

Maybe it's like Fortran: Proglanforgam.

⬐ gnuvince

Sounds like a pill to prolong orgasms...

⬐ lycos1

It seems to be: Jai

⬐ Joof

Running code at compile time seems pretty powerful; mostly for tests.

⬐ lycos1

I really liked that feature. Also being able to write check functions for your function.

⬐ lostcolony

Powerful, yes, for tests, I'm not so sure.

If it stops the compilation when a test breaks, that forces you to fix it, but it also would irritate the crap out of me, since I'd want to test the code changes before refactoring the tests (I'm not a fan of TDD, at least when it comes to fixing bugs in code; let me fix the bug, then figure out what, if any, test broke (if none, add a test for that bug). I can't imagine it's particularly useful in game development either, when there can be a huge disconnect between something seeming correct at the program logic level, but massively broken visually; writing a test to make sure that that animation is smooth isn't easily doable).

If it doesn't stop the compilation on breaking the tests...it's not really any different than any other continuous integration style tool (or even a make script that adds a call to test after compiling), except that the tests are being run as the code is compiled, forcing you to wait the extra time even when experimenting. And it's unclear what code is intended for tests, versus other uses of the facility (such as DSLs and language extensions).

⬐ steveklabnik

The compiler currently bails upon encountering the first error, he said this was a feature, not a bug.

⬐ brandonbloom

I guess that he considers this a feature for two reasons:

1) He's used to the atrociously poor error recovery of typical C++ compilers. You almost always get different errors after you've fixed the first error.

2) His language's semantics enforce sequential compilation, such that it's not reasonably possible to continue evaluating in the face of many or most errors.

#1 is a consequence of not designing for error recovery from the beginning. He's going to run in to a problem when people want squiggly red underlines in their IDE.

As projects grow in size, #2 is going to breakdown quickly without a good separate compilation unit story.

⬐ jblow

Come on guys, think about it!

It is trivial to make your test routine log the error but return true so that the compiler doesn't stop.

⬐ brandonbloom

I'm totally fine with #2, if you do have a good separate compilation unit story. I'm fact, it's how many lisps work, and it works out quite well.

However, I wasn't talking just about your compile time asserts for #1. There's also syntax errors, undefined identifiers, missing or extra arguments, etc, etc. That stuff is hard to get right if you want to report many independent errors. It gets much easier if you can change your language, so don't wait too long to take a swing at it.

⬐ None

None

⬐ MariaRox9

I would also like to mention here some other platforms like Unity that makes games developing a whole lot easier.

⬐ None

None

⬐ _random_

I am unsure of his rhetoric: "...everything we can do to move forward in games... (1:41)".

He is not a messiah, it's already happening, people are using C#, Scala, Python, Haxe, Elm, Rust, D, Haskell to move game programming forward. E.g. Minecraft was built in Java, not C++. Game programming of today are those thousands of small indie developers experimenting, not the several hundred of bigger traditional C++ projects making big bucks.

Besides, there is not much focus on parallelism and concurrency for a performance-oriented language. By the time it hits it's first stable release the 8-core smartphones will probably be quite common.

⬐ jiggy2011

In an earlier video blow mentions that he wants to use this language to develop AAA level game engines and run on consoles. Even games which use a higher level language for some functionality usually have engines written in much lower level, non GC languages (usually C++).

Parallelism is a complicated topic and he will probably dedicate a video to that later.

⬐ None

None

⬐ fuligo

> He is not a messiah, it's already happening

That's a lot of negativity towards a guy who's said from the beginning he's just building a language that he wants to use himself. I don't think he's presented himself as "a messiah" in any way. He laid out some things that irk him in C/C++, and then he set out do make something that suits him better. These may not be the same things that are important to you (as demonstrated by your parallelism and concurrency criticism), but that's absolutely fine. People use different languages for different purposes and different tastes.

It worries me how makers are attacked here. "oh, we don't need that, X did the same thing ages ago" "why even bother if it doesn't do X" "oh dear, please not yet another X, people should just stop" "nobody needs X when we have Y1, Y2, Y3..."

That's some seriously bad attitude.

⬐ _random_

All I am saying is it's better to communicate along the lines of "let's also explore this way of building games" rather than "nobody is doing anything worth looking at, garbage collection is a no go, too much safety is bad and it's a first initiative ever just like the moon landing (which was kinda secondary to actually going to space first time anyway)".

But he is quite smart, so some arrogance could be forgiven. He is also not afraid to say some fair and true things out loud:

> "...the web is a giant pile, I don't want anything to do with it, it's all horrible; it's not an exaggeration, anything to do with web is like so broken and it's so nasty and it's so hard to do good things...".

Maybe it's a correct attitude if we ever want to get rid of legacy crud like JavaScript and HTML...

⬐ fuligo

> let's also explore this way of building games

That's what he said, isn't it? He also actively encouraged people to write their own languages which address what they care about.

> nobody is doing anything worth looking at, garbage collection is a no go, too much safety is bad and it's a first initiative ever just like the moon landing (which was kinda secondary to actually going to space first time anyway)

Those are his views, he needs those in order to make the new language. It's similar but not equal to your judgement of JavaScript and HTML. Those things are not bad per definition, they are just something you don't happen to like. The bigger theme here is that working with things that you don't like makes you unproductive.

So yeah, it does bother me a little when he says these things so emphatically, but they're still well distinguishable from global blanket judgements because they are expressed within the context of designing the new language.

⬐ akurilin

(disclaimer: skimmed through the video) Would be interesting to know what specifically about certain advanced PL typesystems he found to be too bureaucratic and where that line is drawn in his language.

⬐ MrDom

This is the third video in the series. Go to his youtube page to find the two videos previous to this where he talks about all that to death. Each video is between 1.5 and 2 hours. Also, keep in mind he's talking about a language specifically for game development. His requirements are highly specialized.

⬐ Paul_S

Way too long for a video (2 hours!), this should be an article. Disappointing, not really a new language - more like syntax sugar for C. It looks to me like he's not solving a problem here but just having a lot of fun creating his own language (which I agree is a lot of fun).

And just to make sure I deserve all the ire I might get: we already have a language for making games and I don't even need to write what it is because you already know :) (and that's why you know it's true)

⬐ efnx

I'm not sure that a "programming language for games" would be a subset of a general purpose language. I can't think of an operation that a general purpose lang can do that I would not want to use in a game. In that case, how could you specialize for games? A game is kind of an abstract concept - it could be anything. Maybe try constructing a language that lets you choose a subset of its total functionality for your specific game, possibly through extensions. Haskell does that well.

⬐ coffeeaddicted

A lot of modern game frameworks go in a similar direction. It's all about having entity-component systems where the designers (and not the programmers) can put together the objects dynamically. And those all fight with similar problems. One is about making the system cache efficient. Another is about how to add new components. I suppose the latter might be a reason he put so much power into the preprocessor that he even created a VM for that. Current complete solutions tend to have the problem that you have to repeat the class-names of your components often and that type-safety get's lost at some point when ini-files in any format are involved. Having more power in the preprocessor might help to fight this.

I don't know what he has planned for his language, but if I hear about a language that's specific for programming games, then entity-component systems would be the use-case I would have in mind.

⬐ efnx

I'd like to point out though, that I commend the effort of writing a Lang, I'm not try to discourage - just adding my thoughts! We need more language choices!

⬐ mostly_harmless

I think the idea is that the language is focused towards games. Games generally have some inherent shared qualities, mainly that they need to be real time and the language should be minimal overhead. On the otherhand, a language focused on enterprise software would sacrifice speed and low overhead to instead add some safety features like a garbage collector.

Its not a language only for games, but it is a general purpose language where the main feature set is chosen to benefit professional game development.

⬐ efnx

Yes I agree that the games he's designing the Lang for have certain shared qualities, but IMHO those concerns are best dealt with using libraries or (E)DSLs in a host language. That way you can still support games like zork, which don't have to be real time - as well as games that transcend what the "game specific Lang" was designed for. I personally don't see why there is a distinction between "a game" and "an enterprise app" - some enterprise apps need real time rendering and low overhead (unity, blender, arcgis, cad, etc). My point being - a language that is good at describing all games is good at describing all programs.

⬐ chr1

A language that tries to be good for describing all games, will end up not being good at describing any of them, because different types of programs require different tradeoffs

⬐ efnx

Exactly - and those trade offs will be handles at the library level.

⬐ yazaddaruvala

1. It will still be turing complete. In that sense its always going to be a general purpose language.

2. From what I've been taking away, all he is looking for is a way to remove some of the redundant parts of his day to day C++ code/process. Nothing more. Thats why, while I get that it is a full compiler, very intentionally (I think), a lot of the time it just seems like very nice syntax sugar (maybe "program sugar") for C++.

⬐ Betelgeuse90

A bit of context without even watching the video:

This dude nearly single-handedly made Braid, and is now working on a really cool 3D title that's well into its development.

⬐ fuligo

For anyone interested in a bit of background about him and some other indie gaming greats, I highly recommend checking out "Indie Game the Movie" - it's a documentary about the development process of Braid (Jonathan Blow), Fez (Phil Fish), and Super Meat Boy (Edmund McMillen and Tommy Refenes).

At about 10 USD it's a bit steeply priced, but I found it well worthwhile: http://buy.indiegamethemovie.com/

⬐ Betelgeuse90

I'll also join in recommending this.

⬐ None

None

⬐ eco

It's fair to say Braid is his game but it wasn't done single-handedly. David Hellman did the great artwork and Blow licensed the music. Edmund McMillen (Super Meat Boy, The Binding of Isaac) did some of the original character designs which David Hellman remade to fit the the art style that developed.

⬐ infiniteri

Fair. He did all of the programming involved, as well as all of the story and gameplay design.