briantrice
My personal case is a Zero motorcycle, but I've heard confirmation from owners of other kinds; the range it gets is more or less exactly what they state for the test conditions (straight level ground, no winds, etc etc). Mine did in fact improve when I adjusted the aerodynamics, but that's another topic.
I did buy a pre-made Atreus kit and have been playing with it. For a portable/compact solution, it is a reasonable but not full substitute for a Kinesis (basically on the go).
I think the default layer-switching choices are still uncomfortable for me, and I am looking for a better layout to stabilize.
My main interest in the Atreus is hobby-oriented, to learn how to use Plover with it: http://plover.stenoknight.com/
Are they fads, though, inherently, or because of a lack of cultural and financial support? I like to learn from all of them but have no idea how to make a new effort that is worth more than just a splash of publicity.
My current bet is on just getting smart software in the hands of a wide audience that don't listen to programming culture.
What else can one do? Who are we rewarding by the way things work now?
Really, an image is just a heap snapshot with roundtrip serialization possibilities. You want to be able to serialize all the operational data structures, so the model of data has to sort of respect a certain abstraction layer. One consideration is whether the image has to be portable; word-size of 32 or 64 bits, or under endianness. This has strong implications about what kind of code you can keep in the image.
You also would want hooks for startup and shutdown if you expect to be able to snapshot a heap and then restart it under a debugger, say, and get the runtime circumstances that are relevant, like open sockets and files, dynamic-linked libraries, and so on.
Smalltalk lexical style makes certain kinds of notational customizations difficult to compose. I want multiple kinds of brackets that could get used for DSLs. Slate did manage to make prefixes and suffixes customizable and make much more into operators than Smalltalk allowed, at least.
But we did have extreme whitespace sensitivity between tokens so "3+4" was a single token. That was our fault, even if it enabled many interesting notations.
XCode's Interface Builder is an Objective-C knockoff of a Lisp tool from the 80's which needed a lot of work even back then and never received it.
We're talking about two decades of extremely limited conceptual progress on interaction. The only GUIs that are run over network streams are HTML/JS/CSS, and those took about fifteen years to turn into fully standalone clients, and not terribly reliable or secure ones at that.
We still don't have a continuation concept (workflows that can be set aside like data items and continued at any point in time) in any shipping UI, despite that being demonstrated 10 years ago at MIT.
We still very typically treat dates and times as text strings instead of first-class manipulable objects whose identity is separate from presentation.
I could go on, but I'm just trying to convey the sense that our (known) future is stuck in the past.
The question is how to do it and with whom and for what audience.
And then I threw it away as a learning exercise. It was a few years of skills building before I really tried to make a language project. Slate had a few incarnations which were quite different from what it currently presents as.
Homoiconicity is overrated; Atomo and Atomy represented better where I wanted to go, which is to adapt notation to the problem, even have it be flexibly remapped and recombined per modular scope.
Slate had some design goals, but a lot of the goal was general, like "how much can we fit into Smalltalk and still have that core idea be recognizable and coherent?" Multimethods, prototypes, macros, optionals, etc. were all just a part of that.
We did spend a lot of the project's focus on how heavily we could leverage multimethods to clarify and collapse code. Slate probably uses multimethods better than any language I know of, although I admire what Julia does with it within the Matlab/R compatibility constraints.
Mainly, we wanted to take operating systems and meld them with computer languages. The TUNES project says a lot of what I think about that (with a good deal of ideological distortion and handwaving, but that's group editing for you).
Honestly, I checked Alan Kay's philosophical reading list, and its depth in phenomenology and developmental psychology was stuff I covered in college. While he belongs to another generation, I'm keenly following the ideas of the FoNC project and hope to deliver something that takes that to an everyday context broadly.
And Atomy: http://vito.github.io/atomy/
Both of these, I feel, are interesting small offshoots that explore more in a pattern-matching metaprogrammable grammar direction, although they never became large visions or systems.
Obviously not ideal, but we leaned in the direction we hoped others would see. I don't think enough people saw what we were doing beyond the front page news blurbs. Slate has a lot of good code in it.
If I continue, it will be with a specific story in mind about who it's for and what message to convey. I have been attending The Strange Loop for a few years now and growing some ideas to write about.
It's worth noting that Slate was one major project in a long stream of development I started privately in the early 1990's and then brainstormed with some nerds on at the TUNES project until I made Slate its own thing (a kind of stepping stone towards the TUNES goals).
We wanted to make the idea of a programming world as an OS manifest, so Slate images and object networks are like a file system image. The most straightforward way for us to get into that was dynamic with optional typing.
The idea at some point was to have staged meta-programming (like we did to build the VM out of Slate) that was typed, so that the static existed within the dynamic but in a more obvious way than "sure, my Haskell universe exists on a nasty filesystem".
We tried.
Morphic alone was not good enough to build the future out of. First-class information objects called presentations from the CLIM history would have complemented it nicely.
Main regrets: - Starting with multiple delegation from Self; we migrated to Traits a la Squeak and Perl6 but it was pretty late in the project. - Hewing too closely to Smalltalk syntax, instead of ditching the lexical awkwardness for keyword syntax and more conventional but unambiguous lexical patterns. - Image-based bootstrapping was useful, but too monolithic. I wanted to make it have a symbolic graph linker to stitch together images from modules. That would have kept the project flexible enough to keep going.
As it is, I'm disillusioned with the open source and software research fields, and working on startups to accumulate my own funds to run a project like this without being subject to the rhetorical whims of a diseased culture. Hah!
You may as well AMA.