Live data from Hacker News

IBM releases Elm-powered app

discourse.elm-lang.org

181–190 of 199 posts

Re: IBM releases Elm-powered app

#181

Earlier quoted context omitted.

In my opinion you get more than just "eliminating a class of bugs", in my (arguably limited) forays into functional programming languages I really liked the type-guided programming. One aspect is "I refactored the code, fixed all the type-errors and everything works", another is "I don't know, what should I write here, compiler, tell me!" with typed-holes, along-side some nice search, such as hoogle (or elm's fancy s…

With Clojure the approach is to use REPL driven development. It's tightly integrated with the editor, and any time you write a function you run it to see that it's doing what you intended. Because you're evaluating code as you're writing it, there's generally no confusion regarding what the code is doing. [1] Meanwhile, immutability as the default makes it natural to structure applications using independent component…

Nice, if I ever will have the pleasure of working in clojure, I will remember the re-find thing you mentioned here :-)

But to show more of I really liked when developing with types, take a look at this slightly contrived example [1]. I once tried to refactor a medium size haskell code-base, and ability to just ask the compiler "Hey what should I put in here?" really made my life easier :)

[1] https://github.com/paf31/24-days-of-purescript-2016/blob/mas...

Re: IBM releases Elm-powered app

#182
post #175

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

The alternative is less Javascript logic written by the app developer (and instead use packages and APIs directly). Elm disguised as a beginner friendly language for web front-end, which is not true with the case of ports. Where you need to be fairly familiar with Javascript. The Elm community also advertise a lot on the advantage of development happiness of Elm over Javascript, and mention the Javascript fatigue a l…

> sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided.

I don't understand. You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript.

This seems self-evidently false.

> If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.

Seems like the argument is Elm isn't ideal if you're not a programmer, because you can't cargo-cult it.

I think I'm ok with that.

Re: IBM releases Elm-powered app

#183

Earlier quoted context omitted.

With Clojure the approach is to use REPL driven development. It's tightly integrated with the editor, and any time you write a function you run it to see that it's doing what you intended. Because you're evaluating code as you're writing it, there's generally no confusion regarding what the code is doing. [1] Meanwhile, immutability as the default makes it natural to structure applications using independent component…

Nice, if I ever will have the pleasure of working in clojure, I will remember the re-find thing you mentioned here :-) But to show more of I really liked when developing with types, take a look at this slightly contrived example [1]. I once tried to refactor a medium size haskell code-base, and ability to just ask the compiler "Hey what should I put in here?" really made my life easier :) [1] https://github.com/paf31…

Yeah, there are nice aspects of having static typing as well. Haskell was the first FP language I've used actually, and it was a lot of fun. Eventually I ended up working with Clojure professionally, and I don't find that one approach or the other is strictly better. There are pros and cons to each, and they're both productive.

Re: IBM releases Elm-powered app

#184
post #122

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…

I would take F# + Fable over Reason since Reason doesn't have computation expressions or do-notation

OCaml 4.08 would have custom (let) expression.

https://github.com/ocaml/ocaml/pull/1947

Re: IBM releases Elm-powered app

#185

Earlier quoted context omitted.

An apples and oranges comparison. Any difference would surely be made up by all the tests one would have to write to be sure the clojure code was free of basic errors.

That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.

Tests prove the presence of bugs not their absence. You should be writing more tests if you have no static type system, in order to find the bugs that you would otherwise prove don't exist.

Re: IBM releases Elm-powered app

#186

Earlier quoted context omitted.

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

"I don't like how only the BDFL is allowed to do certain things, like create new operators in external libraries" Isn't this true for like, 95% of languages? Yes, Elm breaks from it's Haskell heritage in this regard, but this is a very common lack of feature.

Fair enough, but my main problem with it was that it existed, and then they removed it, which was very sad.

Re: IBM releases Elm-powered app

#188

Earlier quoted context omitted.

That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.

Tests prove the presence of bugs not their absence. You should be writing more tests if you have no static type system, in order to find the bugs that you would otherwise prove don't exist.

A static type system like Elm doesn't fix logical bugs like wrong indexing, wrong predicate etc, it just finds issues with types. Types do not contain the real logic of your program. Types are somewhat useful for verifying data is passed around in the correct shape in a program, but to say it prevents most obvious errors is naive. Not to mention in Elm you will waste tons of time doing useless tasks like writing encoders/decoders and code that could be moved to macros in a more powerful language.

Re: IBM releases Elm-powered app

#189

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.

It might be worth looking at the Reagent framework for Clojurescript.

Re: IBM releases Elm-powered app

#190
post #170

Earlier quoted context omitted.

Also, Elm has terrible communication (yearly posts) and official docs

Not true unless you mean only blog posts. And to be fair it's the best documented platform for web development I have worked with. Have you looked at documentations of random npm packages lately? No, fun.

Absolutely it has:

1. An official guide: https://guide.elm-lang.org/ - with a Hello World followed by all the basics.

2. Great docs https://elm-lang.org/docs with search function. Most package I see have all the functions described with examples etc. E.g. https://package.elm-lang.org/packages/elm/browser/latest/Bro...

3. A subreddit and discourse chat where beginners can ask questions and get good answers.

Post reply on HN