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

61–70 of 199 posts

Re: IBM releases Elm-powered app

#61

Post by yakshaving_jgt »

haskman wrote: post #59
yakshaving_jgt wrote: post #49

Earlier quoted context omitted.

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 :)

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

> I find that Monads become intractable for new devs without do-notation.

That's a fair point, and I agree, however this somewhat negates your previous point:

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

I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project.

I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.

Re: IBM releases Elm-powered app

#62

Post by _0w8t »

haskman wrote: post #54
_0w8t wrote: 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…

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?

Re: IBM releases Elm-powered app

#63

Post by hellofunk »

cttet wrote: post #30
i_feel_great wrote: post #20

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.

This was also the thing that attracted me to Elm years ago. But at that time Elm doesn't have a CSS module yet. Now with Elm-UI, it is like my dream HTML/CSS replacement. However that was all for static UI though. Writing Elm app is still a pain if you are not a Javascript expert. Elm's implementation of the web API is minimal and the progress is extremely slow. In addition, most function that's in libraries in Javas…

Elm-UI is in a questionable state. Their github page originally said it was no longer maintained. Now they acknowledge that they are struggling to update to the latest version of Elm which caused many syntax breakages.

Re: IBM releases Elm-powered app

#64

Post by vanderZwan »

roadbeats wrote: post #56
computerex wrote: post #41

Earlier quoted context omitted.

I thought Elm was known for having vast quantities of boilerplate? I wouldn't put much stock into number of lines of code.

I never had that impression when I was building projects with Elm, in fact, it felt like I was focusing on the app itself instead of the language and boilerplate. I compared it with JS mess though.

It's quite "vertical" though (which is fine, it just makes LOC comparisons a bit less useful)

Re: IBM releases Elm-powered app

#65

Post by fsloth »

yakshaving_jgt wrote: post #38
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…

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

Re: IBM releases Elm-powered app

#66

Post by deltron3030 »

the_gipsy wrote: post #44
deltron3030 wrote: post #37

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

So, something like react’s storyboard would be useful to you in Elm?

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).

Re: IBM releases Elm-powered app

#67

Post by haskman »

yakshaving_jgt wrote: post #61
haskman wrote: post #59

Earlier quoted context omitted.

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

> I find that Monads become intractable for new devs without do-notation. That's a fair point, and I agree, however this somewhat negates your previous point: > 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 toolse…

> I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with.

Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.

Re: IBM releases Elm-powered app

#68

Post by fsloth »

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…

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.

Re: IBM releases Elm-powered app

#69

Post by ltbarcly3 »

empath75 wrote: post #10
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…

Could you be more condescending.

I wouldn't take comments about the relative popularity of programming language threads so personally as to insult someone.

Re: IBM releases Elm-powered app

#70

Post by haskman »

_0w8t wrote: post #62
haskman wrote: post #54

Earlier quoted context omitted.

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…

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 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.
Post reply on HN