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…
> 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.
The Unison language
41–50 of 144 posts
Re: The Unison language
#42Kudos 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…
" 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 resolve…
> 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".
Re: The Unison language
#43I 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'?
Re: The Unison language
#44One 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 excepti…
Perhaps this is the reason:
https://www.unisonweb.org/docs/language-reference#a-note-on-...
Re: The Unison language
#45Earlier quoted context omitted.
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 collaborat…
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.
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!
Re: The Unison language
#46Earlier quoted context omitted.
Small code samples tell me next to nothing. How could they. I want a clear explanation of the foundational aspects.
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
How can you tell the elegance or gotchas from a 6 line Hello World?
Re: The Unison language
#47Maybe 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 impr…
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.
Re: The Unison language
#48One 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 excepti…
Perhaps this is the reason: https://www.unisonweb.org/docs/language-reference#a-note-on-...
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.
Re: The Unison language
#49I 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...) A…
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...
Re: The Unison language
#50Earlier quoted context omitted.
Small code samples tell me next to nothing. How could they. I want a clear explanation of the foundational aspects.
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
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.