What's the incentive people have to combine type systems with functional programming? At least in broad strokes I think of typing and immutability (which is the goal of functional-style programming) as solving the same problem in two different ways. If you write control flow that returns values which are immutably bound lexically, what is the point of a type system?
Grain: A strongly-typed functional programming language for the modern web
71–80 of 156 posts
Re: Grain: A strongly-typed functional programming language for the modern web
#72What's the incentive people have to combine type systems with functional programming? At least in broad strokes I think of typing and immutability (which is the goal of functional-style programming) as solving the same problem in two different ways. If you write control flow that returns values which are immutably bound lexically, what is the point of a type system?
Immutability gives guarantees at runtime, a type system gives guarantees at compile time. Or, from a different perspective, immutability guarantees a certain property – the value – of an item, while a type system guarantees different properties for all items of a type. Those two concerns are mostly orthogonal to each other.
Re: Grain: A strongly-typed functional programming language for the modern web
#73Earlier quoted context omitted.
But JS programs must execute in uncontrolled environments, e.g. browser engines from the past and future with random extensions installed. A bondage-and-discipline language may help developers find logic bugs, but will make the users' experiences worse.
How is "there was a JavaScript error on this page" informational icon any worse than an order total of "undefined" or that the page just doesn't seem to be reacting to clicks? I'd argue that the former is much better UX -- at least the user isn't confused whether it's them that's doing something wrong or it's the page that just shoddily implemented.
> at least the user isn't confused whether it's them that's doing something wrong or it's the page that just shoddily implemented
Users generally ignore all messages coming from their computers. They routinely blame their computers for doing things that the computers are not doing at all. Like, oh I can’t find the document I wrote three weeks ago -> obviously my computer is being disobedient.
Anyway, I don’t blame the users. To them the computer is entirely uninteresting and they don’t want to care about the sorts of concerns that we technically minded people do.
A broken page is a broken page and it doesn’t matter to the user why the page is broken. The only thing that matters to them is, can they do the thing they wanted to do or not. And like the sibling said, the web browsers are surprisingly good at handling broken code.
Re: Grain: A strongly-typed functional programming language for the modern web
#74This is just a prototypal IDEA right?
motivation? benchmark? demo? build system?
Re: Grain: A strongly-typed functional programming language for the modern web
#75Since it's pretty ML-flavored, a comparison with Reason [1] would be nice.
I see compiling to WASM as the key differentiator now. This likely means that all the mechanics required for an ML-style language, like garbage collection, must be included in a runtime library.
Re: Grain: A strongly-typed functional programming language for the modern web
#76Since it's pretty ML-flavored, a comparison with Reason [1] would be nice. I see compiling to WASM as the key differentiator now. This likely means that all the mechanics required for an ML-style language, like garbage collection, must be included in a runtime library. [1]: https://reasonml.github.io/
Only until the WebAssembly spec included access to the host GC:
>>> there's already a very efficient, solidly tested, constantly improving garbage collector in your browser that uses all the possible dirty low-level tricks known to mankind, which is the GC being used for JavaScript. What if we could give you access to the garbage collector directly?
https://blog.benj.me/2018/07/04/mozilla-2018-faster-calls-an...
Re: Grain: A strongly-typed functional programming language for the modern web
#77The main page doesn't do a great job of showing what's interesting about Grain vs. JavaScript. The only hint is this: "No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations." Maybe show some examples of errors Grain would catch that JavaScript wouldn't, like Elm does: http://elm-lang.org/
> No runtime exceptions, ever. This is something I wonder about JS: there are a lot of places that exceptions happen in (say) Python that just return `NaN` or `undefined` in javascript. Is it intentional? Is it a good idea? Examples: the multiplication operator essentially never throws. Out-of-bounds (or "not found") lookups don't throw. I suspect the logic is "only throw if you have the wrong type for that operation…
It's generally better to highlight the existence of an error condition sooner rather than later.
Compile time is better than runtime, evaluation time is better than via explicit value inspection.
Non-signalling NaNs provide an easy way of distributing an invalid value widely throughout a program's data structures before it's discovered.
The only reason to go the other way, and have silent NaN propagation, is if they're expected to occur very frequently. For example, consider how awkward SQL would be if evaluating over null values triggered errors - the conditionality of expressions would need to become very elaborate.
Monadic approaches to errors (Maybe, Rust's Result, that conditionally apply a function to a value only if it's not an error) blur the line between these two. Because they rely on data flow, they feel a bit like non-signalling NaNs. OTOH, evaluation generally bubbles up using monadic return types, and errors bubble up too, just like exceptions - exceptions, and consistent, universal use of monadic return types, are isomorphic and can have the same evaluation characteristics.
Re: Grain: A strongly-typed functional programming language for the modern web
#78I'd hope this is indicative of wasm precipitating a wave of creativity. From a purely technical point of view I actually don't care. Elm is fast, complete, elegant and has perhaps the most user-friendly compiler on the planet. The fact it happens to target js and not wasm (at this point) is practically irrelevant.
I can see, though, that wasm might encourage experimentation by a wider group of people who are put off by targetting js.
Coming back to Elm, it'd be great to see others consider the wider architectural questions. The Elm architecture and language are beautifully complementary. That's stark when looking at react - which was copied from (or at least inspired by) the Elm architecture. However, being js-based, it doesn't have the mutual consistency of elm - and so has to resort to syntactic gymnastics.
Anyway, that's getting off topic. Grain is clearly early stage. Anyone motivated enough to conceive and deliver a language deserves some encouragement. Will be interesting to see how it evolves.
Re: Grain: A strongly-typed functional programming language for the modern web
#79How does Grain prevent bottom with static type checking? Totality is undecidable in Turing complete languages, so “no runtime errors” is probably false (maybe they “solved” the halting problem?).