Elm 0.9 - New type checker, much better error messages | Hacker News Reader

Elm 0.9 - New type checker, much better error messages

elm-lang.org

"Before this release, my primary priority was: prove that FRP is viable and good. If FRP is not the right way, it does not matter how good or bad the type checker is."

This is a lousy justification. If the intent was to prove that FRP was viable and good, why not do it in a dynamic type system? Implementing an extended Hindley Milner inference algorithm can be subtle, so why bother? I can manage a slow type checker, because "eh it's not 1.0", but an unsound type system, no.

I've tried Elm because I really wanted to program functionally a small webapp, but the type checker had so many holes in it that I had to translate the algorithms in Haskell, type them and fix them there before porting them back. I'm now really reluctant to try any new version of Elm.

Elm looks really interesting but one thing I haven't been able to figure out from their website is if there is much support for basic CRUD applications. I know they have basic HTML input controls and web service support but that doesn't much compare to modern javascript frameworks. Is Elm more targetted more at game developers?

I'm going to focus on creating more CRUD examples now that 0.9 is out.

In the same way that JavaScript needs frameworks to have a nice high-level way to create CRUD, Elm needs libraries and frameworks too. I have been focusing on language-level details, so Elm does not have those frameworks yet. It takes time, and I'm working on it! :)

Yes that totally makes sense. Really I just wanted to know if this is something you wanted Elm to provide good support for so thanks for your response here.

I really like Elm as a language, although I'm not into web development. Its record syntax is just so wonderful to work with and something Haskell could learn from.

I like the idea of the unary negation. It feels natural to seasoned programmers but also to beginners according to the last paragraph.

The change from em to pixels seems misguided. Pixels are not a replacement for ems just because it is a programming language. The claim made in the discussion that em is a kludge to make relative resizing possible is wrong. You don't control the users font size to start with. Using ems lets me specify sizes in terms relative to your font size which I do not know. Without ems, I have to force a pixel size on everything to start with, which is terrible (people with vision problems can't read anything now) and which doesn't actually work (setting a font to 10px will not work in my browser for example, I have the minimum font size constrained to 14px). We really do need both px and em to be available.

On a side note, any plans to integrate sounds? The use case I have that got me considering elm was simple web based games like solitaire or connect 4. Sound effects would be really nice there.

This change is more about consistency than anything else.

The problem is that other things, like shapes, are specified in pixels. So if text size isn't, it makes it impossible to position any shapes relative to text.

Think about a title in a game; you don't want it to go off the screen and you don't want it to wrap either.

I'm not suggesting that only ems be available, just that we need both px and em.

It seems the internet shares this opinion. My feeling was that `px` was a general solution, but I may have misunderstood the true meaning of em. I'd imagined code such as:

    em = 16
    title = Text.height (2*em) (toText "Title")
    pic = image 400 (4*em) "yogi.jpg"

I can also imagine the definition of em depending on the user's settings or fonts. In any case, we'll definitely open this up for discussion on the lists again if people start running into problems :)

Reply on news.ycombinator.com