wheatBread
Joined 15 years ago
Karma
800
Submissions
65
Member since
Dec 7
Recent submissions
Comment · 26 days ago
Elm is on a faster release cycle now, and 0.19.3 is out today. The post also has a rough roadmap of what to expect for the next few Elm releases.
Comment · 1 month ago
This post is about one of my favorite aspects of the Acadia compiler, symbolic evaluation.
The compiler evaluates queries as much as possible at compile-time, so it is able to reduce `case` expressions, `let` expressions, etc. One neat outcome of this is that large expressions can sometimes be fully evaluated at compile-time, so they end up having no runtime cost at all!
I like this feature because it also only works because the query language is not Turing Complete. The design choices described in https://acadia.engineering/blog/solving-the-1-plus-N-query-p... that avoids 1+N patterns, also guarantees that queries terminate. This means they terminate whether you run them at runtime or at compile-time!
Anyway, the post also has an example app that uses https://github.com/acadia-engineering/elm-simple-server to run Elm code on the server, so maybe that is interesting as well.
Comment · 8 years ago
I updated the official guide (https://guide.elm-lang.org/) to try to do a better job at that. It covers "routing" and JS interop much more clearly I think. So I recommend starting there and then asking around in the community if you run into anything!
Comment · 10 years ago
It "scales well" because of shouldComponentUpdate. That lets you avoid building huge chunks of virtual DOM as your app becomes very large.
The trick is that the same exact optimization is available in Elm and Angular 2 (with different names) so the same argument applies there as well.
The "Do these results generalize?" section makes an argument as to why the numbers you see on a simple TodoMVC app should generalize to apps of any size. When everyone has the equivalent of shouldComponentUpdate, the question becomes: when you finally DO need an update, how fast is it? That can be measured in small apps.
Comment · 10 years ago
I think it is worthwhile stopping by the Elm slack channel to ask this. You have framed the question in a weird way. The answer is kind of "these things are not really related in any direct way" but I feel like you are asking a different question. Point is, ask on the slack channel and folks will help clarify :)
Comment · 10 years ago
Definitely not ignoring. I talk about the relation between Elm and that sort of stuff in https://youtu.be/Agu6jipKfYw Lots of things look similar in this area that are not.
I also offer an analysis of "higher order" observables in https://youtu.be/DfLvDFxcAIA, and the big difference is the underlying thread architecture you get using these two.
I hope I'll be able to make these sorts of things clearer in time!
Comment · 10 years ago
They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what?
So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
Comment · 11 years ago
That's Standard ML for you ^
I'm excited that Haskell could bring more developers to ML-family languages.
Comment · 11 years ago
You need a garbage collector either way, so doing one implies you have pretty much succeeded at the other. So it's like two stepping stones that are right next to each other and quite a long jump away :P I think we'll get there though!
Comment · 11 years ago
I think so! I'd like to get Elm running way faster than JS in browsers (which is possible thanks to some design choices) and that'd involve getting all this together. That opens things up on lots of different platforms, including servers. I also expect the next release to make things nicer on node.js as a first step in this direction. Point is, I think we'll start seeing folks doing server stuff, and it's a goal of mine to generate machine code for lots of reasons! It's a big project so I'm not setting a timeline at this point though.
Also, thanks for taking a look at Elm! I think of it as a member of "the ML-family" of languages and I draw from a lot of lessons from working with these tools and seeing what issues have come up for other folks, both within the typed functional world and not.
Comment · 11 years ago
You can do stuff in JS really easily with [ports](http://elm-lang.org/learn/Ports.elm).
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 :)
Comment · 11 years ago
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 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