

Elm 0.9 - New type checker, much better error messages - StylifyYourBlog
http://elm-lang.org/blog/announce/version-0.9.elm

======
JumboCopter
"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.

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

~~~
wheatBread
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! :)

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

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

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

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

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

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

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

