Hacker News Reader

The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point.

[1] https://twitter.com/czaplic

We hired him because we'd already been using Elm for awhile and were so happy with it we wanted to contribute financially in addition to contributing with the libraries we open-source. :)

My boss wrote more about it here: http://tech.noredink.com/post/136615783598/welcome-evan

Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.

That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)

That's only been a recent development, rtfeldman has been using Elm for noredink for a long while before that.

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana".

Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple.

I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC.

This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language.

What reasonable response can anyone make to that claim, except "I really don't think that's what the language should focus on improving?"

> This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language.

That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, which is understood at this point to be largely a matter of personal preference. Typeclasses are a language semantics matter. They could add new levels of reuse for identical operations over different types, and they've done exactly that for other languages.

> What reasonable response can anyone make to that claim, except "I really don't think that's what the language should focus on improving?"

Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses to pick concrete examples from NoRedInk's open source Elm and show you how they could be improved, disproving your hypothesis that typeclasses wouldn't really help.

(edit: removed redundancy around "burden of proof")

> Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses

I agree! That would make for a much more straightforward discussion. :)

As an example, I see code all the time with many showX functions whose sole purpose is to turn come ADT into a string, this is the kind of boilerplate that would be reduced with some kind of abstraction mechanism.

Same for map operations, fold, etc.

Then there's other things that would benefit from further abstraction, like being able to compose apps or update functions without boilerplate.

These are just a few examples. What else do you need for it to feel like abstraction beyond simple functions is a useful feature?

Hi leshow, can you be more concrete? If I have a record

  `data Foo = Foo {fooA :: Text, fooB :: Text}`

then I must write a method `show :: Foo -> Text` for it. It is immaterial if I write

  `instance Show Foo where`
  `   show foo = (... implementation ...)`

or

  `shooFoo foo = (... implementation..)`

I save no code with typeclasses (at this point at least). (I do save code with the magic "deriving", but that's not part of the typesystem; it's just the compiler implicitly generating a bit of code for me.)

Likewise, map operations, fold. They need to be written and used.

I'm sceptical of Elm's claim that typeclasses aren't useful, but your post doesn't show what it sets out to, because it lacks concreteness.

Out of your post, it is only when you get to function composition that typeclasses can theoretically help — but the question isn't, can they theoretically help, it's do the help in practice.

So can you show some example? To meet the challenge and provide convincing evidence that a language without typeclasses is lacking, you would need to say "This is what the code is. And this is what it could be with typeclasses". Unless you do that, Noredink's claim that their code wouldn't be simplified with typeclasses stands.

I do not think you are obliged to do this. It is perfectly legitimate for you to ignore my message. But I think both sides can agree that this is what would be convincing to the anti-typeclassists.

!?

Of course you save no code on definitions. Some may even get more verbose.

You save code on usage, because you can use generic functions that will work for any instance of Show, instead of specifying them for every type.

To be clear, I'm not saying it's not useful! No need to convince me of that. :)

What I'm saying is that even useful features come with both benefits and drawbacks. For example, I think user-defined typeclasses would add significant complexity to the language and especially to the library ecosystem.

I'm not saying "these are worthless ideas," I'm saying "these benefits wouldn't improve my life enough to justify the cost." :)

Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is.

Perhaps you can't see the benefit and you're happy writing 10 implementations of "show", but don't claim there is no boilerplate.

For the record I don't care if it's typeclasses and I wouldn't want to see Elm turn into haskell. I'd just like some other type of mechanism for abstraction besides extracting to a function.

> Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is.

You seem very certain of this, so surely finding some real-world code examples to back it up should not be too difficult, yeah? :)

> Perhaps you can't see the benefit and you're happy writing 10 implementations of "show"

Like I said, I do see the benefit, but don't think it's worth the drawbacks.

Also, "deriving" saves you from writing "show" implementations, not typeclasses, so I'm not sure why you're bringing that up.

Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So it could be that half of your code is "library" code that could be open sourced - if it could be written generically with typeclasses.

For example, Rust has typeclasses (called traits) and Rust has a lot of libraries that do the right thing for you.

    fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option<T>
            where T: From<&'a str> {

        tuples.iter()
            .filter(apply(second, i))
            .map(first)
            .cloned()
            .map(<&str>::into)
            .fold1(T::op)

        //op just concatenates, but Cow<'a, str> does not satisfy Add
    }

Here, the functions first and second are taken from tool.rs, fold1 is from itertools, the type Monoid and the function op is taken from monoid.

I did have to write the delayed apply function myself, though. It's definition is:

    fn apply<A, B, C, F, G>(mut f: F, a: A) 
    -> impl FnMut(&B) -> C // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
             where F: FnMut(B) -> G, // must not be `for<'r> FnMut(&'r B) -> G`, because regular functions do not implement it
                   G: FnMut(A) -> C,
                   B: Copy, // for dereferencing
                   A: Clone {

        move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }

I think that could also be in a library somewhere

> I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case.

Of course. We publish quite a few such libraries, in fact. :)

Search for "NoRedInk" on http://package.elm-lang.org

The ridiculous comparison with parens only hurts your message.

I think a more apt comparison is comparing Elm to Go missing generics. Without do-notation I imagine that elm code is filled with a lot more awkward case branching.

My major question is: how do you write reusable code without type classes?

It's not really possible, as far as I can tell.

Well of course there are ways to write reusable code without type classes. But let's say for the sake of argument that that's really what you want. You can in fact implement ad-hoc polymorphism, or something very close to it, without type classes. Type classes can be seen as a way to implicitly add a set of values to scope, but this can be done explicitly by using a record type. Consider (I'm guessing at syntax, I don't know elm):

    -- Monoid as a record type
    type Monoid a = {
      empty: a,
      append: a -> a -> a
    }

    -- Using this to make a generic concatenator 
    mconcat : Monoid a -> [a] -> a
    mconcat m = foldl m.append m.empty

    -- Instance of Monoid for strings
    MString : Monoid String
    MString = {
      empty = "",
      append = (++)
    }

    -- Instance for ints
    MInt : Monoid Int
    MInt = {
      empty = 0,
      append = (+)
    }

    -- Use the generic function
    unlines : [String] -> String
    unlines = mconcat MString . intercalate "\n"

You'll note here that the actual function signature for mconcat looks almost exactly like its Haskell counterpart, just that the Monoid instance is a regular argument like any other.

Of course the downside is that you have to pass in the instance argument to any "type class polymorphic" function, so you lose a bit of conciseness but not much in the way of expressiveness. And you actually gain a bit, because instances are explicit (for example, you could make an instance of Monoid Int which used 1 and (*) instead).

I'm not sure if this pattern is used anywhere in extant Elm code, but this is a common way to implement type classes under the hood in languages that support them, and the approach seems doable in elm.

I'd like to refer you to the article that was posted earlier today on exactly this technique in Elm:

http://reasonablypolymorphic.com/blog/elm-is-wrong

I formulated it badly I guess.

I knew it's possible, s we discussed in the "Elm is wrong" comment thread though, this technique get's awkward quickly.

Are you trying to say that in the 30 years of time between the discovery of Lisp and the discovery of typeclasses, no one wrote reusable code?

Come now, don't hyperbolize: the statement is strictly about Elm, for which typeclasses are a proposed generics mechanism and for which userland generics don't exist right now.

As far as my sleep deprived brain remembers, Lisp is not statically typed... :P

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper (https://github.com/NoRedInk/take-home/wiki/Writing-your-firs...) that we cannot access?

Anyone can write a native module. You can't publish it, but you can use it in your project.[1]

[1] http://faq.elm-community.org/#why-doesnt-the-elm-compiler-fi...

Native modules are accessible to anyone. Unfortunately the link you provided is a little out of date despite being the top hit on google. Here is an example of a native module that works with 0.17 though: https://github.com/evancz/elm-markdown/blob/master/src/Nativ...

Yeah I figured the "rules" to write a native module for a while, but there is no tutorial, no support at all, which makes me rather uncomfortable, and I am never confident with that code.

Is that 55,000 lines of elm in a single large project or across all projects?

A single large project.

We've also split out several pieces of it into libraries that we've open-sourced, but I'm not counting those.

> Our Elm code is about as DRY as our JavaScript code

Not to be flippant, but that's not saying much.

JavaScript code is or can be extremely DRY. I have noticed this especially on a redux (inspired by Elm's architecture) codebase. The pitfall is that JavaScript is very unsafe and hard to read.

I've worked with TypeScript too, and there I started to notice more repitition and boilerplate, although IMO It is very well worth the safety.

Javascript is dynamically typed though.

And Typescript has generics or circumventing the type system with :any to enable reusability.

Exactly my point, dynamically typed means writing less boilerplate. At the cost of safeness and mantainability.

TypeScript's any is more for compatibility with js libs though.

Yes, in a sane codebase, you (almost) never use <any>. 98% of the time, if you type <any>, you're being lazy.