4 ms·

There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats

There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats-cool-about-unison/

grawprog 5y ago
Thank you, that helped explain pretty well what abilities are. I felt like I was kind of starting to get what the language was about, then I hit the abilities section and I had no idea what it was talking about.
PaulDavisThe1st 5y ago
Good explanations, but I'm always a little suspicious when I see things like this: > Code is stored as a structured, type-checked tree in a database, not as text in files What does everyone think a filesystem is?
- thethimble 5y ago
  There’s an important distinction between how non-unison code is stored (literally as plain text files which must be re-parsed and re-compiled every time) vs how unison code is stored (as a post-parsing data structure). The file system is in an entirely different and irrelevant layer of abstraction.
  - turtletontine 5y ago
    I'm not totally sure what the important distinction is here. For many languages the important thing is already a post-parsing data structure, that's what any compilation output or byte code is. You obviously want to keep the raw source around as well if you're the developer. Nothing new about having separate source code and compiled formats?
    - turtletontine 5y ago
      Update: I'm skimming here (https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats-cool-about-unison/) and here (https://joshondesign.com/2012/04/09/open-letter-language-designers https://joshondesign.com/2012/04/09/open-letter-language-des...) and I see Unison is serious about not having raw text source code as the ground truth. I'm intrigued but don't totally understand yet. I'm sure this analogy is technically incorrect but: This reminds me of Smalltalk and old Lisps on mainframes shared by many researchers where the main thing was the VM image, not an object file. Though the probably kept the source code around? At a gut level getting rid of source code makes me uncomfortable but I'm ready to learn more. PS sorry for the ugly raw links I'm on my phone
      - jack_h 5y ago
        Perhaps see my reply here (https://news.ycombinator.com/item?id=27654225 https://news.ycombinator.com/item?id=27654225). I think you may be misunderstanding what is being stored here. Now as a caveat I'm not familiar with this language, but I am familiar with the concept as described. They are not removing source code, rather source code is stored after some processing; in this case it appears to be after lexing, parsing, and type checking. I'm not sure exactly what is being stored, i.e. an AST, but it sounds like they're basically moving this stage of compilation/interpretation to be much earlier in the process. I'm assuming this database can be queried and the result can be rendered back to a textual presentation as well. Presumably this opens the door for syntax being divorced from language semantics since how the syntax is parsed into the database and how the database is rendered into text can be a client side decision rather than set in stone inside the compiler/interpreter. What is set in stone is the semantics of the database that everyone must agree to. Again, there's the caveat that I'm not familiar with how this language in particular is implementing this concept.
- jack_h 5y ago
  I'm not sure I understand your question. Could you elaborate?
  - fouc 5y ago
    He's alluding to the fact that filesystems are a kind of database for files.
    - vanderZwan 5y ago
      I wouldn't exactly consider files "type-checked" though
jack_h 5y ago
Storing code in a database is super cool stuff and is something I've been thinking about for a number of years. I'm actually surprised this development hasn't happened sooner since basically all tooling is forced to deal with the limitations of storing source code as text. The article gives an example that most programmers would be familiar with; canonicalization so that version control and code reviews go smoothly. Version control also becomes somewhat simpler as it can compare the structure of code rather than the structure of a sequence of characters that still must be lexed, parsed, etc. There are lots of other areas where storing code in a structured database of some sort would benefit tooling as well. One example is the use of language servers to index, perform continuous recompilation, perform cross-reference lookups, and offer code completion. With a structured database a lot of this becomes relatively trivial. I'll definitely have to look into this language further as I'm curious about how their database is designed.

There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats-cool-about-unison/

grawprog 5y ago

Thank you, that helped explain pretty well what abilities are. I felt like I was kind of starting to get what the language was about, then I hit the abilities section and I had no idea what it was talking about.

PaulDavisThe1st 5y ago

Good explanations, but I'm always a little suspicious when I see things like this: > Code is stored as a structured, type-checked tree in a database, not as text in files What does everyone think a filesystem is?

thethimble 5y ago
There’s an important distinction between how non-unison code is stored (literally as plain text files which must be re-parsed and re-compiled every time) vs how unison code is stored (as a post-parsing data structure). The file system is in an entirely different and irrelevant layer of abstraction.
- turtletontine 5y ago
  I'm not totally sure what the important distinction is here. For many languages the important thing is already a post-parsing data structure, that's what any compilation output or byte code is. You obviously want to keep the raw source around as well if you're the developer. Nothing new about having separate source code and compiled formats?
  - turtletontine 5y ago
    Update: I'm skimming here (https://jaredforsyth.com/posts/whats-cool-about-unison/ https://jaredforsyth.com/posts/whats-cool-about-unison/) and here (https://joshondesign.com/2012/04/09/open-letter-language-designers https://joshondesign.com/2012/04/09/open-letter-language-des...) and I see Unison is serious about not having raw text source code as the ground truth. I'm intrigued but don't totally understand yet. I'm sure this analogy is technically incorrect but: This reminds me of Smalltalk and old Lisps on mainframes shared by many researchers where the main thing was the VM image, not an object file. Though the probably kept the source code around? At a gut level getting rid of source code makes me uncomfortable but I'm ready to learn more. PS sorry for the ugly raw links I'm on my phone
    - jack_h 5y ago
      Perhaps see my reply here (https://news.ycombinator.com/item?id=27654225 https://news.ycombinator.com/item?id=27654225). I think you may be misunderstanding what is being stored here. Now as a caveat I'm not familiar with this language, but I am familiar with the concept as described. They are not removing source code, rather source code is stored after some processing; in this case it appears to be after lexing, parsing, and type checking. I'm not sure exactly what is being stored, i.e. an AST, but it sounds like they're basically moving this stage of compilation/interpretation to be much earlier in the process. I'm assuming this database can be queried and the result can be rendered back to a textual presentation as well. Presumably this opens the door for syntax being divorced from language semantics since how the syntax is parsed into the database and how the database is rendered into text can be a client side decision rather than set in stone inside the compiler/interpreter. What is set in stone is the semantics of the database that everyone must agree to. Again, there's the caveat that I'm not familiar with how this language in particular is implementing this concept.
jack_h 5y ago
I'm not sure I understand your question. Could you elaborate?
- fouc 5y ago
  He's alluding to the fact that filesystems are a kind of database for files.
  - vanderZwan 5y ago
    I wouldn't exactly consider files "type-checked" though

jack_h 5y ago

Storing code in a database is super cool stuff and is something I've been thinking about for a number of years. I'm actually surprised this development hasn't happened sooner since basically all tooling is forced to deal with the limitations of storing source code as text. The article gives an example that most programmers would be familiar with; canonicalization so that version control and code reviews go smoothly. Version control also becomes somewhat simpler as it can compare the structure of code rather than the structure of a sequence of characters that still must be lexed, parsed, etc. There are lots of other areas where storing code in a structured database of some sort would benefit tooling as well. One example is the use of language servers to index, perform continuous recompilation, perform cross-reference lookups, and offer code completion. With a structured database a lot of this becomes relatively trivial. I'll definitely have to look into this language further as I'm curious about how their database is designed.