71–80 of 84 posts
eie.io would be an awesome domain name for this project. Too bad it's already parked by a squatter as a "premium name". (For non-native or non-Western English speakers, it's a line from the children's song "Old McDonald Had a Farm".)
Earlier quoted context omitted.
True that. We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)). My colleague took notes of the progress at https://gist.github.com/mo…
From the gist: > We have until Friday 7th September to upgrade to Elm 0.19. I'm completely ignorant about the transition, but I'm curious what the source of this deadline was. Would you mind expanding?
Earlier quoted context omitted.
True that. We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)). My colleague took notes of the progress at https://gist.github.com/mo…
Wow! Apologies if this is answered in those notes but my quick question is: Did you make extensive use of Debug.todo to cordon off sections of the app that wouldn't compile in order to work on and "see" the other sections in the meantime? That's what I do on my small elm apps, e.g. put whole features or functionality behind Debug.todos.
Earlier quoted context omitted.
There was a similar project to `go fix` with elm-upgrade ( https://github.com/avh4/elm-upgrade ). We migrated a ~100k LOC app at work from 0.18 to 0.19 and while it was tedious, the compiler really has your back and makes it easier. We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.
True that. We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)). My colleague took notes of the progress at https://gist.github.com/mo…
At our company it was much less drastic. At the time we had about 35kloc of Elm and it took me one evening of Vim macro frenzy. The trickiest things we encountered were an elm/http API change and temporarily vendoring packages that didn't yet upgrade themselves.
Earlier quoted context omitted.
I truly believe TypeScript is the only true way forward for frontend web programming. Now what we really need is a functional dialect which compiles to TypeScript...
TypeScript has a bunch of holes in it because it needs tight compatibility with JavaScript. While a pure functional style may be possible, it isn’t first-class or ergonomic or as expressive, and won't cut it for many. Are there first-class function composition infix operators? Is pattern matching algebraic data types often the easiest way to write code? Is IO managed? With a language like Elm and others in the ML fam…
Earlier quoted context omitted.
I truly believe TypeScript is the only true way forward for frontend web programming. Now what we really need is a functional dialect which compiles to TypeScript...
> Now what we really need is a functional dialect which compiles to TypeScript... Why would it be beneficial to have TS as an intermediate representation? It turns into JS anyway, and there are already statically typed functional languages that compile to JS.
Earlier quoted context omitted.
I truly believe TypeScript is the only true way forward for frontend web programming. Now what we really need is a functional dialect which compiles to TypeScript...
TypeScript or Flow for that matter sucks at using functional style with immutable data types. There are ESLint plugins that allows to enforce immutability with plain JS objects, but still lack of syntactic sugar or union types makes the experience much worse then in functional languages.
I know you're not trying to replace the official Elm compiler, but that's precisely what is needed. I really, really wanted to like Elm but the way it's managed is horrible and antithetical to the idea of Open Source software. With the current compiler I wouldn't touch Elm with a 39.5" pole, even if Elm is a joy to work with.
One's attitude towards Elm directly correlates with the degree to which one likes to dig into and tinker with the internals of their tools and frameworks and rearrange things. Unfortunately that means it's a hard sell around HN-- in a way it's antithetical to "hackers". But I don't think it's antithetical to John Carmack's proverbial "engineer"-- someone who wants to do what they can do with what they've actually got…
I am also someone who just wants to get shit done. I've never had an issue with php, c#, ruby, crystal, go, rust, haskell, erlang etc's compilers/interpreters in terms of letting me get what I want done. Yeah, I haven't actually forked or patched those compilers but neither have they been hostile to their users.
The reason I would use literally any of those except Elm is that the maintainer(s) of Elm act like they're Steve Jobs. How can I "get things done" if I'm being told "oh no, you're not allowed to do , we've decided that only us on the Elm team can do that". With other languages, I'm not worried about a version bump pulling the rug out under me, effectively trapping me in the ecosystem unless I want to rewrite everything in a different language. That is also directly the opposite of being productive and getting things done.
There is nothing about an autocratic "you're holding the compiler wrong" governance model that makes any part of a language itself more efficient or fun. Plenty of other languages are as (or more) efficient and fun as Elm, but without the patronizing and condescending attitude of "you're not as smart as us, so do as you're told, and no you can't discuss this with us". There is no way I could justify the risk of adopting elm professionally given the entire rest of the programming language world... doesn't do this. Let me be the one who decides to shoot my own foot off; even Rust (a language pitched on memory safety) allows this with unsafe, etc.
If one wants to control everything exactly and go against almost every other language and most F/OSS projects, then just... make proprietary/source-available software. F/OSS is a give-and-take, and nearly all of us have taken far more than we've given.
And I don't know what John Carmack's "proverbial engineer" is, but I think just about any engineer would prefer to be in control of their tooling and not at the whims of maintainers.
eie.io would be an awesome domain name for this project. Too bad it's already parked by a squatter as a "premium name". (For non-native or non-Western English speakers, it's a line from the children's song "Old McDonald Had a Farm".)
> EIEIO (“Enhanced Implementation of Emacs Interpreted Objects”) provides an Object Oriented layer for Emacs Lisp, following the basic concepts of the Common Lisp Object System (CLOS). It provides a framework for writing object-oriented applications in Emacs. https://www.gnu.org/software/emacs/manual/html_node/eieio/
> eieio (Enforce In-Order Execution of I/O) instruction
> Ensures that cache-inhibited storage accesses are performed in main memory in the order specified by the program.
I really would love to have this compiler have a llvm backend. I like the idea of a small FP language with amazing error messages. Haskell is too big and complex for me.
I've briefly looked at LLVM and how to interface with it but back then I didn't find much else than some C++ Builder API. I'd hope for some textual format that I could give to LLVM as an input. I assume it exists and that I've just been googling wrong :) Would definitely appreciate some pointers in that regard. Other than that my best bet for native binaries is most likely compiling to C or GraalVM (which already exi…