There is the theory of general causality developed by Judea Pearl, which as far as I've understood implies that you need to be able to purposefully affect the world you're observing in some way to do experiments before you are able to infer causal relationships even in theory. See eg. http://www.michaelnielsen.org/ddi/if-correlation-doesnt-impl...
Chiming in for Rust. It's trying to be a C++ killer, so it has a shot at a very entrenched part of the current game development ecosystem. It's definitely not a safe and solid bet yet though, the whole language might still end up fizzling in the marketplace, and even if it thrives, it might not end up getting a foothold in professional gamedev.
If you want to learn a modern language with interesting ideas and a robust paradigm for developing efficient programs, and are happy to work in the single developer indie gamedev space for the time being, Rust is good and occasionally mindbending fun.
It depends a bit on what OP wants here though. You're not going to get a job writing a game in Rust for anyone else anytime soon. If you want to be an industry game programmer, you pretty much have to know C++. Knowing Rust will help in learning C++, but if you want to be sensible and efficient, you'll just go straight for C++.
If you want to go the indie route, nothing stops you from starting your own game project in Rust right now. But again if you want to be a sensible and efficient indie game developer, you'll pick up an established engine like Unity, and start making your focus-group tested game concept with market projections and publicity plan using all the ecosystem juice you can get. Rust has no established engines yet, Piston is work in progress and doesn't have any big games done with it, so your game development endeavor is going to be more about developing your own basic engine technology than being an efficient and competitive player in the indie game marketplace.
Solomonoff induction seems to be an useful innate bias for the current approaches at general intelligence. It's basically a formalization of Occam's razor that states that instead of being completely random, the surrounding environment is mostly lawful and simple, and therefore most of the processes in it can be described by algorithms with short rather than long source code.
Thanks, those look interesting. Will give them a read when I have time. My naive reaction though is: a lawful universe does not necessarily imply well-behaved fitness landscapes. Many lawful and even very simple processes give rise to chaotic and complex results.
I pay most of my daily shopping with a debit card and my Finnish bank will give me a plaintext dump of all the transactions that's a few regexp operations away from becoming a CSV file that can be imported to hlegder.
As far as I understand, the endgame of this stuff is a piece of software which would make a robot that was an exact physical equivalent of a fly without a brain behave exactly as a real fly does, assuming we had the computing power to run it in real time. Are these projects actually going for that, or do they have some more modest goal for what they expect to achieve, say, before 2020?
This. I'm on the lookout for expressive, statically typed, native code compiling languages for game development. Currently poking around with Rust, since Go seems to pretty much be settled on not doing the custom expressibility thing. Nimrod looks like something I'd really want to like, the game stuff I do doesn't really need Rust's hardcore garbage collection avoidance, but the ecosystem sparsity just scares me off. Meanwhile, Rust has both reasonably heavy institutional support and an impressive swarm of adventurous game developers with a C++ background working on stuff for it. I'm banking on Rust mostly for the potential ecosystem strength in being the only alternative to C++ for a high level of abstraction don't pay for what you don't use language.
I see the Babel doco has now been changed (10 hrs ago - any relation to this HN post?) to say I can run Babel against Nimrod 0.9.4 stable instead of needing to build Nimrod from source. This is great news, I was put off by the language's package manager not working against the stable release version. I look forward to giving this a try.
It's great news indeed. It seems I underestimated how many people will be having trouble building babel due to this. Next time I will do my best to make sure that it works with the latest Nimrod release.
I don't think that we can really consider Perl 6 and Parrot to be anything but abysmal failures at this point. The people developing and advocating for them have had many years now to product something that's even minimally usable, and we just haven't seen that happen.
Writing traditional compilers and interpreters, or emitting C, or targeting LLVM have all proven to be good ways of getting production-grade programming language implementations created and usable quickly. Messing around with Parrot has never resulted in anything useful.
pg said that for a language to become popular, it has to be the scripting language of something popular. That's the category where the three languages I mentioned are falling.
So the answer is simple: one has to build something really nice in Nimrod and use Nimrod as the extension language of that thing. Maybe the embedded world would be a nice field from Nimrod due to having nice interop with C? (I haven't used Nimrod in my life yet, although I am tempted because it looks very easy).
I feel like Lua is used pretty broadly for UI scripting in the games ecosystem (addons, plugins, etc) but I don't see it used really anywhere else aside from maybe IRC chatbots. Being the scripting language for something popular is maybe a necessary but probably not sufficient condition.