Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Putting Down Elm

mkndrsn.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: Putting Down Elm

#21

Post by pka »

tlrobinson wrote: post #15
kemiller wrote: post #7

This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.

I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.

This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.

Re: Putting Down Elm

#22

Post by masklinn »

spuz wrote: post #2

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

> Is there something special about Elm that gives you this kind of benefit

Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust.

Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.

Re: Putting Down Elm

#24

Post by skybrian »

orblivion wrote: post #17
spuz wrote: post #2

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

Haskell had poor error messages last I tried it. Have they improved?

Re: Putting Down Elm

#25

Post by mdm_ »

pka wrote: post #18
tacos wrote: post #16

This is the perfect example of the content-free HN posts that are topping the charts lately. It contains not a single example of a "helpful error message." Nor a single line of code from the language in question. Just a 173 word free-verse poem with some feel-good handwaving. If this were a post about soap (the salt, not the protocol) we'd downvote the post as obvious content-free shilling. But because it's some obsc…

In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.

Great, I look forward to future HN posts such as "Elm is really super. The rest of this article is left as an exercise for the reader."

Re: Putting Down Elm

#26

Post by tlrobinson »

shimon wrote: post #20
tlrobinson wrote: post #15

Earlier quoted context omitted.

I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.

This is the promise of type inference. Languages like Elm that do a good job inferring types are able to play out potentially invalid implications of how your code uses values without requiring you to separately specify all your types in great detail. You'll spend some time just addressing edge cases as "safe to ignore" but it's a lot lower than explicit typing while delivering many of its benefits.

Flow actually does type inference as well.

Re: Putting Down Elm

#27

Post by skybrian »

shimon wrote: post #20
tlrobinson wrote: post #15

Earlier quoted context omitted.

I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.

This is the promise of type inference. Languages like Elm that do a good job inferring types are able to play out potentially invalid implications of how your code uses values without requiring you to separately specify all your types in great detail. You'll spend some time just addressing edge cases as "safe to ignore" but it's a lot lower than explicit typing while delivering many of its benefits.

Type inference usually makes it harder for a compiler to provide good error messages though. Elm has gone the extra mile on this.

Re: Putting Down Elm

#28

Post by vinceguidry »

You should always let something else 'drive' your coding. Lots of people like tests. I personally am not a huge fan of TDD, though it's better than a lot of alternatives.

Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step.

It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is.

Whereas if you're building a new feature, you want to keep the command static until you see what you want to see.

There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.

Re: Putting Down Elm

#29

Post by orblivion »

skybrian wrote: post #24
orblivion wrote: post #17

Earlier quoted context omitted.

Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

Haskell had poor error messages last I tried it. Have they improved?

I didn't think that ease of understanding was necessarily the point. My point was that once you do understand them, it sort of tells you what to do next.

That said, in a recent HN post somebody said that the latest version of GHC has better error messages, which I agree would be welcome, but I haven't tried it.

Re: Putting Down Elm

#30

Post by the_gipsy »

orblivion wrote: post #17
spuz wrote: post #2

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

No, Elm is definitely less complex and generally targetted for newcomers to the FP and pure world.

In haskell there are like a 100 ways of doing anything and it's very hard (for me at least) to figure out where even to begin. Elm tries to reduce options and lets noobs like me get going.

Post reply on HN