Unison
-
I might have found my next language.
- Programs are edited in a (browser-based) semantic editor which guarantees programs are well-formed and typecheck by construction.
- The codebase is a purely functional data structure
- The program is a UI, and UI interaction is programming.
- Persistent data sources must be accessible via a high-level, typed API. Unison’s architecture means that all Unison values can be trivially (and efficiently) serialized and deserialized to a persistent store.
And other neat features.
-
I thought this was going to be about some new public sector strike in the UK.
-
http://what.thedailywtf.com/t/unison-architecture-astronauts/48500
Figures you'd like it.
-
The program is a UI, and UI interaction is programming.
Like Smalltalk and Oberon then?
-
Why in God's name does their about section break at letter boundaries on my phone? If that's a sign of things to come, I'll give this one a miss.
-
-
I don't understand this at all.
The state of the graphical programming environment is the state of the program itself — environment and program are not truly distinguished — so anything that builds or alters the state of the environment is creating the program. It's a model that's been tried from time to time, and it works reasonably well for research systems and sucks for production systems; I'll leave it to the interested reader to figure out why this might possibly be the case…
-
-
UI interaction is programming
If they're trying to tell us that using Facebook makes my sister a programmer, I would like to leave this planet and find an identical one without them in it. Also with Half-Life 3 in it.
-
If they're trying to tell us that using Facebook makes my sister a programmer, I would like to leave this planet and find an identical one without them in it.
Unlikely, but plausible.
Also with Half-Life 3 in it.
Never mind...
-
I'll leave it to the interested reader to figure out why
I will show no such restraint: It is because good design all but necessitates the separation of those two concerns. (Research systems do not require good UI design).
-
It is because good design all but necessitates the separation of those two concerns.
That piece of reasoning smells suspiciously circular. Try again. :-)
-
-
I think the model is meant to be richer than just "graphical repl", though that's where Unison starts. What I got out of the summary is that it's really a distributed, type safe, (probably) functional language. So it's "made" for building and managing complex multiple-system applications, with "automagic" dashboards.
-
I didn't know it had been posted before.
But I disagree with the architecture astronaut label. Haskell has been able to do a lot of this stuff for years, at least with libraries. Unison just extends the ideas, and fixes some of Haskell's problems (like the possibility of DLL hell, by having types get indexed by UUID.)
Considering how much GHC is able to (nearly) automatically derive for data types (like parsers, emitters, pretty printers, serializers, complex type classes -- you just have to tell it what you want to derive), it only makes sense to have a compiler do that stuff automatically, and do it in a way that is consistent across systems/hosts, so that you can dispatch computation between nodes.
-
having types get indexed by UUID
Is that for named types? If it's for structural types like simple tuples too, you're in for a different world of pain. I think it helps if you think in terms of having two broad families of types — open box and closed box types, where the former can be handled by anyone, and the latter can only be handled by their own special named constructors (and for which you might define your own notion of equivalence that isn't just simple field comparison). UUIDs only make sense for closed box types; open box types are structurally compared (or are fundamental atoms like integers, of course).