I have definitely found that electric vehicle companies advertise very sound and realistic figures for their mileage.
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 am a Kinesis Advantage user with ten years' experience, and agree with this.
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.
Hum. I hear you. I've tracked demos come and go with their hype and lack of delivery.
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?
I've heard of NQP but haven't dug into it. I suppose you could, but I'd estimate the effort as higher than for say Rubinius which has been tracking a Smalltalk model since its inception.
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.
Yeah, Fortress had a lot of good ideas that we were looking at. We toyed with a way to render and enter unicode operator characters using angle tag notation a la "<circle-plus>". The whitespace idea is interesting but a little dangerous; I think we just need to be able to separate the syntax from the viewer and editor interactions.
A little bit of both; I'll skip unfamiliarity and get to the awkwardness.
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.
Well, I'd like to explore a link-phase to build images. I think that'd be really quite interesting and might break up the monolith and mix Smalltalk ideas in with Unix as they ought to have.
UI research and development stopped dead in its tracks in the early 90s, and most people who've developed UIs now effectively think a whole class of problems are not solvable or even worth thinking about.
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.
I will say that I'm not done yet; I fully intend to build a practical system that hands the lessons of FoNC to the everyday context. I've learned a lot over the years and tried my best to smooth out my early rough edges.
The question is how to do it and with whom and for what audience.
I was perverted by AutoLISP and CADForth in the very early 90's. By 1995 I was in college and researching on my own, found Self and Squeak and made a rather stupid but fun little lisp that ran on DOS4GW and built a Motif-style Morphic-like UI out of it.
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.
Clojure deserves a lot of respect for attacking concurrency in a totally new way, but I would not call it mainstream.
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.
I know Steve Dekorte and remember him bringing me along to visit David Ungar over beer and pizza more than a decade ago. :) Io doesn't quite address the goals I wanted, and it was dynamic in ways that prevented some optimizations. But it is rather charming.
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.
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.
I guess I should say that we built a type system in Slate using objects and multimethods; it was used for metaprogramming and self-hosting.
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.
I don't feel motivated to work on it (this particular artifact) any more. I want to make something relevant to and appreciated by an audience, and programmer culture seems to be unwilling to do that in a deep way.
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).
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.