Debugging with Elm 0.18 | Hacker News Reader

Debugging with Elm 0.18

elm-lang.org

147 pointsronjouch36 comments

I've updated a few of my projects to 0.18 over the last couple weeks. The new HTTP library is much better than the one before. Working with Authentication Tokens, decoding errors etc is much easier now.

I also welcome the continuous work to remove things which are difficult for beginners and make code less readable, like the backtick syntax and the prime notation. I mostly work with backend code, and I wanted to learn some JS but found the ecosystem hard to swallow. Elm offers a very practical, and quick to get started experience for writing reliable frontend. For a quick win with UI work, also check out the Elm-MDL library. https://debois.github.io/elm-mdl/

---

Coincidentally, I was watching MPJ's FunFunFunction today, where he talks about JS libraries that coerce HTTP statuses into JS errors, and he managed to articulate some of my frustrations with elm-lang/http. The library tries to be helpful by returning a `BadStatus (Response String)` error if the status is not a 20x code. An error is what I want sometimes, but far from always. The result is also a string, while most of the API's I interact with return JSON for errors.

https://www.youtube.com/watch?v=gRsyY0kzXfw&feature=youtu.be...

Http does allow you to get the raw data and treat it as you will. It also isn't that much code. Check out the custom requests section of the documentation.

Right, I know how to get around this issue when I need to. My point was that the library makes a default assumption which is often enough false. And then I have to change things.

Compare this to Go, or even Fetch. You send a request, and you get back a response, with a Body, Headers and Status. A language error type is only expected in case of the request not succeeding, like a timeout. Here, the library makes 2 assumptions. That a non-200 status is an Error, and that the response is a String. These assumptions would be ok in a higher level library someone wanted to build, but as part of a core, they're too high level to work for everyone with the defaults.

At work we developed internal tool in Elm + elm-mdl for listening to specific events and notifying developer on their status change. It takes about 5 minutes to understand what is going on in application by just reading Model/Update. One person can refactor almost whole app and be sure he did not break a thing. Most issues we got were in ports (JavaScript). Also the same page is running as Chrome Extension and Firefox Extension.

I can say that development performance was 3x than the same developers in JS. Plus you don't have to write unit tests and deal with grunt/gulp/npm packages nonsense.

We got only one runtime exception - our state was saved in localStorage and pushed into Elm.embed when page was opened. If this format changes in Elm/localStorage - Elm fails to start. It would be nice to get some promise rejected when you do Elm.embed() and it fails to initialize. But we can write our own Json.decoders and parse state inside application - in such case we can even write data migrators for user data.

Next stop for us will be to rewrite some views into Elm and integrate them into huge our JS project.

How many lines of code are you at? Have you written tests?

And how many people use the application per week?

it is about 2000 lines

I'm glad Evan took out some of the Haskellish syntax that non-Haskellers find confusing, like the x' variable names and backtick syntax.

The decision to write something with backticks or the pipe operator seemed to be a matter of personal taste, and I like a system where these less-important decisions are already made.

It didn't confuse me but it did annoy me!

The x-prime looked like the elm equivalent of mysql_real_escape from PHP.

I've only been using the pipe syntax and this makes things simpler; backticks are special syntax, pipe syntax is just another function.

It didn't help that the argument order of some functions were specifically written to be used in backticks (like `andThen`). So I had to litter `flip` everywhere to use the pipe syntax. Evan flipped the arguments in 0.18 and now I can just `:%s/flip andThen/andThen`.

Also, backticks are absent from some (many?) common non-qwerty keyboards (French azerty, for example), making them even more arcane / un-discoverable.

I for one would make no design decisions at all taking French AZERTY as a consideration. As a Frenchman I feel I can say it's the world's most badly designed keyboard that's used in a major language. I would truly like to know its origins and how it got so bad, cause I have no idea.

Only two of my main gripes: How come there's a whole key dedicated to superscript 2 and superscript 3? How many times a year does one use the key that's dedicated to the Greek letter Mu and the £ sign?

If we're lacking a key for `, howbout we change the ù key into it, given ù is used only in a single word in the whole language?

> "As a Frenchman I feel I can say it's the world's most badly designed keyboard that's used in a major language. I would truly like to know its origins and how it got so bad, cause I have no idea."

I agree the AZERTY layout sucks. But it's not alone in its messiness, even QWERTY's (un-) design continues to raise questions: https://en.wikipedia.org/wiki/QWERTY#History

> "I for one would make no design decisions at all taking French AZERTY as a consideration."

Let me expand that statement: you are a craftsman who refuses to adjust his product to a piece of infrastructure that will at worst never budge, at best evolve conservatively and regardless of what you think, hurting your users/customers and bringing you nothing but some pride of not stepping over a self-imposed line in the sand.

Don't you think that's unrealistic and a bit sad? Have you seen many US roadsign makers refuse to build mph signs and print km/h signs instead because metric is better than imperial?

I think that's a false equivalency.

The cost for people on AZERTY to just get a nice QWERTY layout, individually, is very small, and can be implemented on a personal level.

Units of measure have to be, more often than not, coördinated among multiple people, which increases the costs of migrating between them, making it less favorable.

I'd be a craftsman refusing to adjust my product in a way that benefits an extremely small subset of my users (people on a French keyboard) and worsens the experience of a major subset of my target audience (people on a keyboard with ` that have prior experience with this syntax).

Let's put it this way: If a programming language required the letter ù in its syntax, which being present on a French keyboard but not on most others, represents the inverse of the current situation, my advice would be different.

I've been waiting for 0.18 in anticipation because I had heard we might get server rendering.

Instead a bunch of language and syntax that I enjoyed was removed from the language, but I get better bug reports? The export button is broken unless I click "resume" which I find pretty odd.

I have to say I'm really disappointed, every release they just remove language features.

I was sad to see record fields not being addable anymore. It made for a good typeclass replacement, with no extra baggage.

That's been gone for a while.

Perhaps it's a cleanup-run before adding new stuff. Removing need for arcane syntax seems like it could simplify the compilation pipeline.

The syntax was hardly 'arcane', and I doubt it was necessary to remove these features for the purpose of streamlining the compiler, that sounds a bit ridiculous. In fact you could argue that throwing an error on functions' is actually doing more work. That really is a style thing and something best left to a linter or the like.

Evan hasn't mentioned anywhere that he's been removing features for the last year or so just to give us some big features later. If he has said that I would love to see it.

Removing them wasn't necessary, but it's better. Elm isn't 1.0 yet, so "does this make the language better" is the metric for feature addition or deletion.

"better" is so arbitrary that I'm afraid it's pretty much "what does Evan-san want"

Every other comment about these changes has expressed approval. An overwhelming majority of Elm community members I've heard discuss this feel the same way.

You are welcome to a dissenting opinion, of course, but throwing shade at Evan for his popular design decisions seems unlikely to change anyone's mind.

What has been removed is just syntactic sugar that can easily be acheived in other ways. I think it's a good thing that Elm's core is kept as clean and simple as possible. There are enough other languages with a kitchen sink philosophy.

Explain the 'other ways' I can name a function with a prime or use backticks now that the compiler won't allow it.

The migration guide [1] suggests that instead of primes you can use underscores. And instead of backticks you can use pipelining.

[1]: https://github.com/elm-lang/elm-platform/blob/11c8ecb81a58b8...

My mistake, I thought you were saying I could still have the syntax features I wanted in the language. I like the range syntax, and backticks, and calling functions'. I also liked signals and having access to more stuff that is now 'magic' in the Elm compiler.

It sounds like you might like PureScript [1] or GHCJS [2] more than Elm. Have you tried either of those?

[1]: http://www.purescript.org/ [2]: https://github.com/ghcjs/ghcjs

No, those don't really appeal to me. I think Elm had a great middle ground for a while pre-0.16 with Signals. I'm just disappointed at what I see as a lack of positive change for the language. The more stuff that becomes compiler magic the worse the language is going to get IMO.

> The more stuff that becomes compiler magic the worse the language is going to get IMO.

Not sure what you mean here. Elm 0.18 has less compiler magic, not more.

One such magic is the "comparable" thing. See http://reasonablypolymorphic.com/blog/elm-is-wrong and https://github.com/elm-lang/elm-compiler/issues/774

Yes, but that's not new in 0.18

Did you read my comment? I mentioned the removal of Signals and it's replacement with the 'magic' Html.app

Html.App used to be a namespace, I suspect you mean Program? In any case, how is that any more, or less, magic than Signals? Considering that the compiler has removed syntax in later versions, later versions of Elm has less magic than earlier versions.

Personally I do not like underscores. It can get real ugly.

So instead of:

    map3 f ( x, cmd ) ( y, cmd' ) ( z, cmd'' ) =

I will have to write:

    map3 f ( x, cmd ) ( y, cmd_ ) ( z, cmd__ ) =

https://github.com/Fresheyeball/elm-return/pull/4/files#diff...

And it affects package API too: https://github.com/elm-lang/svg/commit/40b761d66b48fcc28f5b5...

However that's just a matter of taste and does not deter me from continuing to use Elm.

Use numbers instead of backticks or underscores. There's a reason we got rid of roman numerals.

The "other way" is to use x_1, x_2, or to just use better variable names.

Haskellers are bad at coming up with informative variable names (and I say this as a Haskeller).

Reply on news.ycombinator.com