61–70 of 79 posts
Earlier quoted context omitted.
My major question is: how do you write reusable code without type classes? It's not really possible, as far as I can tell.
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?
Earlier quoted context omitted.
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 do…
I knew it's possible, s we discussed in the "Elm is wrong" comment thread though, this technique get's awkward quickly.
Earlier quoted context omitted.
> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…
Is that 55,000 lines of elm in a single large project or across all projects?
We've also split out several pieces of it into libraries that we've open-sourced, but I'm not counting those.
Earlier quoted context omitted.
> 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 examp…
Personally I find composability under The Elm Architecture more of an issue than pure language abstractions.
Successful companies have used plain st* languages like PHP and Java, thousands of companies that use the tool of the week go bust. There is no correlation (perhaps you should not use Assembler or COBOL for web development)
If there is any then companies that use the tool of the week do too many rewrites instead of focusing on delivering business value, the correlation is negative if any.
Earlier quoted context omitted.
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.
But the problem is what if this product will be maintained throughout years? Then to support it, you have definitely hire much more skilled engineer than for the same in stable JS framework. I completely understand about types, strict rules how to write Elm code, etc, but there are literally no guarantees that it will be the same after some time, that new developers will pick it up quickly, and, if you decide to rewrite it much later, there is a big chance that you'd have to rewrite it completely (this applies for JS too, but there are quite a lot of success stories of gradual integration of new framework).
To summarize, I don't think it is bad, it just doesn't scale and creates big technical debt, so you'd pay for it later; though it is a great chance to attract very skillfull and passionate developers – so, it is all about risk.
I'm guessing pragmatism and practicality is why they went with Elm over PureScript? If their backend is in Haskell then it seems like they have devs who know it well enough to use PS.
I actually find PureScript quite practical by design and goals (for example the ffi and readable generated code).
This typeclasses discussion reminds me a lot of complaints about Go's lack of generics. Even without this "glaring shortcoming" Go became the de facto winner in the ops space, by staying a simple language with a smaller learning surface. Elm could be walking down the same route. Personally I find composability under The Elm Architecture more of an issue than pure language abstractions.
Can you explain what you mean by this and possibly provide a source? I'd like to know how the different languages / platforms compare.