carloscm

If this indeed evolved into a stand alone, curated app store like Steam pre 2016 with a 88/12 revenue split it could indeed shake up Android game distribution. Mobile in general and Android in particular is such a brutal market for small indie developers. Epic could pull a Valve here.

From the article:

"The chips that produce an electric field for the Solar Probe Cup are made from tungsten, a metal with the highest known melting point of 6,192 F (3,422 C). Normally lasers are used to etch the gridlines in these chips—however due to the high melting point acid had to be used instead."

I had no idea tungsten was used to make ICs. What kind of density is achieved by laser etching (on tungsten or otherwise)?

I originally did. This was fine when the scripting was just doing data setup in advance, and it wasn't being run per-frame as game logic. When I started The Spatials V3 (aka Galactology) I also started doing real time game logic in s7. After enough code it became clear that the fastest purely interpreted scheme wasn't fast enough to be put into a soft real time path (the game grew up to hundreds of systems, in the ECS sense).

So I made a 6 months long gameplay development freeze last year and I converted all the s7-flavored Scheme code into the l2l Lisp dialect with a custom transpiler (which had to be aware of all the s7-ism plus my own s7 reader macros), and replaced the C++ binding layer with sol2. This resulted in a ten-fold increase in performance when the game is limited by logic perf (it's not visible with an empty new game). LuaJIT is alien technology for all I know.

I have to do a proper write up some day.

I'm beating my own drum here, but the gameplay code for my game Galactology is 90%+ done in a Lisp dialect (l2l with LuaJIT underneath), clocking at 51K lines currently. It has been a huge productivity boost since I switched from C++ two years ago, but I do miss some level of typing and static checking. http://thespatials.com/

I think the article is wrong to call the showcased devices "netbooks". Netbooks were a laptop-lite, with a slightly smaller size. The Dragonbox Pyra is more like a micro laptop, the size of two big smartphones stacked on top of each other. It's a different size category and that's what makes it interesting.

I've looked into both l2l and moonlisp and they were too incomplete to be usable in their current state, and not being worked upon recently (or not much). The most current and interesting effort in this area in my opinion is Conspire[1], which is actually based on Terra[2], another amazing piece of software.

The decision to not go with LuaJIT was complicated and depending how it goes with S7 I probably won't take it again for a new game. For starters I doubt I will delegate any per-frame non-evented computation to the S7 side, while I could easily do it in LuaJIT. But I'm already seeing an at least 10:1 ratio of lines of code for things like building GUIs, and it's only going down even further now that I'm implementing event callbacks with lambdas and adding reactive-like system for rendering updates.

Good work on hua! I read somewhere that once you learn a Lisp you are destined to write one. I've been tempted too :)

[1]: http://blog.duangle.com/2015/01/conspire-programming-environ... [2]: http://terralang.org/

LuaJIT is, by far, the best option for scripting in games/RT, thanks to the incredible JIT performance and its incremental GC with deadlines.

But there's something when you start playing with Lisp and then you want to keep using it more and more. Suddenly the classic Ruby/JS/Python/Lua language design feels boring and stale (ironically, given the age of Lisp).

After getting my feet wet in v2, I'm doubling down on Scheme for The Spatials v3, this time using S7 Scheme, a true gem of an interpreter (first class environments, hook on symbol-access for reactive programming, super extensive C FFI support, etc.)

That 1mm single fiber endoscope is just amazing, out of a spy/scifi novel.

This is notable not just because of Neal Stephenson, but because his blog post contains what I think is the most detailed public description of the tech so far:

--- Here’s where you’re probably expecting the sales pitch about how mind-blowingly awesome the demo was. But it’s a little more interesting than that. Yes, I saw something on that optical table I had never seen before--something that only Magic Leap, as far as I know, is capable of doing. And it was pretty cool. But what fascinated me wasn’t what Magic Leap had done but rather what it was about to start doing.

Magic Leap is mustering an arsenal of techniques--some tried and true, others unbelievably advanced--to produce a synthesized light field that falls upon the retina in the same way as light reflected from real objects in your environment. Depth perception, in this system, isn’t just a trick played on the brain by showing it two slightly different images.

Most of the work to be done is in applied physics, with a sizable dollop of biology--for there’s no way to make this happen without an intimate understanding of how the eye sees, and the brain assembles a three-dimensional model of reality. I’m fascinated by the science, but not qualified to work on it. Where I hope I can be of use is in thinking about what to do with this tech once it is available to the general public. "Chief Futurist" runs the risk of being a disembodied brain on a stick. I took the job on the understanding that I would have the opportunity to get a few things done. ---

~150USD / month from http://thespatials.com/ with a jump to 1000 USD in October after we announced our successful Greenlight. Launching in Steam in early 2015 and expect to shake things up.

This reminded me of ATS - http://www.ats-lang.org/ Check also Chris Double blog - http://bluishcoder.co.nz/tags/ats/

ATS combines ML-style types, linear types, dependent types and theorem-proving. Plus it compiles down to C, has pointers including (safe!) pointer arithmetic, has trivial C interop, and doesn't have GC (alloc/free safety is provided by the linear types, like with Rust lifetimes). It's a really interesting beast and I hope I have more time in the future to dive into it. Idris wins in the syntax department tho.

Please don't name it just "Meta", it will make it a lot more difficult to find resources for it in the web. Imagine googling for "meta", "meta lang", "meta language", "metalang". Maybe something to go with "meta", like MetaCaml.

It's true, it's more customizable and flexible than I realized when I first looked into it. I stand corrected.

It was the glgui library that gave me that impression. It's true that there appears to be no built-in high level concept of a view as a container/ layout holder/ etc, we are talking about different things. I should rephrase that as "kind of GUI as long as you don't want to dive into raw OpenGL". It was more like, if I want to change how a button is drawn, do I have change the internals of the framework or is that a user-level supported API?

Keep in mind LambdaNative appears to be very opinionated about things like project structure (your code goes in this folder and is named like this), files (your images must be in this format and must be copied to this folder) or UI (your code must implement this kind of view, always, in this way). At first it looked really nice to see somebody already did all the grunt work to prepare Gambit-C for all those platforms (specially mobile), but the constraints were too much for me. Impressive project but not for every app.

Is this also true when using JavaScriptCore directly? Or do you only get JIT compilation in the context of a web view?

Partially, mostly in the library area. It still has some troubles with actual C99 code:

http://bellecrazysnail.wordpress.com/2013/11/14/some-thought...

There's also some weird double personality issues going on with their compilers in MSVC2013, for example they support designated initializers in plain C but not in C++. So you get partial C99 inside pure C or C89 (MS flavored) under C++.

I forgot where I read the quote, but for a decade Microsoft saw the plain C compiler as tool exclusively meant for Windows development. While gcc and later clang adopted and embraced new C idioms, like the struct syntax I mention, they kept their plain C support frozen in time.

I also found weird behavior in MSVC when pushing the C preprocessor VERY hard (nested variadic macros. That would require an entire blog post for itself...)