[HN Gopher] The Unison language
___________________________________________________________________
The Unison language
Author : ocfnash
Score : 212 points
Date : 2020-01-10 10:15 UTC (12 hours ago)
(HTM) web link (www.unisonweb.org)
(TXT) w3m dump (www.unisonweb.org)
| blamestross wrote:
| Append only is nice, but I would think a "Garbage Collect" would
| be useful. Remove all the code not attached to the import tree
| anymore. Otherwise you will just keep collecting junk forever
| Honestly git has the problem too, but I expect orphaned/dead code
| will happen a lot more with this approach.
| SamBam wrote:
| Git has this problem only as far as the developer's storage of
| the history of all files is concerned. That "junk" doesn't
| remain in the final program.
|
| You can have a decades-old git repository containing hundreds
| of MBs of files, but output a 2kB program. Someone correct me,
| but it sounds like if you had the same thing with a unison
| project, the actual executable size can only grow?
| lilyball wrote:
| My assumption is the content store can only grow, but any
| executable produced from it would only contain live code.
| jedimastert wrote:
| Maybe I've been out of the game or something. But I don't think
| saying everything is "content-addressed" can land as such of a
| big mic-drop moment when I've never heard the term or the concept
| in my life and the front page does absolutely nothing to explain
| it beyond that.
|
| ------ EDIT: My tone here is a little more antagonistic that I
| meant (proofread kids, don't just check for spelling and publish)
| but my first impression was a kind of "buzzword-y" vibe. I've
| looked a bit more and the authors seem genuinely passionate about
| shaking things up and trying something completely different,
| which I can respect. I'll leave it up as is because I still think
| my issue are legitimate, but the tone is a little off and I
| apologize. ------
|
| Let's take my discovery path so far as an example:
|
| > Functional language: cool cool. I know what that is. Immutable:
| also cool. Content-addressable: no clue. Saying it'll simplify
| code bases and eliminate dependency and "no builds" is supposed
| to sound amazing, but it really doesn't land when I have no clue
| what the premise is.
|
| > Alright, that's it for the front page. No code examples,
| nothing linking the currently known to this new paradigm-shifting
| stuff. K. Let's try the docs.
|
| > The Welcome is the state of the project without saying anything
| about the language itself. Roadmap isn't gonna help Quickstart!
| Let's look there.
|
| This amount of effort for discovery isn't very helpful for me. I
| found a selection of talks elsewhere on the site. One of them is
| labeled "This is a longer (40 min) introduction to the core ideas
| of Unison and probably the best talk to start with." That might
| be a nice link for the front page.
|
| I unfortunately don't have anymore time to look at this this
| morning, but the first 5 or so minutes of the talk say
| waaaaaaaaay more than the first however long I spent. Honestly, I
| think all of that information (code examples, linking core ideas
| to what we already know, basis of comparison) could be on the
| front page.
|
| The tl:dr I can glean from it is:
|
| It's kinda like Haskell, but every definition is turned into AST
| and put in a hash table. Any references are secretly references
| to the table, so changing a definition is making a new hash and
| changing the reference, and renaming is changing the reference to
| name table.
|
| Also, everything is append instead of rewrite, which makes all
| kinds of stuff cleaner, like versioning and refactoring.
|
| Pretty neat idea, I just don't really like how long it took me to
| come to that knowledge. I don't know how well it would scale or
| be usable in a real world scenario, but I also have never used
| Haskell or any functional language in a "real world" scenario so
| I'm not the best one to ask.
| zaphar wrote:
| content-addressable is admittedly perhaps a little bit niche.
| If you spend some time in the version control/distributed data
| structures space you will have run into it. But if you haven't
| d then you will perhaps never have encountered it. Your
| description of a hash table and references is a pretty close
| description of the idea at it's core.
| refried_ wrote:
| Hey; Unison author here--
|
| Definitely appreciate this honest and helpful, specific docs
| feedback, so thanks for taking the time to put it together. We
| do want the value of Unison to be straightforward given even a
| quick skim of the site, so: sorry about the current state,
| we'll try to improve it. :)
| jedimastert wrote:
| No worries. I guess it sounded a bit antagonistic, I
| apologize for that. I am actually interested in the idea, I
| was just a little frustrated that it was hard to figure out
| what was different about the language.
| nlh wrote:
| Just to add to that - I'm kind of in the same boat here. I
| had to read the homepage and intro sections a few times and
| I'm honestly still a bit lost in understanding who this
| benefits and why.
|
| Just by way of anchoring: I'm no dunce, I'm a typical nerdy
| guy who knows his UNIX and has written lots of C, Python,
| JavaScipt, Ruby, etc. Written some mobile apps. Written
| plenty of web stuff. But I'm not immersed in any academic
| language study and not really an FP guy.
|
| I don't think you should dumb this down - the text itself is
| very good prose. But the context is missing something --
| perhaps a paragraph or two of anchoring for us "normal
| programmers" to explain why this is relevant to people who
| normally write Python web apps or Rust utilities or C++ games
| all day long (or if it's not relevant, why, and who it is
| relevant for).
|
| Good luck with the project!
| m712 wrote:
| No mention of Smalltalk in the comments? The "codebase" that is
| managed by ucm sounds very similar to Smalltalk images. I am
| personally delighted about this.
| UglyGenius wrote:
| Wondering if Unison was designed as (or ever planned to become) a
| general-purpose language or it something more domain-specific,
| e.g. distributed computations.
| thethimble wrote:
| Does anyone know how concurrency is handled on Unison? I couldn't
| find any references in the docs.
| tracnar wrote:
| There's an example in this talk:
| https://youtu.be/gCWtkvDQ2ZI?t=1903
|
| Basically you can quote code (like in Lisp) and pass it to an
| executor (thread, remote server, ...).
|
| The main difference is that thanks to the immutability, you can
| also have a protocol which shares efficiently all the
| dependencies required to execute the code (like a git pull).
|
| It also uses an effect system, so the implementation does not
| need to decide which executor to use, it only uses an interface
| called an "ability", and the caller can choose the
| implementation.
| losvedir wrote:
| Very cool. Glad to see someone tackling the idea I first saw
| brought up by Joe Armstrong[0]. When I read his post it made so
| much sense, I was hoping I'd get to see someone try it.
|
| [0]
| https://joearms.github.io/published/2015-03-12-The_web_of_na...
| forgotmypwd123 wrote:
| The name is already pretty taken....
|
| https://en.wikipedia.org/wiki/Unison_(disambiguation)
| hobofan wrote:
| That list looks like its very available to me? The only overlap
| with software are two unmaintained projects.
| vidarh wrote:
| It's incomplete. There's at least the Unison file
| synchronizer as well:
|
| https://www.cis.upenn.edu/~bcpierce/unison/
| nadam wrote:
| I find the content-addressed, name-independent, immutable (kind
| of blockchainy) approach to source code very interesting. On the
| other hand this seems to be rather orthogonal to other (semantic)
| aspects of the language.
|
| I wonder what would happen if we would change one thing at a time
| to test the idea: create something like unison based on an
| existing popular programming language. (python, javascript, java,
| etc...) All the syntax handling, building and version control
| would be done the unison way, but the interpreter would be the
| same as today in that popular language. The benefit would be that
| a lot of existing code could be transferred into the initial
| 'blockchain', with all the current dependency hell being solved
| from day one. I did not think this through deeply though... Maybe
| some aspects of existing languages prevent them to be handled the
| 'unison way'?
| zubairq wrote:
| I have done exactly that with a language called Pilot. It is
| not pure JS but based on JavaScript and all code is content
| addressable and indexed by the sha256 of the code
| ed wrote:
| Google isn't turning up much. Is the project open source?
| Would love to take a look.
| brodo wrote:
| I tried something like that in 2016 with Javascript. I parsed
| the source code and put every AST node on IPFS and linked it to
| the other node using the hashes. The problem was that this is a
| _lot_ of overhead...
| sktrdie wrote:
| I like the idea of syntax-tree rather than filesystem directories
| (if that's the main difference).
|
| Seems like this could be implemented in other languages though,
| and don't really understand why we need yet another new language.
|
| For instance, can I not build my JavaScript code in similar ways:
| I would need a compiler that stores things in trees rather than
| dirs.
| UIZealot wrote:
| This is seriously impressive. I've always felt that some kind of
| database system is needed for code in which you store each
| function individually. Unison not only has that, it goes one step
| further to identify a function by its hash. I can't wait to see
| what the world of programming can become along this direction.
| Vlad_Zamfor wrote:
| >>code is content-addressed and immutable.
|
| No, as I keep insistently repeating: Code is content-immutable
| and addressed.
|
| Also, Urbit is a lie, Surface detail is true and you are a lie
| and your code is retarted.
| Vlad_Zamfor wrote:
| Blaaaaaaah. (No I'm not being sick.) Blaaaaaaaaaah. I am not a
| robot. Repeat: I am not a robot, I am a human being. But I love
| your (timeless) decision theory.
| emmanueloga_ wrote:
| "Unison: a new distributed programming language" by Paul Chiusano
| [1]
|
| 1: https://www.youtube.com/watch?v=gCWtkvDQ2ZI
| the_duke wrote:
| This talk highlights the benefits and interesting features of
| Unison much better than the docs.
|
| Highly recommended.
| capableweb wrote:
| The video is from Sep 15, 2019 and still more useful than
| their website? Anyone have a transcript to link?
| ed wrote:
| For a good introduction, watch this talk at 1.5x speed from 2:50
| to 5:40
|
| https://youtu.be/gCWtkvDQ2ZI?t=170
| cprecioso wrote:
| Content-addressed, immutable code? Reminds me of
| https://thedailywtf.com/articles/the-inner-json-effect
| pcr910303 wrote:
| A TLDR for the tour[0] based on my understanding (please fix me
| if I'm wrong):
|
| Unison is a functional language that treats a codebase as an
| content addressable database[1] where every 'content' is an
| definition. In Unison, the 'codebase' is a somewhat abstract
| concept (unlike other languages where a codebase is a set of
| files) where you can inject definitions, somewhat similar to a
| Lisp image.
|
| One can think of a program as a graph where every node is a
| definition and a definition's content can refer to other
| definitions. Unison content-addresses each node and aliases the
| address to a human-readable name.
|
| This means you can replace a name with another definition, and
| since Unison knows the node a human-readable name is aliased to,
| you can exactly find every name's use and replace them to another
| node. In practice I think this means very easy refactoring unlike
| today's programming languages where it's hard to find every use
| of an identifier.
|
| I'm not sure how this can benefit in practical ways, but the
| concept itself is pretty interesting to see. I would like to see
| a better way to share a Unison codebase though, as it currently
| is only shareable in a format that resembles a .git folder (as
| git also is another CAS).
|
| [0]: https://www.unisonweb.org/docs/tour
|
| [1]: https://en.wikipedia.org/wiki/Content-addressable_storage
|
| [2]: https://github.com/unisonweb/quickstart
|
| PS: The website is very well made, but I would like to comment
| that there should be two buttons on the top front page, the tour
| and installation, as I think most people want to have a glimpse
| of the PL before installing. I, at least was puzzled because I
| thought the button was a link to an introduction of the language.
| Avi-D-coder wrote:
| I really like the idea, I like the language, but the world will
| not be rewritten in Unison. A web assembly FFI story is needed
| for Unison to succeed.
| tasogare wrote:
| Is this satire? Web assembly has no real adoption on the
| browser yet, is waiting for a standard I/O interface on the
| desktop to be useful and is itself the nth iteration of an old
| concept.
| Avi-D-coder wrote:
| Web assembly is the first time a binary assembly has been
| adopted as an open web standard. What do you propose as an
| alternative safe sandbox for other languages?
|
| Large quantities of code can already be compiled to WASM.
| Since Unison works best with pure functions, most system
| interfaces would presumably be emulated. This emulation is
| already possible with Browsix.
| strbean wrote:
| Unity targets WASM. I've run into several browser games using
| it in the wild.
| ivanbakel wrote:
| Reading the tour[1], I got the impression of being struck by
| something not that surprising, but still fundamentally
| groundbreaking.
|
| Beyond just the idea of a global program store (which I hope has
| space for some virtualenv equivalent), the cleverness of effect
| handlers as a first-class language feature is very exciting.
|
| Once the type system is more mature, this could easily be the
| next kind of Haskell - a language which redefines modern ideas of
| good programming.
|
| 1: https://www.unisonweb.org/docs/tour
| thesuperbigfrog wrote:
| Unison seems to combine ideas from Forth, Haskell, and
| Clojure's Datomic and stir them together into an interesting
| mix:
|
| Forth ideas: a global dictionary with pre-existing and user-
| definable words
|
| Haskell ideas: functional programming and type signatures of
| functions / words
|
| Clojure Datomic ideas: immutable store of object definitions
| that append and use references to point to the latest
| definitions.
|
| I am curious how I/O and error handling are done in Unison.
| ivanbakel wrote:
| If you look at the other reply to my comment, someone has
| linked the Unison docs on their effect handlers
| implementation - which is what is used for IO, and with any
| luck, error handling as well. Haskell has several packages
| for effect handlers, and they're taking off in programming
| and category theory circles as alternatives to monads for IO.
|
| The short summary is that you can write code with side-
| effects that you don't define the implementation for, and
| then let call sites handle those effects or defer them.
| the_duke wrote:
| Since it took me a while to find it, the relevant documentation
| is under "Abilities and Ability Handlers" [1]
|
| [1] https://www.unisonweb.org/docs/language-
| reference#abilities-...
| giancarlostoro wrote:
| One thing that takes away from programming languages is not
| having code samples on the index. I think this lets someone know
| immediately if it's interesting to them or not. Show a sample of
| code with the console output or a screenshot of an UI from the
| code. I think Racket had it right ages back. They would show
| everything from a web server, to other things. This is what major
| programming languages (with some exceptions) basically do and it
| gives a developer more information than any amount of marketing
| speak.
|
| That said, I had to dig in the documentation to find code, and it
| didn't seem as obvious cause the syntax is definitely different
| from what I'm used to and there's weak syntax highlighting.
| Tade0 wrote:
| Perhaps this is the reason:
|
| https://www.unisonweb.org/docs/language-reference#a-note-on-...
| ktpsns wrote:
| Interesting. Maybe they should add further representations of
| the code. This is not the only language where there are
| mutliple representations of the same "code".
|
| Wolfram Mathematica (or "the Wolfram language") introduced
| "forms" for that, for instance
| https://reference.wolfram.com/language/ref/FullForm.html or
| https://reference.wolfram.com/language/ref/InputForm.html or,
| quite charming in the math context, https://reference.wolfram
| .com/language/ref/TraditionalForm.h... or
| https://reference.wolfram.com/language/ref/TeXForm.html --
| See also https://reference.wolfram.com/language/tutorial/Ever
| ythingIs...
| dunham wrote:
| Also Bucklescript and ReasonML respectively provide OCaml
| and javascript-like syntax over the same AST and can
| translate your code between the two (as seen in the try
| reasonML UI).
| floatboth wrote:
| That's not exactly how it works: Bucklescript is a JS
| backend for OCaml, and ReasonML is an alternative syntax
| for OCaml. Bucklescript is not involved in this
| translation, it generates the JS output on the top right
| pane of that UI.
| hybrids wrote:
| https://forum.nim-lang.org/t/2811
|
| The Nim language in 2008 (when it was known as Nimrod) had
| originally been planned a similar approach of considering a
| unified AST with multiple "syntax skins," and as far as I
| understand there used to be a limited implementation of this.
| This would theoretically have been a boon for Nim, because an
| often complaint about Nim from emigrating programmers from
| languages with a C-style syntax was the (rather superficial)
| complaint - "no braces? Pythonic syntax? Yuck!"
|
| https://forum.dlang.org/thread/mailman.1427.1428691340.3111..
| ..
|
| The problem with this - and why Nim never really committed to
| the "syntax skin" concept - is that it would have led to far
| much fragmentation within Nim's own community as some users
| would prefer one "sub-language" over another. Given as it is
| the opinion of new languages (Nim included) towards a tool-
| based unified syntax formatting (e.g. certain naming
| conventions for identifiers, number of spaces for indent),
| "syntax skins" have become harder of a sell in favor of
| lingual consistency.
|
| The original idea was that the same program could be rendered
| in a variety of different syntaxes in the author's IDE - but
| the implied maintenance cost of such skins plus that
| previously mentioned potential for fragmentation led to this
| idea falling to the wayside. Nim, as a language, grew to be
| quite flexible within its prime syntax over the years - e.g.
| the macro system (which modifies the AST directly) made way
| for a variety of DSLs (e.g.
| https://github.com/khchen/wNim#code-examples) that remain
| valid Nim code.
| giancarlostoro wrote:
| Thanks for this, I totally missed this nugget. If it's on the
| front-page it should be made more obvious. Whether it's code
| or some sort of video, every language should showcase
| something that tells you what development is like. Code you
| can interactively compile from a front page is always a plus
| too.
| xixixao wrote:
| TBH if you're creating a new language after 2014 you should be
| thinking about how to get good syntax highlighting and other
| tooling from the language definition itself, because you're
| competing with a ton of mature languages that had to do this
| manually through a ton of effort of their communities.
| DelightOne wrote:
| How do you get it from the language definition? By adding
| metadata to it?
| ahel wrote:
| have a look if you want some example and what dev process looks
| like https://dev.to/petets/palindromes-with-unison-5h9o
| perfunctory wrote:
| > One thing that takes away from programming languages is not
| having code samples on the index. I think this lets someone
| know immediately if it's interesting to them or not.
|
| Because when I see Chinese characters I know immediately if
| it's interesting to learn Mandarin or not.
| blain_the_train wrote:
| Small code samples tell me next to nothing. How could they. I
| want a clear explanation of the foundational aspects.
| robofanatic wrote:
| Little code snippets are nice to get a quick feel of the
| language. A good "Get Started" page is also a must have. I
| love languages or frameworks that have a step by step clear
| instructions on how to get started.
|
| It's almost like taking test drives when you go car shopping.
| You don't want to open the hood and check what's inside right
| away you just want to be able to drive the car.
| dunefox wrote:
| I want both.
| giancarlostoro wrote:
| That's the ideal amount of information.
|
| A reasonable example of a good page that is informative and
| provides lots of examples (enough at least!) is the one for
| D:
|
| https://dlang.org/
| Minor49er wrote:
| How can you choose a language without knowing the syntax?
| It's not arbitrary. Some languages have elegance or gotchas
| in how the syntax is laid out
| dudul wrote:
| How can you tell the elegance or gotchas from a 6 line
| Hello World?
| giancarlostoro wrote:
| It's how I picked my favorite Python web framework, I
| compared all the hello world samples they all had, and
| wound up with CherryPy. The rest had too many decorators
| and it just looked silly to me.
|
| You can also figure out if it's C-like or Lisp-like, and
| so on from looking at syntax.
| neurobashing wrote:
| you can infer a lot; is it LISPy, is it C-ish, or one of
| the Haskell family, etc. I think you can tell a lot from
| just which family of syntax.
| cttet wrote:
| No, take Reason as an example: it is basically Ocaml.
| Despite having a C-like syntax, it is quite different
| from it. The syntax barrier is usually much smaller than
| the language itself.
| CarlRJ wrote:
| And yet... someone trying to "sell" me a language while
| seemingly refusing to show me any code samples feels like
| someone trying to sell me a car based entirely on a spec
| sheet with no pictures and without actually seeing,
| touching or experiencing the car. They both provoke a
| reaction of suspicion - "what are they trying to hide?"
| As if they don't trust me, the customer, to be able to
| understand the very thing they want/expect me to buy.
|
| I'm perfectly fine with a page that says, "here's a code
| sample - notice that it looks similar to C, but here's a
| list of reasons / an explanation of why/how it's actually
| quite different from C."
|
| One of my favorite programming books of all time is K&R,
| from back before ANSI, even. It said, "here's a simple
| problem to solve, and here's how you solve it in our
| language." Repeatedly. Explaining how the features helped
| to solve the problem at hand. It was revelatory. And it
| assumed its audience to be knowledgeable programmers. It
| didn't spend the first chapter just describing all the
| features or how great the language is without showing any
| code.
| thesz wrote:
| For many programming languages the line count of "hello,
| world!" program is exactly one.
|
| So you can deduce something just from a line count of
| simple program alone - for one such deduction is an
| answer to a question "are there at least some attempts to
| provide useful defaults?"
| chhickman wrote:
| I agree that a Hello World is fairly useless example for
| anyone already familiar with programming languages.
| Perhaps something like a Fibonacci function should be the
| de facto short syntax example, as is common in functional
| languages. More useful though would be to have an example
| of how composition data structures work in the language -
| standard example could be a binary tree.
| tobr wrote:
| Syntax is easy to show, but ultimately rather unimportant.
| If the big idea of a language is something substantial,
| starting by showing the syntax arguably just creates a
| distraction.
| vidarh wrote:
| Syntax stops me from even considering some languages,
| because to a lot of us it _is_ important. I spend most of
| working hours reading code; as a result how easy it is to
| read is important not just for my productivity, but for
| my overall happiness in life.
|
| A small sample on the front page will not tell me if a
| language is good enough, but it can give me an idea if
| it's worth spending more time reading up on it or not.
| elcomet wrote:
| Syntax is something you become used to in a few hours.
| But it's not what's the most important and will make your
| time more efficient in the end.
| frenchyatwork wrote:
| 2000 years ago, they didn't have spaces or punctuation in
| writing. We could try dropping them again, and people
| would adjust after a few hours, but that doesn't mean
| that the spaces and punctuation don't provide value.
| antisthenes wrote:
| > Syntax is something you become used to in a few hours.
|
| This is completely subjective and not at all universal.
| vidarh wrote:
| Maybe you do. I don't. Syntax is something that has a
| substantial impact on how I think and work. Presentation
| overall matters immensely.
| setr wrote:
| The problem is that readability is largely a matter of
| naming conventions, organization, and adherence to known
| patterns. The language becomes more readable as you use
| it. Anything that isn't a C derivative is unreadable if
| you only know C.
|
| There are of course actual blockers to readability, like
| usage of similar-looking sigils and poor system library
| naming, but otherwise the syntax really doesn't tell you
| any useful information. It's the semantics that tell you
| how it'll all fall apart
| vidarh wrote:
| I couldn't disagree more. Syntax changes whether I can
| look at a page of code and get an idea of structure and
| which elements to focus attention on, or whether I need
| to read everything in detail.
|
| It doesn't matter _that much_ when I have found a piece
| of code that I need to read and understand every detail
| of, but that is a tiny proportion of the amount of code
| reading I do - most of the time reading code is about
| grasping overall structure to learn a codebase well
| enough to find the points you need to focus on and read.
|
| A clean syntax makes the difference between always having
| to read each token vs. being able to speed-read by
| pattern matching high level structure when you don't need
| the details of that specific piece of code.
|
| I've worked with dozens of languages, with wildly
| differing syntax, and I'll say that once you reach a
| certain base capability-level, syntax matters _more to
| me_ than semantics.
|
| You can paper over a _lot_ of semantic difference.
|
| I can (and have, and so have many others) build libraries
| to do object-oriented programming in C, for example, and
| I have implemented closures in C too [1]. So the reason I
| don't do much C any more is not semantics, but that there
| is no mechanism for plugging those semantic gaps _that
| creates readable code_.
|
| There are languages where the semantics paints you into a
| corner and makes plugging the holes too hard, so it's not
| that semantics doesn't matter _at all_. But it 's usually
| easier to paper over semantic gaps than unreadable
| syntax.
|
| [1] http://hokstad.com/how-to-implement-closures
| scott_s wrote:
| I don't want small code samples. I want well defined problems
| that this particular language is well suited for, as
| demonstrated by a dozen (or a few dozen) line program which
| uses the core features of the language to elegantly solve
| that problem. That gives me a feel for what the language is,
| and if interested, I'll learn about the foundations.
| agbell wrote:
| I have learned a lot from the creators Paul and Runar in that
| past. Their book on FP is legendary in some circles. Unison seems
| like a super ambitious undertaking, but I wouldn't bet against
| this team.
| war1025 wrote:
| Maybe I'm missing something, but this seems like it would get
| unwieldy very quickly for anything more serious than toy
| examples.
|
| Even the toy examples I'm having trouble following along with.
|
| The benefit of code-as-text is that you can navigate the text
| without knowing what you are looking for.
|
| This seems to take the opposite approach of making it very easy
| to look things up _assuming you know ahead of time what you are
| looking for_.
|
| That is something that a good usage of grep or some more
| sophisticated IDE integration will already take care of for you.
|
| The only thing I could see this being potentially useful for is
| "notebook" style computation, where you are really only using the
| language to do things like structured math calculations.
|
| What am I missing here?
| strbean wrote:
| > What am I missing here?
|
| I think IDE tooling for Unison could pretty easily give you the
| exact same experience. Generate code from the AST, group it
| reasonably, and give you a view that is indistinguishable from
| a traditional source tree.
|
| It might be non-trivial to structure things nicely, but I think
| theres a good chance your generated structure would be better
| organized than a traditional codebase.
| alipang wrote:
| Algebraic effect handlers no doubt seem to be the future of
| getting side-effects under control in programming languages, much
| like in the way of what immutability has done for data.
|
| My (admittedly little) experience with Unison though is that it's
| far from ready for the spotlight however. Much of the docs 404,
| and joining their discord mostly resulted in the advice to wait
| for future releases.
|
| I wish Microsoft would invest in something like the koka language
| https://github.com/koka-lang/koka. Perhaps the idea of content-
| addressable / immutable code could find a place too, but I think
| it's less critical.
| imglorp wrote:
| I've pondered using IPFS as a backend for content-addressable,
| immutable code blocks. That idea seems to fit in with the
| concept of structured or syntaxless programming, to assemble
| blocks into systems. Here's a list of the latter.
| https://www.reddit.com/r/nosyntax/
| pjmlp wrote:
| They already have F __* for such type systems.
|
| https://www.fstar-lang.org/
| tasogare wrote:
| > I wish Microsoft would invest in something like the koka
| language
|
| Given the ML-like syntax of Unison, it would be nice to see F#
| taking some of the key ideas.
| pjmlp wrote:
| F __*,https://www.fstar-lang.org/
| augustk wrote:
| I found this rather incomprehensible.
| kowolkian wrote:
| Hell yea, we can finally move forward with editors now. No more
| saving files with syntax errors. I imagine you could move a lot
| of paredit functionality into an editor like this, or have
| excellent voice editing.
| DerSaidin wrote:
| This is cool.
|
| I've wanted to see a Merkle tree based AST for faster incremental
| compilation (and incremental static analysis).
|
| I wonder if the source manager interface makes this easier to use
| than editing source files?
|
| AST can still be the source of truth. To edit need to generate
| source text from AST, edit as text, parse to AST, save.
|
| In other words, I think most of the benefits of this can live
| behind the scenes for other languages.
| bnjmn wrote:
| I don't think you can have a proper Merkle _tree_ if cycles are
| possible, and cycles definitely are possible in this AST
| representation: https://www.unisonweb.org/docs/faq#how-does-
| hashing-work-for...
| stef-13013 wrote:
| The language of the month... (Can't wait february)
| kbr wrote:
| Looking at their GitHub [1], it's been actively developed and
| open source since 2013.
|
| [1] https://github.com/unisonweb/unison
| rzwitserloot wrote:
| Kudos to them for not using the buzzword, but if you believe in
| the notion that 'blockchain is just a fancy buzzword that gives
| developers the ability to get managers to agree to larger budgets
| to clean up tech debt', this is.. blockchain programming.
|
| One problem I did find: Somewhat deeper into the tour, the tour
| makes the claim:
|
| > a Unison codebase can be versioned and synchronized with Git or
| any similar tool and will never generate a conflict in those
| tools.
|
| This is pratically speaking of course not true: If you have some
| unison codebase, whilst under the hood it's all hashes, that
| doesn't change the simple fact that if 2 people both check out
| the exact same code, and then both people make a change to how
| the software operates, where that change is conflicting (say, I
| make the green 'OK' button now red, and you make it blue), you..
| have a conflict. That is a fundamental property of this
| interaction; no language bells and whistles can ever change this
| fact.
|
| So, what does happen in unison? Is it 'last committer' wins?
| That'd be a bit problematic. A conflict in your version control
| system, _IF_ it is representative of the fact that there was an
| actual conflict (as above with the button and the conflicting
| colours), is a good thing, not a bad thing.
| steve_taylor wrote:
| > It is append-only: once a file in the .unison directory is
| created, it is never modified or deleted, and files are always
| named uniquely and deterministically based on their content.
|
| That's how conflicts are avoided.
| aidenn0 wrote:
| So I append X to my file and you append Y to your file, do we
| not have a conflict?
| capableweb wrote:
| Yes and no. Yes as in, if you'd like them to be merged into
| a new one, then you'll have to resolve a conflict. But no
| as in, you both appended different data, so you both have
| new files from the original one, as you're dealing with
| immutable data.
| strbean wrote:
| If you want to resolve merges using the workflow of git,
| you can generate scratch files and diff them, right?
| nadam wrote:
| " I make the green 'OK' button now red, and you make it blue"
|
| I did not fully read the introduction yet, but in my mind, in a
| truly content-addressed system this is not a conflict: you have
| the hash of a main() function which ultimately makes the button
| red, and the other guy has a main() function that makes the
| button blue. No conflict in the physical sense. Yes,
| philosophycally there is a conflict, which is resolved by you
| deciding which main() function you find more useful.
| theamk wrote:
| Looks pretty practical to me? Here is a described situation:
|
| Developer A made a change which adds feature X and makes a
| button blue.
|
| Developer B made a change which adds feature Y and makes a
| button green.
|
| Now the system does not allow both feature X and feature Y at
| the same time. Our options are either drop X, drop Y, or
| expend more effort/programming time to make a version which
| includes both X and Y.
|
| The description above applies equally well to Unison code CAS
| system and regular program in git. Sure, one is at the file
| level, and other at the function level - but you still need
| same kind of tooling. You want to look at the changes and
| somehow produce a merged version.
| the_duke wrote:
| Of course there are still conflicts everywhere.
|
| Developer A makes the button red, developer B changes the
| label from "OK" to "Accept", both inside the same function.
|
| You can't just pick one or the other, you have to combine the
| changes.
|
| Or two developers add two different fields to a type. Or ...
|
| Sadly the docs only have placeholders for "Concurrent work
| and resolving edit conflicts" and "Pull requests and
| collaboration". Would be very interesting to read the
| developers thoughts on this.
|
| The system seems to support patches, forking and merging.
| nadam wrote:
| Hmmm, interesting. It is getting a bit philosophical: you
| can view it as a conflict. But you can also view it as: hm
| we have these nice 2 main functions. Let's create a merged
| one. Kind of what was previously conflict resolution
| becomes part of regular programming... A slight perspective
| change.
| xwowsersx wrote:
| There's nothing philosophical about it! There will exist
| a conflict as far as Git (or any other) version control
| system is concerned. That's all he saying!
| pwinnski wrote:
| That seems to be incorrect. The linked page seems to
| suggest that both changes will exist without any conflict
| at the VCS level at all.
| the_duke wrote:
| That's like saying Git has no conflicts because a file
| can have different contents in different commits.
|
| A conflict can only arise when trying to unify (aka
| merge) two different states. The difference is the
| representation, with Git (naively explained) mapping file
| paths to text blobs , and Unison mapping identifiers to
| AST nodes.
| colonwqbang wrote:
| Then how do you know which main function to use? That
| information has to be stored somewhere. Or does the user
| provide the hash for the main function they wish to run?
| strbean wrote:
| The files holding the ASTs are append-only. So you get:
|
| PR #1: appended stuff
|
| PR #2: appended stuff
|
| So there is no merge conflict in the git sense.
| SamBam wrote:
| My small understanding is that the "(or any other)" part
| is not correct in your statement, and that you are locked
| into thinking of version control as being git-like.
|
| I think the implication is that version control is _not_
| git like, and that it 's not that we both changed the
| text on line 17, rather we both made additions to the
| underlying structure.
|
| Indeed, it's _impossible_ for us to both edit the same
| file, because files are never modified. They are
| immutable, like a blockchain transaction.
|
| I haven't quite understood how it works in practice,
| though, but definitely don't think "git".
| mbrock wrote:
| Mostly they are just not relying on Git for conflict
| detection and resolution, but bringing it up into the
| Unison system itself, in order to deal with it more
| gracefully and intelligently.
| zawodnaya wrote:
| This is the right idea. Conceptually there are conflicts
| which get resolved in the Unison tooling, but you will
| never get Git conflicts.
| [deleted]
| SideburnsOfDoom wrote:
| > Yes, philosophically there is a conflict, which is resolved
| by you deciding which main() function you find more useful.
|
| it's not just philosophical though. In git terms, when
| merging the two sets of changes, someone has to choose which
| of these functions goes onto the master branch. git calls
| this a "merge conflict".
| pwinnski wrote:
| No changes are ever made to an existing file, so there are
| never any merge conflicts. All changes result in a new
| object/file, named based on a content hash.
|
| So in git terms, there are never any updates, only
| additions, and therefore never any merge conflicts.
| SideburnsOfDoom wrote:
| Ok, if you want to be pedantic, lets be pedantic:
|
| > No changes are ever made to an existing file,
|
| I did not say or imply that there were. it's a new
| version, of course.
|
| > so there are never any merge conflicts
|
| Does not follow. There is only one HEAD (latest version)
| of foo.txt on the master branch. In a merge, it has two
| (or more) parent objects (1).
|
| > All changes result in a new object/file ... therefore
| never any merge conflicts.
|
| And yet somehow git calls the process of deciding what's
| in this new (version of the) file with two parents
| "resolving a merge conflict". Because the two parent
| changes can't be automatically reconciled. They are in
| conflict.
|
| 1) https://softwareengineering.stackexchange.com/question
| s/3142...
| Vlad_Zamfor wrote:
| David Bowie.
| rzwitserloot wrote:
| If it works precisely as you say, then most likely the last
| committer wins, and that's bad.
|
| The most hopeful case is that there is ONE place that isn't
| 'strictly append only', and that's, for lack of a better
| term, the 'main pointer'. Which hash is the actual state of
| the app as it should be compiled and deployed right now?
|
| Then THAT conflict, together with tooling to diff 2 different
| hashes, should swiftly lead to figuring it out.
|
| But then you're still kinda hosed; how do you merge 2 nodes?
| It sounds like you can't; you can only pick one. With git,
| you can do a text merge.
|
| I get the beauty of AST based storage and reasoning, but,
| hey, trying to use git to merge 2 versions of a word doc
| together is also a disaster, so it sounds like it'd be the
| same here.
|
| In that sense, unison is worse than your average (text based)
| language, not better.
|
| That's not actually a downside though; it's different. If I
| demerited the language for this, that's akin to complaining
| about a delicious roasted bell pepper because it doesn't
| taste anything like an onion.
|
| But I do find it a spot irksome that the otherwise well
| written tour is implying something here that doesn't appear
| to be true. Perhaps I'm merely misinterpreting it and reading
| more into that sentence than is implied.
| breuleux wrote:
| > The most hopeful case is that there is ONE place that
| isn't 'strictly append only', and that's, for lack of a
| better term, the 'main pointer'. Which hash is the actual
| state of the app as it should be compiled and deployed
| right now?
|
| I _think_ that 's how it works. The way I understand it
| from reading the tour, there is a separate store for the
| code and for the name mappings. Both main functions would
| merge without conflict into the code store, but the
| mappings would conflict.
| jayrhynas wrote:
| This [1] seems to be the "head pointer", and I assume it
| would conflict when merging. In fact, would it not
| conflict on every merge even if unrelated code was
| changed, since it hashes on the value of the entire
| codebase?
|
| Edit: After thinking some more, it wouldn't conflict on a
| file-level, since the file itself has a different name.
| But there would be now two files in the _head folder, and
| I assume the `ucm` tool would detect that and present the
| user with merging options?
|
| [1]: https://git.io/Jvfen
| Vlad_Zamfor wrote:
| Yes TFGP. This is...blockchain programming. What I find
| (somewhat) amusing () is that you changed your name from TTGP
| to TFFP. Why did she do that to you?
___________________________________________________________________
(page generated 2020-01-10 23:00 UTC)