Live data from Hacker News

IBM releases Elm-powered app

discourse.elm-lang.org

91–100 of 199 posts

Re: IBM releases Elm-powered app

#91
post #65

Earlier quoted context omitted.

> Functional languages are great toys but nobody uses them to get work done, almost without exception. I run my own businesses on functional programming languages (Haskell and Elm) almost exclusively. 100% of my income comes from the three software products I own, all primarily written in Haskell. You're displaying a pretty amazing level of ignorance here.

That sounds really interesting! What's the market/domain of your software product?

I'd say the products themselves are fairly uninteresting :)

NewBusinessMonitor[0] is a tool for marketing your products/services to businesses in the UK. This company is a bootstrapped SaaS, built and run by just me. It's been taking money for over a year.

Comparestack[1] is a price comparison platform. Our first product is Moneygains[2] — a way for residents of Northern Ireland to switch to a better deal on their home electricity. I'm building this with a partner — he's taking care of all the business stuff.

I have a third in the reinsurance space, and it has taken funding. I'm not going to talk about this one so much for the time being — it's still in stealth mode.

[0]: https://newbusinessmonitor.co.uk/

[1]: https://comparestack.com/

[2]: https://moneygains.co.uk/

Re: IBM releases Elm-powered app

#92
post #54
post #50

Elm is fascinating since it shows that with the right architecture functional programming for GUI is possible without hatches like monads or hiding state in closures or green thread stacks. Another things is that in Elm the state of the whole application is very visible. Typically just by looking at data structures and message types one gets how things work. The code just fills details.

I understand what you are saying, but - the whole point of abstractions is to "hide state". For example, what is nicer to write/read? Pseudocode - // Stateful state = {buttonClicked: false} render() { if(!state.buttonClicked) { return button({text: "Click Me", onClick: {state.buttonClicked=true}}) } else { return text("Thanks!") } } vs. // Implicit state render() { yield button({text: "Click Me", onClick}) yield text…

To me, the second is smaller but less clear for hiding the logic. I'd assume both button and text are output always.

Re: IBM releases Elm-powered app

#93
post #33
post #28

Earlier quoted context omitted.

"one of the few languages that have parametric polymorphism but no ad-hoc polymorphism" I wonder what others are? Would like to try them.

OCaml and Standard ML are two others, and I'd say OCaml is established enough that Elm is not really breaching new ground here. The main difference is that OCaml has other features you tend to use instead, particularly the module system.

OCaml is a very fun language in my experience. Apparently they were going to add ad-hoc polymorphism in the form of modular implicits, but I have no idea what happened to that.

Re: IBM releases Elm-powered app

#94

Earlier quoted context omitted.

> North Korean style crap This confirms my belief that most criticisms of Elm are emotional responses, not rational ones. Allowing arbitrary JS functions to be called from wherever would indeed break everything. Want to use `Math.random()`? Whoops! There goes referential transparency. Want to use `document.querySelector()`? Hello runtime errors my old friend. Want to use `function(x) { return x / 0; }`? Yeah, have fu…

I gave you examples of using JS type safe way. You don't care. One question I alway use to tilt FP purist zealots: How about Time.now()? :) Source of disturbance, it should not be allowed to be used in programming etc. etc.

Uhh… What? I’m confused. Did you think this would be a smoking gun to your argument?

Of course Time.now() is an effectful routine.

This is not a strange idea to “FP purist zealots” either.

How is it defined in Elm?

  Time.now : Task x Posix
How is it defined in Haskell?

  Data.Time.Clock.getCurrentTime :: IO UTCTime
And no, you have not given any examples of using JavaScript in a type-safe way. If you think you have, it means you don’t adequately understand type-safety.

Re: IBM releases Elm-powered app

#96
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.

> 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…

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.

Re: IBM releases Elm-powered app

#97

Earlier quoted context omitted.

Of course you can't hang yourself with `Math.PI` or `window.alert`. Try `Math.random()` and `window.confirm` instead, or much more relevant: `document.getElementById`.

I am not saying that everything is going to be super easy to do this way but taking away my ability of using Math.PI because of document.getElementById is silly.

If you absolutely must run unsafe JS interop inline then maybe Elm is not for you, but it doesn't make its approach "silly".

You can run absolutely any JS code, just through the ports API. Trivial things like Math.PI are in the core[1] or some package.

[1] https://package.elm-lang.org/packages/elm-lang/core/5.1.1/Ba...

Re: IBM releases Elm-powered app

#98

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…

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.

Re: IBM releases Elm-powered app

#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 development have far more choices with generally fewer pain points.

Re: IBM releases Elm-powered app

#100
post #33

Earlier quoted context omitted.

OCaml and Standard ML are two others, and I'd say OCaml is established enough that Elm is not really breaching new ground here. The main difference is that OCaml has other features you tend to use instead, particularly the module system.

OCaml is a very fun language in my experience. Apparently they were going to add ad-hoc polymorphism in the form of modular implicits, but I have no idea what happened to that.

It's due around the time OCaml multicore support and Half Life 3 are released.
Post reply on HN