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

141–150 of 199 posts

Re: IBM releases Elm-powered app

#141

Post by yakshaving_jgt »

hellofunk wrote: post #140
yakshaving_jgt wrote: post #139

Earlier quoted context omitted.

Great. I'm happy for you. However I think there's a difference between "with care, runtime errors are rare", and "by default, number of runtime errors is zero".

There is also a big difference between spending one hour debugging runtime errors on any given day or week vs. the time it takes to write 3x or 4x the code and handle compiler errors. Ultimately there are tradeoffs in how time is spent in both languages. Each developer will prefer different tradeoffs. I think in terms of net time spent on the whole dev cycle, it's hard to beat Clojurescript.

I have the exact opposite opinion :)

Re: IBM releases Elm-powered app

#142

Post by yakshaving_jgt »

sawady wrote: post #138
aarpmcgee wrote: post #123

Earlier quoted context omitted.

The core question is, "have you ever experienced a runtime error?" Have you ever spent time debugging a runtime error deployed to production? You can't get those in Elm.

List.tail []

  tail : List a -> Maybe (List a)
Nice try though.

https://github.com/elm/core/blob/master/src/List.elm#L548

Re: IBM releases Elm-powered app

#143

Post by haskman »

dkersten wrote: post #108
haskman wrote: post #70

Earlier quoted context omitted.

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.

Of course you need to understand how the framework works. But that's a fixed cost vs. having to understand a program from scratch everytime when your framework is not clear or powerful enough.

Would you also say using "goto" is easier because it's a simple jump, vs. having to understand how while/for loops work?

Re: IBM releases Elm-powered app

#144

Post by StreamBright »

aarpmcgee wrote: post #123
chickenfries wrote: post #116

Earlier quoted context omitted.

I literally have never experienced a bug because of the existence of Math.random(). I don’t think I’ve ever used it outside of a coding interview. Similarly, I don’t spend time debugging runtime errors caused by document.querySelector()? If I do it’s usually only once when I write the initial query. I don’t understand your last argument: why would I divide by 0? Everyone’s relationship to their tools of choice has an…

The core question is, "have you ever experienced a runtime error?" Have you ever spent time debugging a runtime error deployed to production? You can't get those in Elm.

https://medium.com/@eeue56/top-6-ways-to-make-your-elm-app-c...

Re: IBM releases Elm-powered app

#145

Post by haskman »

projektfu wrote: post #92
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…

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

It might seem like that, but javascript generator semantics mean that execution pauses at the first yield, and awaits external input before it resumes computation.

Also, the framework I described is only partially "hypothetical". [Concur-js](https://github.com/ajnsit/concur-js) gives you almost the same syntax and semantics. So you can try it out yourself :)

Re: IBM releases Elm-powered app

#146

Post by haskman »

marcosdumay wrote: post #115
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…

Hum... No. Abstractions can hide anything. Besides, your example get much of its gains by hiding the behavior of that 'if' statement than by hiding that 'buttonClicked' stores the button data.

> Hum... No. Abstractions can hide anything.

Sure, I'm not going to argue the meaning of "state". You know what I mean. Hiding internal state is good for abstraction.

> Besides, your example get much of its gains by hiding the behavior of that 'if' statement than by hiding that 'buttonClicked' stores the button data.

The if statement is intrinsically linked to the boolean state. If your render function forgets its implicit state on every update, then it needs to painstakingly analyse an external state and recreate its internal state. That's a cost which can be avoided.

Re: IBM releases Elm-powered app

#147

Post by yogthos »

yakshaving_jgt wrote: post #139
yogthos wrote: post #136

Earlier quoted context omitted.

ClojureScript will have quite a bit less code in a non-trivial project https://medium.freecodecamp.org/a-real-world-comparison-of-f... Meanwhile, my team has been working with ClojureScript for years, and runtime errors are a really rare occurrence in my experience. Especially if you use Schema or Spec around the API between components.

Great. I'm happy for you. However I think there's a difference between "with care, runtime errors are rare", and "by default, number of runtime errors is zero".

There's absolutely no empirical evidence to support the notion that static typing has a significant impact on errors https://danluu.com/empirical-pl/

Of course, if it makes you feel better personally that's great for you and you should keep using it. However, if you're going to make wide sweeping claims regarding that, then they have to be rooted in more than just your personal experience and rationalizing.

Re: IBM releases Elm-powered app

#148

Post by haskman »

the_gipsy wrote: post #80
haskman wrote: post #36

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

Aren't those few lines missing all of async/IO/runtime stuff? Is all that supposed to happen inside `render`?

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  show action))
          go (update st action)
Meanwhile, the render function itself can be a widget which performs side effects -

    view = do
      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/exam...

And running demo -

https://ajnsit.github.io/purescript-concur/

Re: IBM releases Elm-powered app

#149

Post by hellofunk »

yakshaving_jgt wrote: post #141
hellofunk wrote: post #140

Earlier quoted context omitted.

There is also a big difference between spending one hour debugging runtime errors on any given day or week vs. the time it takes to write 3x or 4x the code and handle compiler errors. Ultimately there are tradeoffs in how time is spent in both languages. Each developer will prefer different tradeoffs. I think in terms of net time spent on the whole dev cycle, it's hard to beat Clojurescript.

I have the exact opposite opinion :)

The problem with static typing confidence is it suggests no runtime errors, but really all it does is handle a certain class of runtime errors. To say that Elm has no runtime crashes is one thing, but it still suffers from all the runtime problems of any language when logic isn't written properly to account for different and unexpected values. Does your compiler guarantee that you don't have a "cents" value that is greater than 99? Or, for example, consider division by zero, which is another interesting case.

Clojurescript, on the other hand, has a novel system in place for handling runtime issues of any kind (types, values, whatever), because this is where it excels -- runtime dynamism.

Re: IBM releases Elm-powered app

#150

Post by yakshaving_jgt »

hellofunk wrote: post #149
yakshaving_jgt wrote: post #141

Earlier quoted context omitted.

I have the exact opposite opinion :)

The problem with static typing confidence is it suggests no runtime errors, but really all it does is handle a certain class of runtime errors. To say that Elm has no runtime crashes is one thing, but it still suffers from all the runtime problems of any language when logic isn't written properly to account for different and unexpected values. Does your compiler guarantee that you don't have a "cents" value that is g…

This argument is essentially “the tool doesn’t protect me from everything, therefore it’s better to have no protection at all.”

And I don’t agree with it. I’m aware Elm doesn’t have dependent types.

Post reply on HN