We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
Love unison: * integrated source control, sharing & online documentation & browsing of source code (with links) * refactoring is a breeze * integrated unit tests that only run once (and are guaranteed to only run if anything they depend on changes) * the documentation modules are fantastic and you can include compiled snippets in it * the Abilities system is also awesome and it basically generalises exceptions & monads while at the same time being more understandable (in my opinion) than Monads * the scratch system is so nice! It's like the change, compile, eval loop is super tight and makes it very interactive and FUN to write code.
I wanted to share a video to colleagues but this wonderful language is sooo badly presented that I know they won't care. Runar, please spend time, significant, quality time, to reflect on how to market Unison. Show the magic, then explain the magic. You are explaining the magic trick before the audience even knows what is exciting about it! Don't think about hashes, and trees and what not. Talk about features, implications, user experience. Then, only after that, explain how this works.
that's a good question, when Runar says "implementation" I think he's actually referring to the "definition". For example, you can define generic data types such as List, Tree, etc and be able to define them in a generic way. eg if I have a type "List a = Nil | Cons a (List a)" then I can define generic functions such as "head" that will work "in the same way" on a List Int and on a List String. My understanding is that they basically create those hashes from the Abstract Syntax Tree hence they completely get rid of the concept of "source code". It just becomes an input to the parser. Once it's parsed THEN it gets assigned a hash and that essentially depends only on definitions, not names.
The "proof" of a unit testing having been run is interesting. 16:30 I wonder if there would be some way of not needing to store the hash of the unit test definition externally (blockchain or otherwise) as a record of it having succeeded. Something like creating a brand new definition that takes the unit test definition and success/fail result (and probably a private key for authenticity) as constant inputs. The existence of the hash of that new definition is proof it has passed (or failed), and the "compiler" and "documentation" systems know everything about it automatically. I am probably way off base, but the language internals definitely open up a lot of new ways of thinking about things :) Great video!
I believe you can in fact do as you describe, just by saving the test result in the codebase, with the usual “add” command. And this would simply retain a reference to the hash, instead of evicting it from the cache. So you don’t _need_ to record the hash externally, but you _could_ do so, if you wanted evidence that you actually ran the tests (and when). I believe this would let you very easily implement policies like “only allow pushing a deployment to the server if all the tests passed or a developer signed off on it with their key”.
@@EvincarOfAutumn Yeah, I thought about this more, and a function/definition in the code base, as you mentioned, that returns true and some sort of id/key should do what I am thinking - at least in my mental model. Thanks.
So, what happens when I've found a bug somewhere in my code? Should I then manually change every transitive dependency, with no indication if I've missed one?... Names aren't inherently bound to the implementation - often, they denote a concept, allowing the underlying interpretation to be changed freely. If Unison lacks this aspect, I don't think it'll find practical use
I just saw Unison for the first time today, so I'm guessing that the coder would be prompted with a list of code that calls this implementation and can select which use the new version and which continue to call the old buggy one.
Pondering this further - I do wonder about this removal of names, substituting them with hashes. In this or some related video, I think I heard the suggestion that devs don't like thinking of names so it will be universally beneficial to relieve them of this burden. Now maybe they don't like thinking of names, but it does seem to have some value. Every time a piece of code is called by name, the caller thinks only of the name and not the implementation. He just assumes that say, "ListCount" will return a count of the items in the list. Equally, the name "ListCount" is a clear reminder to the implementer of what the function is meant to do. Giving names to pieces of code is sort of like putting signposts in a new township. Once up, people can think about them and be guided by them, even request name changes etc. As far as I can tell from the videos, names are still likely to be used in the Unison model - but they are optional extras - maybe that's a good approach. Sometimes when writing code I will write let dunnoYet = .... in the hope I will think of a good name later :)
Names don't matter : I don't think it really is a problem to solve, modern language servers are able to change all occurrences of a name using refactor features
Dude… I’m 12 minutes in and you’ve lost me. All these features seem very cutsie and the mainstay of old dynamic languages. Cool parlor trick that this can be pulled off with strong typing, but why do i care? What does unison do that i can’t do today? What does it do better? How does it evolve the state of the art? I may never know…
@@higaski I think he means that if you compile everything first then someone decides to change method name you don't need to change it in other places even if someone bumps dependency version of your lib their code is still using correct hash. Now this might be cute to think about but having to carry over a mini DB as source code and having to rely on parsing it all the time sounds like a waste of cpu cycles when you have IDEs for renaming across whole project for local stuff and even on upgrade dependency replace all is just fine
@@higaski But when you start thinking about it early, you can come up with those things like global universe of every version of every definition in a cool and accessible way.
@@JobvanderZwan i am under no obligation to listen to a bad presentation. Have new ideas? Sell them, and sell them well. I’ve spend 100+ hours learning rust because the rust community have convinced me (lots of people) that they have something to offer.
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
Love unison:
* integrated source control, sharing & online documentation & browsing of source code (with links)
* refactoring is a breeze
* integrated unit tests that only run once (and are guaranteed to only run if anything they depend on changes)
* the documentation modules are fantastic and you can include compiled snippets in it
* the Abilities system is also awesome and it basically generalises exceptions & monads while at the same time being more understandable (in my opinion) than Monads
* the scratch system is so nice! It's like the change, compile, eval loop is super tight and makes it very interactive and FUN to write code.
I wanted to share a video to colleagues but this wonderful language is sooo badly presented that I know they won't care.
Runar, please spend time, significant, quality time, to reflect on how to market Unison. Show the magic, then explain the magic. You are explaining the magic trick before the audience even knows what is exciting about it! Don't think about hashes, and trees and what not. Talk about features, implications, user experience. Then, only after that, explain how this works.
it resonated, youre just expressing your envy as veiled haterade and it is pathetic my friend.
Very interesting concept! Definitely need to dive in! 👍
7:20 Wait how do you do polymorphism if when call a function you are in effect committing to an implementation by even "naming" it?
Great question, I wonder if there is some kind of hash monomorphisation.
statically-typed purely functional language, for backend
that's a good question, when Runar says "implementation" I think he's actually referring to the "definition". For example, you can define generic data types such as List, Tree, etc and be able to define them in a generic way. eg if I have a type "List a = Nil | Cons a (List a)" then I can define generic functions such as "head" that will work "in the same way" on a List Int and on a List String. My understanding is that they basically create those hashes from the Abstract Syntax Tree hence they completely get rid of the concept of "source code". It just becomes an input to the parser. Once it's parsed THEN it gets assigned a hash and that essentially depends only on definitions, not names.
The "proof" of a unit testing having been run is interesting.
16:30
I wonder if there would be some way of not needing to store the hash of the unit test definition externally (blockchain or otherwise) as a record of it having succeeded.
Something like creating a brand new definition that takes the unit test definition and success/fail result (and probably a private key for authenticity) as constant inputs. The existence of the hash of that new definition is proof it has passed (or failed), and the "compiler" and "documentation" systems know everything about it automatically. I am probably way off base, but the language internals definitely open up a lot of new ways of thinking about things :)
Great video!
I believe you can in fact do as you describe, just by saving the test result in the codebase, with the usual “add” command. And this would simply retain a reference to the hash, instead of evicting it from the cache. So you don’t _need_ to record the hash externally, but you _could_ do so, if you wanted evidence that you actually ran the tests (and when). I believe this would let you very easily implement policies like “only allow pushing a deployment to the server if all the tests passed or a developer signed off on it with their key”.
@@EvincarOfAutumn Yeah, I thought about this more, and a function/definition in the code base, as you mentioned, that returns true and some sort of id/key should do what I am thinking - at least in my mental model. Thanks.
So, what happens when I've found a bug somewhere in my code? Should I then manually change every transitive dependency, with no indication if I've missed one?... Names aren't inherently bound to the implementation - often, they denote a concept, allowing the underlying interpretation to be changed freely. If Unison lacks this aspect, I don't think it'll find practical use
I just saw Unison for the first time today, so I'm guessing that the coder would be prompted with a list of code that calls this implementation and can select which use the new version and which continue to call the old buggy one.
Pondering this further - I do wonder about this removal of names, substituting them with hashes. In this or some related video, I think I heard the suggestion that devs don't like thinking of names so it will be universally beneficial to relieve them of this burden. Now maybe they don't like thinking of names, but it does seem to have some value. Every time a piece of code is called by name, the caller thinks only of the name and not the implementation. He just assumes that say, "ListCount" will return a count of the items in the list. Equally, the name "ListCount" is a clear reminder to the implementer of what the function is meant to do.
Giving names to pieces of code is sort of like putting signposts in a new township. Once up, people can think about them and be guided by them, even request name changes etc.
As far as I can tell from the videos, names are still likely to be used in the Unison model - but they are optional extras - maybe that's a good approach. Sometimes when writing code I will write let dunnoYet = .... in the hope I will think of a good name later :)
Wow greatt concept!!! Love it
Why would anyone use this over Erlang (concurrency, distributed programming) or Ada/SPARK (security)?
Have you even seen any source code in Erlang or Ada? Honestly first impression is they make LISP seem straightforward and sensible.
@@cianmoriarty7345 Every Boeing 777 is flying since 95 with Ada from nose to tail.
Why do you think this is remotely similar?
Names don't matter : I don't think it really is a problem to solve, modern language servers are able to change all occurrences of a name using refactor features
The idea of referencing functions by their hashes removes the dependency on the language server.
Soooo… it’s basically Smalltalk but with an AST editor rather than text?
No
dont you hate when you cant just boil everything down to something you already understand (or dont understand in this case) lol
I'm fascinated by new languages like Gleam or Unison. My only problem is, that they are TOO new to really use them
There are basically no new things in Gleam and it's not running on a new platform. It's not a particularly big leap to use it.
gleam can use everything in the erlang ecosystem
Dude… I’m 12 minutes in and you’ve lost me. All these features seem very cutsie and the mainstay of old dynamic languages. Cool parlor trick that this can be pulled off with strong typing, but why do i care? What does unison do that i can’t do today? What does it do better? How does it evolve the state of the art? I may never know…
@@higaski I think he means that if you compile everything first then someone decides to change method name you don't need to change it in other places even if someone bumps dependency version of your lib their code is still using correct hash. Now this might be cute to think about but having to carry over a mini DB as source code and having to rely on parsing it all the time sounds like a waste of cpu cycles when you have IDEs for renaming across whole project for local stuff and even on upgrade dependency replace all is just fine
@@higaski But when you start thinking about it early, you can come up with those things like global universe of every version of every definition in a cool and accessible way.
"So strange, I stopped listening and now I may never know what else they have to offer"
@@JobvanderZwan i am under no obligation to listen to a bad presentation. Have new ideas? Sell them, and sell them well. I’ve spend 100+ hours learning rust because the rust community have convinced me (lots of people) that they have something to offer.
@@davidvernon3119 It was an incredible presentation.
❤❤Smalltalk❤❤
First 😍
|| tail
-- list defined
Non controversial comment: THIS IS A WASTE TIME. prove me wrong!