Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IBM releases Elm-powered app

discourse.elm-lang.org

Post reply on HN
Print view View original

101–110 of 199 posts

Re: IBM releases Elm-powered app

#101

Post by k_bx »

hellofunk wrote: post #99

Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of…

- no runtime errors guaranteed (in the Elm code)

- the ones you do get from your JS code – will be shown as console errors not involving Elm runtime in their stack trace

- guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies), side-effects and JS FFI?

- better dead code elimination. All the code in Elm is pure

Basically, OCaml brings almost nothing to the table out of things Elm provides because it tries to suit everybody.

Re: IBM releases Elm-powered app

#102

Post by k_bx »

savanaly wrote: post #8

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. That's one of the largest (and apparently most useful) Elm apps in the wild that I've heard of, and the fact that it exists and they had an overall good experience with it inspires me even more to try to learn and use Elm.

Elm code is hard to measure because you encode HTML in Elm as well. I'm currently working on a form which takes 1.5K code in just one module. But there's a lot of HTML generated :)

Re: IBM releases Elm-powered app

#103

Post by hellofunk »

k_bx wrote: post #101
hellofunk wrote: post #99

Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of…

- no runtime errors guaranteed (in the Elm code) - the ones you do get from your JS code – will be shown as console errors not involving Elm runtime in their stack trace - guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies), side-effects and JS FFI? - better dead code elimination. All the code in Elm is pure B…

> guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies) and JS FFI?

The ReasonML debugger supports time-travelling as one of its features.

The Bucklescript compiler that backs ReasonML provides dead-code elimination.

Re: IBM releases Elm-powered app

#104

Post by aaaaaaass »

hellofunk wrote: post #98
davidgrenier wrote: post #84

Earlier quoted context omitted.

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…

30K lines of Clojurescript is so enormous on an epic scale. I think that even the most liberal estimate on line count would be half what you typically find in Elm.

yeah because no types

Re: IBM releases Elm-powered app

#105

Post by k_bx »

hellofunk wrote: post #103
k_bx wrote: post #101

Earlier quoted context omitted.

- no runtime errors guaranteed (in the Elm code) - the ones you do get from your JS code – will be shown as console errors not involving Elm runtime in their stack trace - guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies), side-effects and JS FFI? - better dead code elimination. All the code in Elm is pure B…

> guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies) and JS FFI? The ReasonML debugger supports time-travelling as one of its features. The Bucklescript compiler that backs ReasonML provides dead-code elimination.

> 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 link, but Todo app in Elm weights less than the one made in React, that's how good it is.

Re: IBM releases Elm-powered app

#106

Post by deltron3030 »

the_gipsy wrote: post #77
deltron3030 wrote: post #66

Earlier quoted context omitted.

isn't Storyboard based on components (parts) first (atomic design)? Elm is the opposite, it's focused on the whole which you then use as the basis for parts at actual design time (thinking about layout and hierarchy). So in a way Elm is about form following function (creating visuals from existing functionality), while most of the other environments are focused on function following form instead (creating functionali…

You can perfectly do the design-first process with Elm, I thought you were maybe accustomed to Storyboard or something like that. IMHO you can do design-first process with Elm just like with React. There is no Storyboard equivalent that I'm aware of, but I never found it useful enough but maybe it is, for toolkit/library designers. I have found that I work differently depending on environment. I do model/types/functi…

>I have found that I work differently depending on environment.

That's the best way to handle this I think. I didn't mean that you can't do specific workflows in either framework or language, just that there is a "native ideal way" of how things are done.

Philosophically it's an interesting topic, because there are many arguments for and against either method. It's also way bigger than programming, it's about evolution itself.

Re: IBM releases Elm-powered app

#107

Post by k_bx »

StreamBright wrote: post #52
yakshaving_jgt wrote: post #40

> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous." Like, what's the alternative? More JavaScript?

Have you seen ReasonML? [@bs.val] external pi : float = "Math.PI"; let tau = pi *. 2.0; [@bs.val] external alert : string => unit = "alert"; alert("hello"); Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language. Clojure is so popular because you have access to most of Java and the libraries written in Java. ReasonML makes super easy to use JS (or other lang…

> Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language.

Your code will produce runtime errors which will be rendered into console with ReasonML runtime guts in it. I would disagree that this is in any way superior to Elm's promise of no runtime errors, and JS via ports having no runtime in its errors.

Re: IBM releases Elm-powered app

#108

Post by dkersten »

haskman wrote: post #70
_0w8t wrote: post #62

Earlier quoted context omitted.

What is nicer to test and maintain? To test render() in the clicked state with the explicit state I can call it with the corresponding state. With the implicit state at the very least I have to write a driver to run render() into the clicked state and then test the next state transition. To understand the effects of the code on other parts of the application with the explicit state it is sufficient to look at the def…

Testing could be much easier for the implicit state version. I've not defined it, but you are assuming things about how the render function or the implicit state behaves. In my hypothetical implicit state framework - A widget is composed of a sequence of steps, each of which is an independent widget. So it's easy to write invariant properties for each step - For (text "String") it's guaranteed that the widget never r…

The explicit version we can understand how it works just by looking at it. The implicit version we need knowledge about how your hypothetical framework works.

Re: IBM releases Elm-powered app

#109

Post by dkersten »

giornogiovanna wrote: post #29
fxfan wrote: post #25

Anybody who liked elm is highly recommended to check out Scala.js. With scalatags, it looks close to what elm does AND you have the entire power of jvm libs. And you get code sharing across client and server as its just plain old scala. I believe elm is not big server side.

Scalatags is not a VDOM implementation, though, and the Elm architecture (one giant state machine) is very different to what you'd typically see in a Scala.js application. A closer analog, in my opinion, would be ClojureScript + Reagent, but even that doesn't feature Elm's focus around immutability.

Clojuresxript + re-frame would be pretty close though, right?

Re: IBM releases Elm-powered app

#110

Post by elbear »

StreamBright wrote: post #73
yakshaving_jgt wrote: post #58

Earlier quoted context omitted.

I do not agree that it is "always a bad idea". That is why I use Elm, and not some other compile-to-JS language that allows me more freedom. I don't want freedom. I want constraints. Freedom is the rope with which I can hang myself. Constraints keep my bug tracker silent.

Most of the people want freedom and not some North Korean style crap. The example I gave was explicitly displaying how it is possible to use something from JS on a type safe way. Not sure how could you hang yourself with that. I guess you are just very creative.

What happens if you call in your ReasonML code a JS function that throws an exception?
Post reply on HN