
The Witness: the creator of Braid talks about his fiendishly difficult new game - binarycrusader
http://www.polygon.com/features/2015/9/17/9343943/the-witness-hands-on-preview-feature-braid-jonathan-blow-interview-ps4-playstation-4-pc
======
erikpukinskis
I _strongly_ encourage anyone interested in programming languages to watch his
series about Jai, the language he is creating for his next game. Starts here:

[https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxai...](https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO)

It's not released yet, but watching the videos has massively changed the way I
think about programming. The notion of "data-driven programming," which I
would describe as "only move around the data you have to", has been a real
revelation to me. I sort of came out of the Ruby world (and Java before that)
where the attitude is more "Abstract all the things!"

I have been trying to apply many of Blow's principles in my JavaScript
programming and it has been awesome. I find myself staying closer to the
"metal" (which in JavaScript world is pure Node and low-level browser APIs)
and it has been incredibly rewarding.

I've also really enjoyed his policy of pragmatism over idealism. I think the
React world for example has taken a good idea (immutability can clarify data
flows) and turned it into a religion (Everything Must Be Immutable!) Watching
Blow work has given me the confidence to steer away from that.

Much in the same way that learning Rails made me a better programmer (even
though I don't use it anymore, and I've rejected a lot of its premises) I have
found learning Jai has really leveled me up as a programmer and a computer
science thinker.

~~~
hacker_9
See here for a write up up Jai's language features:
[https://sites.google.com/site/jailanguageprimer/](https://sites.google.com/site/jailanguageprimer/)

 _John_ is clearly coming in from a C++ mindset and is essentially fixing
problems with the language that should have been really been fixed long ago. I
think it looks interesting, but I'm not sure it really solves any big
problems? Just seems to be a bit better syntax.

~~~
greggman
It's not just a better syntax for C++. If nothing else being able to use the
entire language at compile time is a huge step in the right direction IMO.

C++ meta programming IMO was never meant for meta programming. It was intended
do to a few simple template things, then someone discovered if you made an
array of size [-1] you could basically turn it into a turing complete
language. But, the contortions you have to go through are ridiculous. It's
like writing photoshop in bash script. I'm surprised someone hasn't written an
LLVM pick your language to C++ meta programming compiler just to not have to
deal with that crap.

Sure that feature has been around in other languages for decades (lisp) but
it's sorely missing from C++. People usually work around it by writing code
generators, almost always in other languages.

There were other interesting ideas like using the closure specifiers to
enforce function purity including all functions they call. I haven't followed
whether that has worked out or not.

On top of that syntax matters. As JBlow pointed out, every time he has to
waste time refactoring 50 lines of code for something that should be a 1
character change or spelling things out the compiler should be able to figure
out is a huge drag on productivity and motivation.

That was my #1 take away from the videos I watched. How about designing a
language for programmer joy. Most languages pick something else (multi-
processing, memory safety, ...) but whether or not it will actually be
pleasant and fun to program in is rarely considered.

Sure some people get off on solving the puzzles of contorting their language
of choice to do something difficult. Especially C++ meta programming gurus.
Others of us just want to get shit done. It's not writing the code that's fun
for us. It's the result. The faster we can get there the more we can work on
polishing and iterating.

~~~
hyperion2010
I watched all his videos and my main take away was that there is actually no
high level language besides C (and restricted subsets of C++ that don't use
templates) that can be used to tell the computer what to do. Almost every high
level language we have already abstracts away the idea that you are trying to
control a piece of hardware. Game programmers are in an ideal position to have
learned what is actually needed to make talking to a computer more efficient.
The fact that J also has the vision to build the language to account for real
world development processes is almost like an added bonus.

~~~
bsder
Presumably Rust wasn't stable enough for him to consider because that's the
single language that seems to address his complaints.

Once you bar garbage collection, you're pretty much left with C, C++, and Rust
(FORTRAN weenies can leave the room, thanks).

~~~
GolDDranks
Also, he doesn't like Rust's stance on safety -- he thinks it's going to lead
to too much hand-holding and boilerplate annotations.

~~~
pcwalton
Yes, that's the main design difference between Jai and Rust.

My _personal_ feeling is that memory safety isn't something I want to
compromise on. But, I work on browsers and not games, so I'm perfectly willing
to acknowledge that, for games, developers may be willing to sacrifice safety
for fewer type system restrictions. Browsers, critical OS components,
databases, etc. are security critical, while games aren't. I'm a pluralist
when it comes to programming languages, and I'm perfectly willing to accept
that there are _prima facie_ valid reasons for not wanting memory safety. One
thing I like about Jai is that it's very up-front about not being type-safe or
memory-safe, and specifically argues against the usefulness of memory safety
for its domain.

It's interesting, though, that whenever I've floated the possibility of
relaxing restrictions on an opt-in basis for apps that don't care about memory
safety as much the reaction of the Rust community has been lukewarm at best
and usually pretty negative, even from the game devs. It's interesting: most
people don't want to give up their memory safety, once they see the benefits
that it brings in terms of developer productivity (preventing annoying bugs).
That's the camp I'm in too, at least for the apps I write.

~~~
renox
In one of his latest video he show how it is going to work for array access:
by default it's checked, but you have a directive to make one (or a block) of
array access unchecked and then you have a global directive which can change
the default to check all the array access or NOT check all the array access.
So you get the full range from safe array access to C-like performance and
with the possibility of dropping the checks only where this impact really
performance.

Memory safety isn't limited to array access, but I really like the idea of
this kind of control (even though for library this could create issue, I think
that there are plans to allow the use of an 'ANDF' like format for libraries).

~~~
pcwalton
Bounds checking isn't as interesting as use-after-free protection (like the
borrow check) for a couple of reasons: (1) you can easily opt-in and opt-out
on a case-by-case basis (even in Rust), whereas UAF protection is nonlocal;
(2) bounds checks rarely if ever show up in profiles with a well-designed
iterator library and an optimizing compiler.

~~~
renox
I mostly agree with you (UAF is more interesting but more difficult that bound
checking), but I would nitpick on details:

\- yes you can opt-in and opt-out on a case-by-case basis in Rust for bound
checking but can you globally remove checks and globally force checks?

\- as for UAF protection being non local, a true UAF protection true but a 99%
solution such as overwriting the data with know garbage on free (0xDEADBEEF)
and ensuring that the allocator doesn't reuse virtual addresses may be good
enough in practice, no? But yes it's probably too expensive to release with
such configuration..

~~~
pcwalton
> \- yes you can opt-in and opt-out on a case-by-case basis in Rust for bound
> checking but can you globally remove checks and globally force checks?

No. Nobody has asked for it, because nearly all bounds checks in Rust just
don't matter from a performance point of view, and thus there is no reason to
remove them.

> \- as for UAF protection being non local, a true UAF protection true but a
> 99% solution such as overwriting the data with know garbage on free
> (0xDEADBEEF) and ensuring that the allocator doesn't reuse virtual addresses
> may be good enough in practice, no?

You can't avoid reuse of virtual addresses. That would have terrible cache
implications.

The only thing that sorta works is something like WebKit's PartitionAlloc, but
that only mitigates some exploitation scenarios. There is no easy solution to
UAF.

~~~
renox
> You can't avoid reuse of virtual addresses. That would have terrible cache
> implications.

\--> terrible TLB implications

> There is no easy solution to UAF.

Agreed.

------
teddyh
Buried lede: “ _While it 's been a long and winding road,_ The Witness _is
nearing its end. Blow has a little over four months until the just-announced
release date of January 26, 2016._ ”

~~~
devindotcom
It's not really the lede, though.

------
maxander
My goodness, but that's pretty for a small-studio game.

Its worth noting that, assuming this actually comes through, Blow will have
overcome one of the most pernicious traps that wait for successful game
designers- that next, wondrous game you make once you have all the resources
you could possibly dream of and no excuse not to follow every possible design
ambition. Compare Duke Nukem 3D, or 0x10c.

~~~
xerophyte12932
Yes its refreshing to see them take a complete departure from Braid instead of
just seeing Braid as "formula for success" and re-iterating it. (I am looking
at you Angry Birds).

I like how he used his financial freedom to follow through with something he
really wanted to build in a way that he feels justifies his dream

------
teddyh
The web site of the game itself ([http://the-witness.net/](http://the-
witness.net/)) seems down at the moment, but their Twitter account has links
to more articles:

[https://twitter.com/witnessgame](https://twitter.com/witnessgame)

~~~
PopeOfNope
Wordpress. Nuff said.

~~~
PopeOfNope
To all you twits downvoting me, proof:

@Jonathan_Blow: "Sadly I did not manage to get us off WP in time, and surprise
surprise, our blog gets crushed immediately every time I reboot the machine."

[https://twitter.com/Jonathan_Blow/status/644564200275054592](https://twitter.com/Jonathan_Blow/status/644564200275054592)

~~~
steveklabnik
You're not being downvoted because you mis-characterized the software stack.

~~~
PopeOfNope
Care to enlighten me, then? It's as on topic and relevant to the posted story
as the rest of the comments here. The best I can figure is people just don't
like my tone, which is childish.

~~~
steveklabnik

      > which is childish.
    

uh huh

~~~
loco5niner
[https://xkcd.com/1124/](https://xkcd.com/1124/)

------
tempodox
I wish the temporal delta between buzz generation and game release were
smaller. By the time the game will be released, I will have forgotten all
about it.

~~~
rtpg
I've been looking forward to this for an extremely long time. But it looks so
promising that I go to the game blog once a month or so to see what's
happening

------
stringham
I have been following the progress of this game on the-witness.net for a few
years. Really exciting that they've got a release date now.

