IBM releases Elm-powered app

Post by k_bx » Thu, Jan 10, 2019, 4:04 PM UTC

salimmadjd wrote: post #127

k_bx wrote: post #105

Earlier quoted context omitted.

> The ReasonML debugger supports time-travelling as one of its features. Yes, but the question is: does it guarantee to be working or is it only "sort of" working? Can your view do side-effects? Can it call JS? If yes -- it will break soon. > The Bucklescript compiler that backs ReasonML provides dead-code elimination. I didn't say it doesn't. I said it will be way more poor than the one Elm has. I don't have the lin…

Interesting since OP says time-traveling is not mature in ELM Tooling isn’t mature. IDE plugins, time travel “debugger” : they cannot compare yet with our usual Dev XP for TS

Post by yakshaving_jgt » Thu, Jan 10, 2019, 4:12 PM UTC

gothy wrote: post #126

yakshaving_jgt wrote: post #89

Earlier quoted context omitted.

> If you'd like to, why not? It's up to you. You're not forced to do, though. Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.

> Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project. Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want.…

Post by yogthos » Thu, Jan 10, 2019, 4:30 PM UTC

davidgrenier wrote: post #84

hellofunk wrote: post #72

Earlier quoted context omitted.

> In a comment below the main post they say that the app they wrote is approximately 45,000 lines of code over 170 Elm files. One thing I've found a bit weird about the Elm community is how common it is to highlight or even brag about the size of the codebases. One of the reasons I have come to particularly enjoy Clojurescript on the front-end is because of how much code I don't have to write. I once ported an Elm ap…

I think you should read this as being an otherwise 150kloc project in Java. Seriously, at this point IBM should fork a couple hundred thousand dollars just to know how anyone on their staff can recreate this in idiomatic java (or whatever OO language they want) and have you do it in idiomatic clojure/script. I'd be surprised if you managed less than 30k and very surprised if the OO implementation managed less than 10…

Post by yogthos » Thu, Jan 10, 2019, 4:38 PM UTC

ltbarcly3 wrote: post #2

I don't understand why this is noteworthy. I think maybe this is when you decide 'maybe our language has failed'. Or at least admit it's a toy language that hasn't been properly engineered to be effectively used commercially. When it's a 'worth mentioning' when a single app has been written in it by some dying company. I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Ja…

Post by yakshaving_jgt » Thu, Jan 10, 2019, 4:44 PM UTC

yogthos wrote: post #136

yakshaving_jgt wrote: post #96

Earlier quoted context omitted.

That’s not how I feel about it. I’d say it’s more “look how many lines of code there are vs how many ways this could break in production”. This will always be very different from your average ClojureScript/Reframe/Reagent app, which may or may not have fewer lines of code (in my experience they’ve been roughly equivalent), but vastly more opportunity for runtime errors.

ClojureScript will have quite a bit less code in a non-trivial project https://medium.freecodecamp.org/a-real-world-comparison-of-f... Meanwhile, my team has been working with ClojureScript for years, and runtime errors are a really rare occurrence in my experience. Especially if you use Schema or Spec around the API between components.