ivanmilles

Netflix’s Sacred Games. It was their first domestic production and is a straight faced noir cop drama. It’s my favorite crime series of all time - I think it blends The crime boss mythology of The Usual Suspects with the multi-decade story telling of The Godfather. It is told in a way that it feels like a picture coming into focus, rather than a linear narrative.

A recommendation to the Dutch "precursor" to Paradise Lost: Vondel's "Lucifer" is a tight five-act play along the same lines. It's about a century older than Paradise Lost, with a contemporary energy that's quite fun and punchy, and a quick read.

Noel Clark's translation gives it a modern air of office politics as Lucifer and Beelzebub quarrel with Gabriel on how to behave in their shared workplace.

Your [1] could be Walther J. Ong's Orality and Literacy? It goes into differences between cultures rooted in written/oral language, and has several examples where words that are "missing" from or present in a language reflect the way the speakers think and reason.

Sliding offtopic, but do you have any more memories around this specific collaboration? I'm deeply familiar with the theory, but anecdotes on such an ambitious project would be useful to a text I'm working on. Thanks.

Thanks for digging out the links on Doreen, pocketed both.

But am I reading GP wrong that it wasn't constructionist education proper that failed, but a "let's do things with laptops" being retconned onto constructivism?

Excellent. Appreciate the answers.

>every kid could be an autodidact just like them once they had the magic laptop

So, if I understand you correctly, OLPC went in with a constructionist perspective and it didn't work out? This is hyper-relevant to what I'm working on, so: did a proper theoretical constructionist framework fail you, or was underestimating the role of teachers the main problem?

Did engaging Nepali teachers give any insights in the above?

Can you say more about the autodidacts and the conflict with professional staff? I'm interested in specific areas that were problematic, and if you have any learnings from mitigating it.

Playdead spat out a series of incredible GDC talks after their game INSIDE. They did a full presentation on the ending of the game [0] as a collab between engineering, rendering and art.

It’s fascinating just to see the creativity, but also a teaching moment on striking the balance between tight, accurate engineering and enough hack&mirrors to pass inspection.

[0] https://youtu.be/gFkYjAKuUCE

No-one claims that gamedevs see lock-in as something positive; only that very few AAA gamedev shops care about lock-in - especially for a relatively small part of the production pipeline as a graphics API.

What you see as locked-in API, others see as a great feature set to build on, probably with access to driver developers to help reach even further, past publicly available APIs.

A game engine is not something you can switch out of easily anyway. Everything from game code, to years of asset libraries to decades of source control repositories - all of those are very rigid parts of the production pipeline.

Chernobyl is still open for tours, afaik. You won't get very close to any of the running reactors (and not the closed one, of course) but the tours generally go through the complex' main road and through the Pripyat ghost town.

On the contrary. If you look at the projected search area, it's a huge swath of deep ocean. A plane is very small. Once it breaks up against the waves it's really, really small. The debris sinks into silt at the bottom of a deep ocean. Currents spread them out. Even if we knew where it went down, finding it is a difficult problem.

On top of that, we don't have radar tracking over the oceans. Transcievers don't communicate all the time while in flight. There are long periods of time where you are outside any national radar system. Compounded, it's entirely reasonable to lose a plane.

There are 15-20 planes that have never been found since the 1980s.

This echoes the tribulations of the original Starcraft devs. [1]

> ...based on my experiences the biggest problems in StarCraft related to the use of doubly-linked linked lists. Linked lists were used extensively in the engine to track units with shared behavior. [...] Some of the link fields were shared among several lists, so it was necessary to know exactly which list an object was linked into in order to safely unlink. And some link fields were even stored in C unions with other data types to keep memory utilization to a minimum. So the game would blow up all the time. All the time.

Serialising game state to disk was done by moving all those scattered objects into a contiguous memory block, re-link, save to disk, and then restore the game engine's internal state.

> It was necessary to fixup all the link pointers (taking special care of unioned pointer fields) so that all 1600 units could be written at once. And then unfixup the link pointers to keep playing. Yuck.

[1] http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s...

No, you're right. The use case for Grunt/Gulp is in the name: task runners, to automate the running of tasks, to stabilise and formalise the build process to the point of repeatability across a team.

It's a bit strange to have him bash on the Grunt/Gulp ecosystem's plugin dependence and SemVer configs, and then go on to recommend using npm instead, which is also dependent on node and its ecosystem.

That said, the npm solution looks attractive for simpler build flows, but hook in a fat custom plugin to a watch task on a subset of files and I'm sure you'll get the same complexity in package.json.

Agricultural produce is a strongly limiting factor on how good human life can be - the most important process we run. To give kids a rudimentary insight into the mechanics and economy of it is - to me - clearly a more important lesson than understanding an oil rig.

>That's basically the 'hello world' of farming This is an extremely fascinating perspective. I need to go... build something. Wow.

...if they work more /as evaluated by men/.

>how do we know it's not justified? Presumably the pay reflects the work done. Again, do you think studies haven't been done? That's the core of the discussion: pay does not reflect the work done, and it is sometimes even inverted.

An excellent example of structural discrimination - one group both organizes and controls the perception of value in a field. It becomes hard to unless you support the structure - hence women who are forced to act on male terms. "Karen's alright, she's like one of the guys."

Such a structure becomes "sex inclusive" (accepting biological men and women who act masculinely) and not "gender inclusive" (accepting biological men and women who act masculinely or femininely).

I get advertisements for the S3 inbetween pages. Nice touch.

There's also the very basic disappointment that a piece of good software won't grow to maturity. I finally found a mail client that restored my faith in SMTP as a communications medium; a mail client that had me managing email exclusively on my iPhone. A mail client that broke away from email as a metaphor for paper envelopes with written messages on pulp.

I liked handling email in Sparrow. It felt modern, and now it won't get any better.

It's very hard to prove that high-entropy random data isn't encrypted.

So, now Random actually /is/ Resistance? http://www.youtube.com/watch?v=aE6RtzwVdHI

I'll print this and hang it on the wall above my machine. Brilliant.