26 ms·

IBM releases Elm-powered app

263 points by quickthrower2 8y ago

ltbarcly3 8y ago
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 Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) Steve Yegge said it best almost 10 years ago: https://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html https://steve-yegge.blogspot.com/2010/12/haskell-researchers... Functional languages are great toys but nobody uses them to get work done, almost without exception.
- azemetre 8y ago
  I think this is interesting to me because Elm is an extremely unique way of doing frontend development on the web by utilizing functional programming concepts. IBM, in my mind, is a massive dinosaur. To know that some group there was able to make a consumer facing product using the latest tech is cool. Definitely gives IBM a better favorability rating in my view.
  - ltbarcly3 8y ago
    Not to be glib, but what you are saying, kind-of, is "the worse a company is at staying up to date with technology, the more meaningful it is if they use a fringe langauge"
    - wishinghand 8y ago
      I don't see that as a criticism. It just means a new technology is noteworthy enough that even those slow to catch up get interested. Like when senior citizens started using iPads.
    - yjftsjthsd-h 8y ago
      Yes? If a company sucks at trying new things, then it's probably noteworthy when they bothered to try a new thing, because it implies that either 1. they're pulling out of their rut, or 2. this thing was so great that even they wanted to use it. (Note, I'm not convinced that IBM is quite so ... obsolete... as this discussion implies, either.)
    - digitalzombie 8y ago
      Considering they sold most of their hardware department, such as harddrive to Hitachi and thinkpad to Lenovo, and went focusing on patents, this is a change in their image. I had the view they were risk adverse, to be using Elm is interesting.
- innocentoldguy 8y ago
  I think it is newsworthy because it details the strengths and weaknesses of Elm in what looks like a fairly complex project. I already use and like Elm better than any other front-end framework, but if I was considering Elm as a possibility, this information would be quite useful, I think. Definitely not the most important thing on the list, but I use Vim to code so IDE integrations mean absolutely nothing to me. I hate IDEs. To companies and teams that can't go to the bathroom without an IDE, that may be a deal breaker. Either way, it is good information to have.
  - quickthrower2 8y ago
    Just so you know, Vim has Elm plugins: https://github.com/ElmCast/elm-vim https://github.com/ElmCast/elm-vim. As an aside, of all the things I judge a job offer on, whether or not they use IDEs is pretty far down the list. I can get Visual Studio to behave like VIM and vice versa probably. I find it interesting that people sometimes hold this in high regard.
  - cttet 8y ago
    One of the reason I like Elm is that it has great potential for great IDEs. If you use Vim with lot of plugins then it is already sort of a minimal IDE right? Most IDE you hate perhaps have a lot of UX design problems. Good IDEs should aim for a better overall coding experience, by this definition. For example in Elm, all the nice error messages can appear next to the line, and all the case-of statements can be auto-completed according to the type definition, it all adds to an overall better coding experience.
- empath75 8y ago
  Could you be more condescending.
  - ltbarcly3 8y ago
    I wouldn't take comments about the relative popularity of programming language threads so personally as to insult someone.
- nemothekid 8y ago
  >I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) Doesn't this already happen almost every day for Rust and Go?
- int_19h 8y ago
  > I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) IBM writing an app of this size in Rust would definitely be headline-worthy. For other languages you list, it's not, but only because they're already well-established, and have been for decades. But it could have been a headline when they were new and unproven.
- quickthrower2 8y ago
  You have to take into account that Elm is relying on organic growth. If React had been released by a bunch of enthusiasts with day jobs, and no Facebook behind it, it may be in the same position as Elm. > Steve Yegge said it best almost 10 years ago That reads like a Register article. It's just a bit of fun.
- dnautics 8y ago
  > Functional languages are great toys but nobody uses them to get work done, almost without exception. Whatsapp was written in a FP, as is a large segment of Cisco router control plane. React arguably is strongly pushing towards a FP subset of ECMA6.
- yakshaving_jgt 8y ago
  > 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.
  - deleted 8y ago
    [deleted]
  - fsloth 8y ago
    That sounds really interesting! What's the market/domain of your software product?
    - yakshaving_jgt 8y ago
      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/ https://newbusinessmonitor.co.uk/ [1]: https://comparestack.com/ https://comparestack.com/ [2]: https://moneygains.co.uk/ https://moneygains.co.uk/
  - luuio 8y ago
    This is a good example of survivor bias.
- StreamBright 8y ago
  Totally: https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... "Which Team's Next? We believe in iterating on/alongside product teams in order to create the best infra. The product teams' and open source folks' feedback has changed our strategy a few times, for the better. As of today, Reason and BuckleScript are also deployed on a WhatsApp internal tool, Instagram Web (small scale), plus some critical Ads internal tools. We'll be working closely with these teams over the next year."
- fsloth 8y ago
  It's noteworthy that as you have shown, functional languages still have this insane opposition in the industry because they are perceived as toy languages. Despite the fact that they have a very bullish minority in the industry doing some very serious and lucrative work using them. See for example Jane Street and Ocaml. The fact that functional languages are not yet "mainstream" is more of an artefact to two things unrelated to their capability as languages in an industrial setting: a) Historical baggage. Industry has always taken the first tool it has come up with, declared it the "professional tool", which has become a self fullfilling prophecy then. Despite when looked from historical perspective, there is no technical reason why the chosen language was best among many. See for example C, C++, Java, and my favorite example JavaScript (ship it! 9 days is quite enough to make a language). I.e. industry has taken anything that creates an abstract syntax three that can be transferred to the chosen execution context, and maked it work by adding tooling and education, no matter how crude the language itself was. b) Lack of industrial quality tooling. See a). Industrial quality tooling is often a sane prequirement to choose a language for a project. There might be instances where you feel you might want to hire a legion of developers, and then you choose probably one of the most popular languages because it has tooling and it has a large number of candidates who know the language. Note: neither the fact that the language has tooling, nor that is popular, does mean it's the "best" for an arbitrary scenario.
- dkersten 8y ago
  > Functional languages are great toys but nobody uses them to get work done, almost without exception. Just because you don’t use functional languages for serious commercial work and don’t personally know anybody who does, doesn’t mean the rest of us don’t too. Plenty of us use functional languages for serious commercial work, now or in the past. I’ve persobally used ClonureScript and know plenty of people who use Clojure. I know people who use Haskell. Jane Street famously use OCaml. Lots of people use Scala. Clearly an IBM team uses Elm. I mean, the article itself is a counter example to your statement.
  - JoeAltmaier 8y ago
    Both can be correct - some number of folks do use them, but they are vanishingly small in the sea of developers out there.
- yogthos 8y ago
  >Functional languages are great toys but nobody uses them to get work done, almost without exception. As somebody who's been working with Clojure professionally for nearly a decade that's big news to me. Also, you might be surprised to know that it's used by companies like Walmart for critical infrastructure https://clojure.org/community/success_stories https://clojure.org/community/success_stories
patsall 8y ago
* Obligatory Pine joke here * (I know the Elm people don't like jokes about the email client. Tough; they should have picked a name that wasn't already used.)
- RickJWagner 8y ago
  I thought of Oak (later 'Java'), too.
- acheron 8y ago
  > Obligatory Pine joke here But Pine Is Not Elm. I wonder how many of today's Linux users don't get why the editor is named nano. The fact that you can trace the name back to "electronic mail" is my favorite command-name joke in an environment full of them. (If you missed the chain, it was 1. "electronic mail" = "elm" 2. "pine" as a joke on "elm" -- though I believe they deny the "PINE Is Not Elm" derivation, it's still pretty clearly a reference to elm 3. "pico" the editor as "PIne COmposer" 4. "nano" as a joke on "pico".)
  - yjftsjthsd-h 8y ago
    And let's not forget that less(1) is more(1) ;) (And there's also a most(1), because of course there is;p)
  - phlakaton 8y ago
    More of an "mh" dude myself. It was an efficient and pleasantly humorless system. :-)
  - JCharante 8y ago
    I didn't realize there was that much of a backstory behind nano's name! Thanks for sharing!
- benatkin 8y ago
  Maybe they like jokes about it somewhat but think people joke about it too much, and the way to get them to joke about it less is to pretend not to like it at all. I think that's what happened with Clojure and people coming up with jure puns on it (compujure, etc). https://github.com/Raynes/lein-newnew/blob/master/src/leiningen/new.clj#L54 https://github.com/Raynes/lein-newnew/blob/master/src/leinin...
savanaly 8y ago
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.
- k_bx 8y ago
  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 :)
- hellofunk 8y ago
  > 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 app to Clojurescript and it was only one-third the line count for the same functionality, and generally a smoother experience. I think some developers just love building up these huge, complex worlds and living inside them, and then telling others how big those worlds are.
  - the_gipsy 8y ago
    You make it seem like Elm strives to make big, complex programs and that people would take pride in that. That is not the case. It's nothing more than being happy that this somewhat academic and niche language is being adopted in the real-world.
  - davidgrenier 8y ago
    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 100k. Hard data on this kind of debate being hard to come by, we'd learn something from the experiment.
tolmasky 8y ago
Is there no way to try this without signing up? I even finally decided I'd sign up and then was greeted with a form that required a phone number.
- neurotrace 8y ago
  > The app is live here (requires registration) Doesn't look like it.
i_feel_great 8y ago
This inspired me to look up the Elm docs, and came across this gem: view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (String.fromInt model) ] , button [ onClick Increment ] [ text "+" ] ] The html elements themselves are Elm functions. Code looks like data. Nice. Now considering Elm to be potentially useful tool to know.
- grenadier21 8y ago
  That's how literally every VDOM-based framework looks, including React. Elm isn't special in this regard. It is special in many other regards, however, and I appreciate it for that. It's also interesting as one of the few languages that have parametric polymorphism but no ad-hoc polymorphism, which leads to some interesting designs. I don't like how only the BDFL is allowed to do certain things, like create new operators in external libraries, but overall, it's a very pleasant experience.
  - cttet 8y ago
    "one of the few languages that have parametric polymorphism but no ad-hoc polymorphism" I wonder what others are? Would like to try them.
    - Athas 8y ago
      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.
      - ikfmpwdsoz 8y ago
        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.
fxfan 8y ago
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.
- giornogiovanna 8y ago
  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.
  - sraquo 8y ago
    ScalaTags is indeed not relevant here, but Scala.js has its fair share of reactive UI libraries such as my own Laminar https://github.com/raquo/Laminar https://github.com/raquo/Laminar
    - lenticular 8y ago
      Your DOM builder library is also great for lower-level DOM manipulation. Thanks for your work, by the way. https://github.com/raquo/scala-dom-builder/ https://github.com/raquo/scala-dom-builder/
  - dkersten 8y ago
    Clojuresxript + re-frame would be pretty close though, right?
Kiro 8y ago
Completely OT but I'm curious about his use of space before exclamation and question marks. Is it a cultural thing?
- LeoPanthera 8y ago
  This is common in European languages.
- kvakil 8y ago
  In French, there is a space before exclamation and question marks. Based on the author's name, I'd also guess that they are French.
haskman 8y ago
Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming tricks when you can and want to. It is available for [Haskell](https://github.com/ajnsit/concur https://github.com/ajnsit/concur), [Purescript](https://github.com/ajnsit/purescript-concur https://github.com/ajnsit/purescript-concur), and [Javascript](https://github.com/ajnsit/concur-js https://github.com/ajnsit/concur-js) (so no need to learn a new language), and also allows using external React components. The Javascript version uses Async Generators as a substitute for Monads. With Concur, you can implement the entirety of Elm architecture with a few lines of idiomatic code. Purescript or Haskell - elm render update = go where go st = do action <- render st go (update st action) Or in JS - function elm(render, update){ var go = async function*(st) { action = yield* render(st); yield* go(update(st, action)); }; return go; }
- the_gipsy 8y ago
  Aren't those few lines missing all of async/IO/runtime stuff? Is all that supposed to happen inside `render`?
  - haskman 8y ago
    Edit: I changed my response after I took the time to understand what you meant. Concur has a very uniform programming model where you do everything by composing widgets. `elm` is a widget. `render` also is a widget. As such both can perform arbitrary async effects, and they take place inside event handlers, or inside lifecycle methods like componentWillMount. Concur takes care of managing that for you. So to log all actions to the console, you can add a logging call to `elm`. elm render update = go where go st = do action <- render st liftEffect (log ("Action - " <> show action)) go (update st action) Meanwhile, the render function itself can be a widget which performs side effects - view = do evt <- button [onClick] [text "Click me"] liftEffect (log "Button was clicked") return evt There are lots of examples of effects in the Concur repo - Take a look at some running examples here - https://github.com/ajnsit/purescript-concur/blob/master/examples https://github.com/ajnsit/purescript-concur/blob/master/exam... And running demo - https://ajnsit.github.io/purescript-concur/ https://ajnsit.github.io/purescript-concur/
deltron3030 8y ago
What I find most interesting about Elm as a designer who also "codes", is that because of its bottom up frontend philosophy (types first instead of components first) it somehow assumes that the UI designer and coder is the same person, that there is no clear designer to developer handoff where you hand over a thought out design to implement. It's more the other way round, where you'd hand over what you've come up with in Elm to a designer (which might be another problem because it reduces the designers job to just make things pretty). So the best use would be for designers who code, basically unifying frontend design and engineering.
- the_gipsy 8y ago
  So, something like react’s storyboard would be useful to you in Elm?
  - deltron3030 8y ago
    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 functionality based on existing visuals).
    - the_gipsy 8y ago
      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/functionality first if working on my own, but in a corporate environment I typically get designs handed together with some kind of specification, so there I often do "design-first".
yakshaving_jgt 8y ago
> 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?
- haskman 8y ago
  Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.
  - yakshaving_jgt 8y ago
    Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
    - haskman 8y ago
      > Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
      - 8y ago
fpoling 8y ago
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.
- StreamBright 8y ago
  And just about everything else sucks with Elm.
- haskman 8y ago
  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("Thanks!") }
  - fpoling 8y ago
    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 definition of the state. The implementation of render is only relevant if one wants to look at details. With the implicit state I have not only understand what render() is doing, but also understand how to properly call it from other parts of application. I.e. what happens when the render is called the third time?
    - haskman 8y ago
      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 returns a value or raises an event. i.e. the type is forall a. Widget a. So the issue of calling render a third time never arises.
hellofunk 8y ago
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.
- k_bx 8y ago
  - 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.
  - hellofunk 8y ago
    > 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.
    - k_bx 8y ago
      > 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.
gdsdfe 8y ago
hmm interesting ... on the other hand some people are trying to get away from ELM https://discourse.elm-lang.org/t/elm-to-bucklescript-compiler/2871/4 https://discourse.elm-lang.org/t/elm-to-bucklescript-compile...
srean 8y ago
Any HNer using Opa ? Is that alive and well. If someone has used elm and opa would love to know about their experiences.
anotheryou 8y ago
Is anyone doing business logic with a visual tool like this one? And if so: In production? Does it work? Do you trust non-programmers with it?

263 points by quickthrower2 8y ago

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 Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) Steve Yegge said it best almost 10 years ago: https://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html https://steve-yegge.blogspot.com/2010/12/haskell-researchers... Functional languages are great toys but nobody uses them to get work done, almost without exception.

azemetre 8y ago
I think this is interesting to me because Elm is an extremely unique way of doing frontend development on the web by utilizing functional programming concepts. IBM, in my mind, is a massive dinosaur. To know that some group there was able to make a consumer facing product using the latest tech is cool. Definitely gives IBM a better favorability rating in my view.
- ltbarcly3 8y ago
  Not to be glib, but what you are saying, kind-of, is "the worse a company is at staying up to date with technology, the more meaningful it is if they use a fringe langauge"
  - wishinghand 8y ago
    I don't see that as a criticism. It just means a new technology is noteworthy enough that even those slow to catch up get interested. Like when senior citizens started using iPads.
  - yjftsjthsd-h 8y ago
    Yes? If a company sucks at trying new things, then it's probably noteworthy when they bothered to try a new thing, because it implies that either 1. they're pulling out of their rut, or 2. this thing was so great that even they wanted to use it. (Note, I'm not convinced that IBM is quite so ... obsolete... as this discussion implies, either.)
  - digitalzombie 8y ago
    Considering they sold most of their hardware department, such as harddrive to Hitachi and thinkpad to Lenovo, and went focusing on patents, this is a change in their image. I had the view they were risk adverse, to be using Elm is interesting.
innocentoldguy 8y ago
I think it is newsworthy because it details the strengths and weaknesses of Elm in what looks like a fairly complex project. I already use and like Elm better than any other front-end framework, but if I was considering Elm as a possibility, this information would be quite useful, I think. Definitely not the most important thing on the list, but I use Vim to code so IDE integrations mean absolutely nothing to me. I hate IDEs. To companies and teams that can't go to the bathroom without an IDE, that may be a deal breaker. Either way, it is good information to have.
- quickthrower2 8y ago
  Just so you know, Vim has Elm plugins: https://github.com/ElmCast/elm-vim https://github.com/ElmCast/elm-vim. As an aside, of all the things I judge a job offer on, whether or not they use IDEs is pretty far down the list. I can get Visual Studio to behave like VIM and vice versa probably. I find it interesting that people sometimes hold this in high regard.
- cttet 8y ago
  One of the reason I like Elm is that it has great potential for great IDEs. If you use Vim with lot of plugins then it is already sort of a minimal IDE right? Most IDE you hate perhaps have a lot of UX design problems. Good IDEs should aim for a better overall coding experience, by this definition. For example in Elm, all the nice error messages can appear next to the line, and all the case-of statements can be auto-completed according to the type definition, it all adds to an overall better coding experience.
empath75 8y ago
Could you be more condescending.
- ltbarcly3 8y ago
  I wouldn't take comments about the relative popularity of programming language threads so personally as to insult someone.
nemothekid 8y ago
>I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) Doesn't this already happen almost every day for Rust and Go?
int_19h 8y ago
> I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Java or Python (or Objective-C or Swift or C# or even Visual Basic or Rust) IBM writing an app of this size in Rust would definitely be headline-worthy. For other languages you list, it's not, but only because they're already well-established, and have been for decades. But it could have been a headline when they were new and unproven.
quickthrower2 8y ago
You have to take into account that Elm is relying on organic growth. If React had been released by a bunch of enthusiasts with day jobs, and no Facebook behind it, it may be in the same position as Elm. > Steve Yegge said it best almost 10 years ago That reads like a Register article. It's just a bit of fun.
dnautics 8y ago
> Functional languages are great toys but nobody uses them to get work done, almost without exception. Whatsapp was written in a FP, as is a large segment of Cisco router control plane. React arguably is strongly pushing towards a FP subset of ECMA6.
yakshaving_jgt 8y ago
> 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.
- deleted 8y ago
  [deleted]
- fsloth 8y ago
  That sounds really interesting! What's the market/domain of your software product?
  - yakshaving_jgt 8y ago
    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/ https://newbusinessmonitor.co.uk/ [1]: https://comparestack.com/ https://comparestack.com/ [2]: https://moneygains.co.uk/ https://moneygains.co.uk/
- luuio 8y ago
  This is a good example of survivor bias.
StreamBright 8y ago
Totally: https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... "Which Team's Next? We believe in iterating on/alongside product teams in order to create the best infra. The product teams' and open source folks' feedback has changed our strategy a few times, for the better. As of today, Reason and BuckleScript are also deployed on a WhatsApp internal tool, Instagram Web (small scale), plus some critical Ads internal tools. We'll be working closely with these teams over the next year."
fsloth 8y ago
It's noteworthy that as you have shown, functional languages still have this insane opposition in the industry because they are perceived as toy languages. Despite the fact that they have a very bullish minority in the industry doing some very serious and lucrative work using them. See for example Jane Street and Ocaml. The fact that functional languages are not yet "mainstream" is more of an artefact to two things unrelated to their capability as languages in an industrial setting: a) Historical baggage. Industry has always taken the first tool it has come up with, declared it the "professional tool", which has become a self fullfilling prophecy then. Despite when looked from historical perspective, there is no technical reason why the chosen language was best among many. See for example C, C++, Java, and my favorite example JavaScript (ship it! 9 days is quite enough to make a language). I.e. industry has taken anything that creates an abstract syntax three that can be transferred to the chosen execution context, and maked it work by adding tooling and education, no matter how crude the language itself was. b) Lack of industrial quality tooling. See a). Industrial quality tooling is often a sane prequirement to choose a language for a project. There might be instances where you feel you might want to hire a legion of developers, and then you choose probably one of the most popular languages because it has tooling and it has a large number of candidates who know the language. Note: neither the fact that the language has tooling, nor that is popular, does mean it's the "best" for an arbitrary scenario.
dkersten 8y ago
> Functional languages are great toys but nobody uses them to get work done, almost without exception. Just because you don’t use functional languages for serious commercial work and don’t personally know anybody who does, doesn’t mean the rest of us don’t too. Plenty of us use functional languages for serious commercial work, now or in the past. I’ve persobally used ClonureScript and know plenty of people who use Clojure. I know people who use Haskell. Jane Street famously use OCaml. Lots of people use Scala. Clearly an IBM team uses Elm. I mean, the article itself is a counter example to your statement.
- JoeAltmaier 8y ago
  Both can be correct - some number of folks do use them, but they are vanishingly small in the sea of developers out there.
yogthos 8y ago
>Functional languages are great toys but nobody uses them to get work done, almost without exception. As somebody who's been working with Clojure professionally for nearly a decade that's big news to me. Also, you might be surprised to know that it's used by companies like Walmart for critical infrastructure https://clojure.org/community/success_stories https://clojure.org/community/success_stories

patsall 8y ago

* Obligatory Pine joke here * (I know the Elm people don't like jokes about the email client. Tough; they should have picked a name that wasn't already used.)

RickJWagner 8y ago
I thought of Oak (later 'Java'), too.
acheron 8y ago
> Obligatory Pine joke here But Pine Is Not Elm. I wonder how many of today's Linux users don't get why the editor is named nano. The fact that you can trace the name back to "electronic mail" is my favorite command-name joke in an environment full of them. (If you missed the chain, it was 1. "electronic mail" = "elm" 2. "pine" as a joke on "elm" -- though I believe they deny the "PINE Is Not Elm" derivation, it's still pretty clearly a reference to elm 3. "pico" the editor as "PIne COmposer" 4. "nano" as a joke on "pico".)
- yjftsjthsd-h 8y ago
  And let's not forget that less(1) is more(1) ;) (And there's also a most(1), because of course there is;p)
- phlakaton 8y ago
  More of an "mh" dude myself. It was an efficient and pleasantly humorless system. :-)
- JCharante 8y ago
  I didn't realize there was that much of a backstory behind nano's name! Thanks for sharing!
benatkin 8y ago
Maybe they like jokes about it somewhat but think people joke about it too much, and the way to get them to joke about it less is to pretend not to like it at all. I think that's what happened with Clojure and people coming up with jure puns on it (compujure, etc). https://github.com/Raynes/lein-newnew/blob/master/src/leiningen/new.clj#L54 https://github.com/Raynes/lein-newnew/blob/master/src/leinin...

savanaly 8y ago

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.

k_bx 8y ago
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 :)
hellofunk 8y ago
> 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 app to Clojurescript and it was only one-third the line count for the same functionality, and generally a smoother experience. I think some developers just love building up these huge, complex worlds and living inside them, and then telling others how big those worlds are.
- the_gipsy 8y ago
  You make it seem like Elm strives to make big, complex programs and that people would take pride in that. That is not the case. It's nothing more than being happy that this somewhat academic and niche language is being adopted in the real-world.
- davidgrenier 8y ago
  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 100k. Hard data on this kind of debate being hard to come by, we'd learn something from the experiment.

tolmasky 8y ago

Is there no way to try this without signing up? I even finally decided I'd sign up and then was greeted with a form that required a phone number.

neurotrace 8y ago
> The app is live here (requires registration) Doesn't look like it.

i_feel_great 8y ago

This inspired me to look up the Elm docs, and came across this gem: view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (String.fromInt model) ] , button [ onClick Increment ] [ text "+" ] ] The html elements themselves are Elm functions. Code looks like data. Nice. Now considering Elm to be potentially useful tool to know.

grenadier21 8y ago
That's how literally every VDOM-based framework looks, including React. Elm isn't special in this regard. It is special in many other regards, however, and I appreciate it for that. It's also interesting as one of the few languages that have parametric polymorphism but no ad-hoc polymorphism, which leads to some interesting designs. I don't like how only the BDFL is allowed to do certain things, like create new operators in external libraries, but overall, it's a very pleasant experience.
- cttet 8y ago
  "one of the few languages that have parametric polymorphism but no ad-hoc polymorphism" I wonder what others are? Would like to try them.
  - Athas 8y ago
    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.
    - ikfmpwdsoz 8y ago
      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.

fxfan 8y ago

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.

giornogiovanna 8y ago
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.
- sraquo 8y ago
  ScalaTags is indeed not relevant here, but Scala.js has its fair share of reactive UI libraries such as my own Laminar https://github.com/raquo/Laminar https://github.com/raquo/Laminar
  - lenticular 8y ago
    Your DOM builder library is also great for lower-level DOM manipulation. Thanks for your work, by the way. https://github.com/raquo/scala-dom-builder/ https://github.com/raquo/scala-dom-builder/
- dkersten 8y ago
  Clojuresxript + re-frame would be pretty close though, right?

Kiro 8y ago

Completely OT but I'm curious about his use of space before exclamation and question marks. Is it a cultural thing?

LeoPanthera 8y ago
This is common in European languages.
kvakil 8y ago
In French, there is a space before exclamation and question marks. Based on the author's name, I'd also guess that they are French.

haskman 8y ago

Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming tricks when you can and want to. It is available for [Haskell](https://github.com/ajnsit/concur https://github.com/ajnsit/concur), [Purescript](https://github.com/ajnsit/purescript-concur https://github.com/ajnsit/purescript-concur), and [Javascript](https://github.com/ajnsit/concur-js https://github.com/ajnsit/concur-js) (so no need to learn a new language), and also allows using external React components. The Javascript version uses Async Generators as a substitute for Monads. With Concur, you can implement the entirety of Elm architecture with a few lines of idiomatic code. Purescript or Haskell - elm render update = go where go st = do action <- render st go (update st action) Or in JS - function elm(render, update){ var go = async function*(st) { action = yield* render(st); yield* go(update(st, action)); }; return go; }

the_gipsy 8y ago
Aren't those few lines missing all of async/IO/runtime stuff? Is all that supposed to happen inside `render`?
- haskman 8y ago
  Edit: I changed my response after I took the time to understand what you meant. Concur has a very uniform programming model where you do everything by composing widgets. `elm` is a widget. `render` also is a widget. As such both can perform arbitrary async effects, and they take place inside event handlers, or inside lifecycle methods like componentWillMount. Concur takes care of managing that for you. So to log all actions to the console, you can add a logging call to `elm`. elm render update = go where go st = do action <- render st liftEffect (log ("Action - " <> show action)) go (update st action) Meanwhile, the render function itself can be a widget which performs side effects - view = do evt <- button [onClick] [text "Click me"] liftEffect (log "Button was clicked") return evt There are lots of examples of effects in the Concur repo - Take a look at some running examples here - https://github.com/ajnsit/purescript-concur/blob/master/examples https://github.com/ajnsit/purescript-concur/blob/master/exam... And running demo - https://ajnsit.github.io/purescript-concur/ https://ajnsit.github.io/purescript-concur/

deltron3030 8y ago

What I find most interesting about Elm as a designer who also "codes", is that because of its bottom up frontend philosophy (types first instead of components first) it somehow assumes that the UI designer and coder is the same person, that there is no clear designer to developer handoff where you hand over a thought out design to implement. It's more the other way round, where you'd hand over what you've come up with in Elm to a designer (which might be another problem because it reduces the designers job to just make things pretty). So the best use would be for designers who code, basically unifying frontend design and engineering.

the_gipsy 8y ago
So, something like react’s storyboard would be useful to you in Elm?
- deltron3030 8y ago
  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 functionality based on existing visuals).
  - the_gipsy 8y ago
    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/functionality first if working on my own, but in a corporate environment I typically get designs handed together with some kind of specification, so there I often do "design-first".

yakshaving_jgt 8y ago

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

haskman 8y ago
Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.
- yakshaving_jgt 8y ago
  Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
  - haskman 8y ago
    > Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
    - 8y ago

fpoling 8y ago

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.

StreamBright 8y ago
And just about everything else sucks with Elm.
haskman 8y ago
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("Thanks!") }
- fpoling 8y ago
  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 definition of the state. The implementation of render is only relevant if one wants to look at details. With the implicit state I have not only understand what render() is doing, but also understand how to properly call it from other parts of application. I.e. what happens when the render is called the third time?
  - haskman 8y ago
    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 returns a value or raises an event. i.e. the type is forall a. Widget a. So the issue of calling render a third time never arises.

hellofunk 8y ago

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.

k_bx 8y ago
- 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.
- hellofunk 8y ago
  > 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.
  - k_bx 8y ago
    > 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.

gdsdfe 8y ago

hmm interesting ... on the other hand some people are trying to get away from ELM https://discourse.elm-lang.org/t/elm-to-bucklescript-compiler/2871/4 https://discourse.elm-lang.org/t/elm-to-bucklescript-compile...

srean 8y ago

Any HNer using Opa ? Is that alive and well. If someone has used elm and opa would love to know about their experiences.

anotheryou 8y ago

Is anyone doing business logic with a visual tool like this one? And if so: In production? Does it work? Do you trust non-programmers with it?