helloWorld : '{IO, Exception} ()
helloWorld _ = printLine "Hello World"
I wouldn't call it friendly.
this post was submitted on 16 Dec 2023
67 points (85.3% liked)
Programming
17313 readers
306 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
Oh, it's weird ugly Haskell!
... I can write weird, ugly Haskell in Haskell, though.
Compiler, give me all the language extensions you have. Wait, wait. I'm worried what you just heard was, "Give me a lot of language extensions." What I said was, "Give me all the language extensions you have." Do you understand?
Literally the opposite of friendly. Already in the hello world you have two imports for extremely basic functionality (why should I have to import the ability to throw exceptions??) and a completely enigmatic symbol ' that apparently has a significant function.
A "friendly" programming language should be readable without knowing esoteric symbols.
Really got my hopes up with that headline that it'd be a python-level intuitive-to-read language with static typing.
What you expected sounds more like what nim offers.
python-level intuitive-to-read language with static typing
Agreed, this is exactly Nim
Thanks I'll check it out
There are no imports, these are type annotations
Do I really have to declare that something requires exceptions?
Yes, in functional programming you want to use pure functions. Exceptions are impure, therefore it has to be declared.
Other functional languages don't even have exceptions
I'm surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).
I'm currently learning functional languages and have only limited knowledge, but from what I've read now you are right. Throwing exceptions is pure, but catching them is impure.
In this case I guess the printLine function can throw an exception therefore the calling function must be declared with Exception?
I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it's only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.
Sounds good,
but would the preferred way be to use a wrapper type, which holds either the data or the error and avoid exceptions completely?
Pure functions should be referentially transparent; you should be able to replace them with whatever value they evaluate to without changing the semantics of your code.
Throwing is referentially impure: what value do you get from calling x => throw new RuntimeException()?
Instead, functional languages prefer to return a tagged union of the value or the error.
That's one of the things I appreciate in a language/framework. Drives me nuts getting an exception from a dependency of a dependency of a dependency.
Even better if its baked into the type system and I can't run my code without handling it.
Functional languages typically have type inference, so the type signatures are entirely optional. I haven't looked that deeply at unison, but I'd be entirely unsurprised if it had global type inference and if all or most type signatures were optimal.
It's less that you have to declare something can do IO or throw an exception, and more that you're calling something from the standard library that does IO or throws an exception.
Most stuff does neither. There's a type level distinction between normal, regular pure code, and impure effectful code, so it's easy to tell from the type signature whether a function is pure or not.
This looks like the opposite of friendly to me. Is it supposed to be targeted towards cloud computing or web apps? I don’t really understand what its ideal use case is.
V disappointed upon realizing this is not, as I initially read, satirically-typed
Time for a Java fork: Jaja
Unison stores code in a database.
🫣🤨
There take on what they call capabitilites is very interesting. Basically anything that would make a function non-pure seems to be declared explicitely.
A computational effect or an "effectful" computation is one which relies on or changes elements that are outside of its immediate environment. Some examples of effectful actions that a function might take are:
- writing to a database
- throwing an exception
- making a network call
- getting a random number
- altering a global variable
The distributed computing aspect is very interesting, but the documentation is a mess. I applaud trying to use different and understandable terms than Haskell and other functional languages (monad, monoids, functors, applicative functor, etc.), but the examples are too verbose.
Concerning distributed computing, writing code that seemingly has no boundaries would be a major step forward for web development. Having to split models between client and server, come up with an API that follows some convention, find a solution for client-library generation, and so much more, is tedious, repetitive, and error-prone. Having most of that handled and having blurred boundaries would make writing web applications pleasurable again.
At the moment, unison looks like an iteration on the right path, but there is a lot of work to do in making it accessible and understandable.
As a F# lover I really want to see Unison take off
"Capabilities" is the new "Functional Programming" of decades prior,
Scala is also expanding in this area via the Caprese project: https://docs.scala-lang.org/scala3/reference/experimental/cc.html and it promises Safe Exceptions, Safe Nullability, Safe Asynchronicity in direct style/without the "what color is your function" dilemma, delineation of pure vs impure functions, … even Rust's borrow checker (and memory guarantees) becomes a special case of Capabilities.
I believe this is a major paradigm shift, but the ergonomics have yet to be figured out and be battle-tested in the real world. Ultimately, like for Functional Programming Languages (OCaml, F#, Haskell, …) I don't expect pionniers like Unison/Koka/Scala to ever become mainstream, but the "good parts" to be ported to ever the more complex and clunky "general purpose" programming languages (or, why I love Scala which is multiparadigm and still very thin/clean at its core).
It's not really fair to state that functional languages aren't battle tested or imply they aren't useful in real world problem solving, Erlang/Elixir prove that.
functional languages aren’t battle tested or imply they aren’t useful in real world problem solving
Yup, I never said that, though? What I was about was to draw a parallel between functional programming languages and explorations from several decades ago vs the new languages and explorations going into effect typing/capabilities programming now (and the long way ahead for those).
What I find interesting is that those pioneering FP languages never came to top the popularity chart, implying that I'm not expecting Unison to be different (but the good parts might make it into Java/C#/Python/… many years from now).
All good, that was just how your comment read to me.
Sorry if it came that way :)
I think that when it comes to functional programming with effect systems, unison is currently the closest to showing how it is actually done. Koka and languages like Effekt are of course very nice, but they don't show much going for them besides the example nondeterminism and exception effect. Verse, that language that was going to be used as Fortnite's scripting language, also plans on adding these effect systems a la Koka.
Overall, I think one of 2 things will happen:
- unison will slowly gain more and more adoption and grow out to become a formidable niche language
- Verse will blow unison out of the water and everyone who once even considered unison will be moving to Verse instead
unison is currently the closest to showing how it is actually done
What makes you say that? As far as I'm aware, even the theoretical soundness of it isn't a done deal (this is a harder nut to crack than e.g. rust's borrow checker)
Overall, I think one of 2 things will happen:
In this niche, perhaps, I don't believe any of those will gain mainstream adoption (though I hope I'm wrong)
Looks intriguing, reading a bit ... some concepts look like they came from Nix
This hurts my eyes to look at
Some of the solutions it claims to provide would be genuinely great. I can't tell if it delivers. It definitely looks pre-alpha stage. I really hope it's not locked-in to their cloud platform.
I tried to get into this language about 6 months ago and lets just say it was pure pain. Trying to make anything simple for learning was just a mess. Nearly no support from editors(Apart from VSCode but that does not count). And Documentation was overwhelming. It may be useful in some cases but due to its sheer complexity(I did not even managed to create a simple calculator) i dont think it would a big language.
Edit: typos
That looks like line noise to me, but then again you get over syntax pretty quickly.
Bruh this looks like gibberish ong