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

Small Assets without the Headache in Elm 0.19

elm-lang.org

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Small Assets without the Headache in Elm 0.19

#111

Post by Skinney »

Athas wrote: post #107
rtfeldman wrote: post #99

Earlier quoted context omitted.

> use of dictionary passing as a substitute for typeclasses No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. Another example of their being different is that Haskell offers custom…

> Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a not…

I guess Go is the only language which comes close, which has map and array/slice which cannot be implemented in the language itself. Though it's the lack of generics, not ad-hoc polymorphism which is Go's lack.

Then again, it wouldn't surprise me if of all the languages you've thought about, Elm is the only one which hasn't reached 1.0 yet.

I think Elm will get some mechanism of ad-hoc polymorphism before it reaches 1.0, but I don't think it will be type classes. Though, I have been wrong before.

Re: Small Assets without the Headache in Elm 0.19

#112

Post by jarcane »

rtfeldman wrote: post #109
hazza1 wrote: post #105

Earlier quoted context omitted.

True, probably a lot of bias in my environment but I interview a lot of people for frontend roles - a couple of years ago Elm was the next exciting language to learn, it's now more often than not Reason.

The last time I interviewed someone who applied because they wanted to use Elm in production was an hour ago. Elm continues to be our #1 source of applicants, and none of them mention an interest in Reason...but then again, it would make sense that Reason, being newer and endorsed by Facebook, would have more interest in the overall JS community!

Honestly my love of Elm is part of why I'm completely uninterested in Reason and the direction it's taken.

Re: Small Assets without the Headache in Elm 0.19

#113

Post by Skinney »

leshow wrote: post #104
undreren wrote: post #20

Earlier quoted context omitted.

> Once people start using Elm the way it was designed to be used, things become simple and start to flow. But how will anyone ever get anything done, when they can't make everything in their code exceptionally clear by wrapping it all up in a 15 monad thick monad-combinator? /s But yes, I totally agree. Elm is a simpler, safer and easier Haskell for the front-end. I just love it :)

I don't think it's crazy to wish for some kind of interface or trait-like abstraction mechanism in a language. Anything taken to the extreme can sound stupid. edit: I'm not saying Elm should change, the time for that is long gone. Just that the idea someone would want an interface (to do things like bound on generically) isn't that far fetched.

> the time for that is long gone

What makes you say that? Elm has yet to reach 1.0, anything can happen. It's not likely it will happen any time soon, however.

Re: Small Assets without the Headache in Elm 0.19

#116

Post by bjz_ »

rtfeldman wrote: post #99
comex wrote: post #95

Earlier quoted context omitted.

> Elm handles those things the way Standard ML does, not the way Haskell does. That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow use of dictionary passing as a substitute for typeclasses, and as you noted, this approach has some resemblance to how ML modules work – albeit with less sugar. However, Elm's standard library does not seem to think this is the best approach, since it instead use…

> use of dictionary passing as a substitute for typeclasses No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. Another example of their being different is that Haskell offers custom…

> No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses.

Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedious to pass around module definitions all the time, which is why they added equality types when the language was originally designed. This is considered an ugly hack though, even by its own creators [0].

Definitely agree that folks should aim for better than type classes, especially due to complications around global instance coherence. One nice solution is modular implicits/instance arguments [1][2]. Tricky thing is to do it without adding too much complexity to the language.

I do wish that there would just be some acknowledgment that it's a hard, but real problem to solve for Elm's point in the design space, rather than just pretending it isn't there. It's ok just to say that you're not spending design capital on it at the moment due to more pressing issues!

[0]: https://github.com/SMLFamily/Successor-ML/issues/18

[1]: https://arxiv.org/abs/1512.01895

[2]: https://www.researchgate.net/profile/Dominique_Devriese/publ...

Re: Small Assets without the Headache in Elm 0.19

#117

Post by SupremumLimit »

aczerepinski wrote: post #65

I've dabbeled in Elm and have some trivial single static pages in Elm on one of my sites. Is there a book or blog series anybody could recommend that's less about the language and more about the practical steps of building a full single page app in Elm? How does routing work, do you need JS to integrate with your API, how to configure the compilation/build/deploy step, etc?

I wrote up a list of Elm resources (including books) recently: https://korban.net/posts/elm/2018-07-31-learning-elm-2018-co...

There are quite a few books/courses/articles which examine various aspects of building an SPA.

Re: Small Assets without the Headache in Elm 0.19

#118

Post by SupremumLimit »

lsjroberts wrote: post #16
subbz wrote: post #7

Seeing that and liking Elm I have to tell that GatsbyJS ( https://www.gatsbyjs.org/ ) outputs really fast end-products. Is that possible with Elm too?

Gatsby produces static html sites and then rehydrates them once loaded, which is what makes it feel so fast. Elm dynamically generates the html. There has been some work to generate static html from Elm - https://github.com/eeue56/elm-static-html - and there's no technical reason I'm aware of that prevents it from being taken as far as Gatsby does.

I've been doing some work on an Elm-based static site generator: https://korban.net/elm/elmstatic/

(It uses elm-static-html under the hood.)

Re: Small Assets without the Headache in Elm 0.19

#119

Post by choonkeat »

bobbby wrote: post #43
Skinney wrote: post #41

Earlier quoted context omitted.

It's in the release notes, as with every other open source project: https://github.com/elm/compiler/blob/master/upgrade-docs/0.1...

Thanks It explicitly says I'm not allowed to tell you that the auto upgrade doesn't work for me and there's no details on how to do it manually. Sigh I'll try again in a few months.. maybe.

but upgrade guide says its ok "talk things through" on the issues page, so I posted my solution there

https://github.com/avh4/elm-upgrade/issues/44

Re: Small Assets without the Headache in Elm 0.19

#120

Post by chenglou »

hazza1 wrote: post #97
tonyhb wrote: post #94

This sounds really cool, and it's exciting to see Elm come along! I always feel like Bucklescript and the Ocaml ecosystem doesn't get enough love when Elm crops up. Bucklescript has been doing aggressive dead code elimination for some time, and comes with the full type system of ocaml — plus easy JS interop: https://github.com/BuckleScript/bucklescript/wiki/Why-buckle... . As Elm develops I'm finding it harder and ha…

I've found the opposite, all the momentum seems to be with Reason - I don't hear of many new people picking up Elm. A release with smaller bundle is an amazing technical achievement but doesn't really address the underlying language and ecosystem issues.

I work on Reason. The front-end pie is big enough for Elm and Reason to coexist! Elm’s (hypothetical) loss isn’t a gain for Reason, and vice-versa.
Post reply on HN