31–38 of 38 posts
Earlier quoted context omitted.
I've programmed COBOL for a living back when it was still fashionable and I don't think it looks like COBOL at all, what specifically triggers your 'looks like' bit?
The separate sections for data definitions, forms, etc.
So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…
Some quick notes:
[0] Idris compiles to C, Java, and JavaScript, but is considered experimental.
[1] Frege compiles to Java, and seems to have fairly nice Java interop. It may be possible to target iOS via RoboVM [2], and the browser via GWT [3].
I've yet to really dig into either of them yet, so I can't claim any level of confidence.
My current best hope is that GHC's ARM support will become mature enough someday before Sol goes supernova. (Or at least before the effective heat-death of the universe.)
(I'm still learning Haskell and kin, so I can't be of much help yet.)
[1] http://frege-lang.org (appears to be down ATM)
Earlier quoted context omitted.
I, too, really love Elm, and have worked on some tooling for getting it running on the server. (Self promotion ahead). I wrote an NPM module for compiling and loading Elm[1], and also put together a more comprehensive project for scaffolding an Express application to communicate between Elm in the browser and Elm on the server, via ports (this is the first time I announce it anywhere, since I want to have some full e…
Interesting. So basically Reactive Haskell right inside the NodeJS. Did you able to run any performance test yet? I'm interested to learn more about this.
This is a working example of the Pong example from the Elm website: https://github.com/sonnym/elm-expressway_pong
I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right. ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way boun…
1. How much is the language going to help you independently arrive at nice architecture? It took millions of people 20 years to arrive at this pattern in JS, and it literally happens in every Elm program out there automatically. The pattern described in "The Elm Architecture" really does come from looking at people's Elm code and seeing the naturally arising patterns. So new people don't need to read this post and learn these concepts, commercial users don't need to have strict discipline, the architecture just comes out this way.
2. How much is the language going to fight you or help you when you already know what you want to do? In particular, ADTs are a key part of why this is so nice in Elm, and when you are working in JS or TypeScript, writing "the same code" leads to code that can be quite awful. Even when you know why you want it, it often does not seem worthwhile to fake ADTs. Immutability is another key aspect that's hard to get in many languages. I'll write more about this in some future post, but I think lack of side-effects is another key aspect of keeping the architecture nice.
3. How much is a language going to help a team of 20 keep this up in a large code base? Will the intern or the new hire be able to do it right? Once you start to get cracks, do they continue to grow? If you lack a module system or a type system, are you going to start running into other scaling problems? In this setting, having tools that guide you to the right answer is extremely valuable.
So I think language matters a lot, but I would :P
My experience with Elm was that it's very elegant and fun to work with if you are building a purely clientside application, but once you need communication with server the APIs are not very well developed and it becomes a major headache. Note that none of the examples in this page (or in any Elm tutorial I found) flesh out interaction with a backend.
It this problem bad enough that you would consider it to be a deal breaker? Can't one shell out to JS for the pain points?
The TodoMVC example in Elm does this to use localStorage: https://github.com/evancz/elm-todomvc/blob/master/Todo.elm#L... and https://github.com/evancz/elm-todomvc/blob/master/index.html...
The same can be done for HTTP or WebSockets if you have needs that are not met by the existing APIs. Furthermore, the next major release is focused on drastically improving these APIs.
So there's a safety valve right now and there's a plan of how to make things excellent. I would not block on this, but I am also relatively biased :)
Some things that would interest me but which I couldn't figure out from these docs are:
1. Will sending something to a Channel or the DOM event that causes the send to the channel (e.g. onClick (send channel Decrement) in the example) be executed synchronously (aka direct function calls in the transpiled JS) or asynchronously (signal processing in the subscriber is deferred, e.g. with settimeout). If it's deferred, can it really be guaranteed that for example a button could only be pressed once (with direct calls you could disable it immediatly in the onClick listener) or other actions which you might want to see immediatly?
2. Are there any concepts around cancellation? E.g. in one other example there was a textbox whose text-changed signal triggered the downloading of images which were shown in another view. There old pictures were still shown despite the input has changed already again because they are in the HTTP response signal at some point of time. I guess you would have to create and map a new HTTP signal each time the input change and disconnect the old one. But this seems like against the proposed architecture.
I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right. ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way boun…
I think the core ideas can be used in many settings, that is true. One can use a pattern like this in C if they want. I think there are a couple questions to consider when asking "how does language really help?" 1. How much is the language going to help you independently arrive at nice architecture? It took millions of people 20 years to arrive at this pattern in JS, and it literally happens in every Elm program out…
I appreciate the practical lens with which you've described how the language can influence code. Many language geeks far too often remain too abstract about how a craftsman programmer's life can be improved by the language's design.
ADTs stood out as something I'd love to have in my day-to-do programming toolbet during my short tryst with Haskell. But I was unable to articulate the concrete improvements it can bring into my code, and so it has unfortunately remained a hunch. I eagerly look forward to your post about ADT in the context of Elm and UI programming.
So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…
It's killing me that there isn't a good enough solution to this right now. Some quick notes: [0] Idris compiles to C, Java, and JavaScript, but is considered experimental. [1] Frege compiles to Java, and seems to have fairly nice Java interop. It may be possible to target iOS via RoboVM [2], and the browser via GWT [3]. I've yet to really dig into either of them yet, so I can't claim any level of confidence. My curre…