Elm's strengths and limitations vs Purescript

[Paul Chiusano]

Hi guys,

I'm a member of the Boston Haskell meetup, and we're planning a friendly "Elm vs Purescript" night. The idea is that one person (myself) will present on Elm, and another person will present on Purescript, and then we'll have a group discussion about the strengths and limitations of each.

What is interesting about Elm vs Purescript is that, on the one hand, Elm has a great story for largely avoiding the nastiness of dealing with the DOM and writing UIs in a declarative way that gives me the warm fuzzies. It also has some pretty great tooling (elm-reactor is really sweet). But, on the other hand, Elm the core language has some limitations compared to Purescript*:

* No typeclasses

* No higher-rank types, e.g. runST : (forall s . ST s a) -> a

* No higher-kinded types, e.g. data Free f a = Pure a | Free (f (Free f a))

* No existential types - It would be nice to define, say, data Sink a = forall r . Sink (a -> r) (Handle r)

* No pattern guards

* No tail call elimination, even for self-recursive calls. Actually, there's no way to write loops in pure Elm, nor is there a lazy list type (or any support for laziness) that would at least let you write loops via foldl / foldr on lazy lists.

If I had to single one thing out, it's the lack of typeclasses and/or higher-rank / higher-kinded types (which would at least let us use first-class dictionaries as a poor-man's typeclasses) that's the most serious limitation, responsible for a large amount of code duplication and missing functionality in the standard library, and in my own code. Though the other stuff is important, too.

As part of prepping my side of the talk, I'd like to get some sort of official comment about how likely each of these things are to be added to Elm, what the attitude is toward these features, and what the timeline for adding them would be. I've gotten the impression that avoiding adding some of these features might be a somewhat deliberate decision, out of fear that Haskell programmers and others with background in FP might then start using Elm and scaring off newcomers with talk of monads and category theory... or something like that. :) If that is the case, then some sort of official statement would be helpful so people can make decisions about where to invest resources.

Cheers,

Paul :)

[*] Neither language has GADTs, but that's a more complex feature, and less critical than the others IMO.

[Alexey Zlobin]

On first 4 points... That's like claiming that absence of pointers is limitation for Haskell.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/10/14 21:01, Alexey Zlobin wrote:
> On first 4 points... That's like claiming that absence of pointers
> is limitation for Haskell.

It would be. But Haskell has pointers.

- --
Alexander
alex...@plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRKomoACgkQRtClrXBQc7VwXwEAqzzkW0ApO8rTgDeiy1VaYeA5
HIMhWt2HQ80I+Mn62ZAA/1epN7wlsnIJUs0lHwb+xZQcnQv7jeQs5dUaqbDiVBTY
=xmQO
-----END PGP SIGNATURE-----

[Jeff Smits]

I obviously can't give an official statement. But I remember in earlier discussions about typeclass-like functionality and other fancy types, Evan mentioned he thinks there are more important things to focus on right now to gain adoption. Fancy types would be something to be added at a later time.

(Typeclasses will likely not be copied over from Haskell but instead be a combination of the existing extensible records and optional arguments as present in Agda. I'm personally looking forward to seeing if the extensible part of Elms records will increase the power of these typeclassy things :) )

--

[Dobes Vandermeer]

Yes, my understanding was that Evan is interested in solving the same problems that are solved by type classes, but the exact mechanism hasn't been decided.  He was also attracted to the "implicit parameters" approach.  But in any case I think there will be some form of ad-hoc polymorphism one day.

[Evan Czaplicki]

The decisions on types are deliberate. Since very very early on, type classes have been requested by Haskell programmers. My opinion is that these features create serious accessibility problems in Haskell, even for people such as myself who came to Haskell already knowing Scheme, Standard ML, and OCaml. I was three years in to Haskell before Monad Transformers were clear to me.

So I have always looked at these things not just as features to be implemented, but unsolved design problems. How do we present these ideas in a way that is super simple? How do we grow our community in a smart way?

A question to think about for type classes is, what is the best way to reuse variable names? Type classes, implicit arguments, and module functors all answer this question, but each comes with some unfortunate tradeoffs. My view here is that there is no need to rush. When our community collectively needs this kind of feature, we will be in a much better position to evaluate the trade-offs between these approaches for the problems we are facing in practice.

Until that time, I'd like to pursue the "scrap your type classes" approach which allows you to do explicit dictionary passing through some combination of higher-kinded polymorphism and rankN types. To me this is a minimal set of non-controversial features that get you a lot of what you want, so I think it makes sense to explore this route thoroughly before picking our poison with type classes, implicit args, or module functors.

I have put off the simpler type features partly because of prioritization decisions and partly because I do not yet feel confident that the pedagogy that must come with this power has been fully fleshed out. I know how I want to talk about these things, but I don't think I have communicated that clearly to the community yet, and I know for a fact that Haskell people will import their pedagogy unaltered if they can.

This has been the plan for ages, and hopefully that clarifies the prioritization of each of these type features. My opinion is that these are potentially detrimental to the kind of growth I want in Elm right now. If we get all the existing Haskell programmers to use Elm, we have not made a dent on the real goal, which is to get all the existing front-end programmers. To convince front-end people to take a look, other features are way more important. This is why I'm focusing on things like Elm Reactor, package management, and elm-html.

Optimization is uncontroversial and may become an increasingly high priority. Tail-call elimination is important, dead code elimination is important, etc. These are areas that have not been focused on because they have never been "the biggest issue", and because they are require non-trivial design choices within the compiler, making them hard to "slap on". As more people begin using Elm through elm-html, I can see these becoming most important pretty soon.

I don't think pattern guards are a question of expressiveness, so I see them as a nice-to-have. Even if the code was all written, I'd be hesitant to add them because they make some demands of syntax that I'm not certain about yet and I don't want to spend time on this kind of decision now. But I have no objection here besides it can be expressed already and it is a bit of a specialist feature.

Max New created a really nice Lazy library a while ago, but I did not think it was "time" yet. My view has mellowed as times have changed since then, but I still don't see it as a feature that will drive JS people to Elm at this point.

As a meta comment, I want people to focus their creative power on making cool stuff right now. The bulk of future users do not care if we have the coolest lazy data structures and fanciest types. They are not going to switch until they see that we have made cool apps. That's what Elm is for, and we need to demonstrate to people that it works before we show them all sorts of cool extras.

[Joey Eremondi]

The lack of higher-kinded-polymorphism is really the only one of those that is a downside for me, and even so, it's fairly minor. Basically, you can replace typeclasses with records of functions, and it solves a lot of problems, such as having to know about undecidable instances and the monomorphism restriction and conflicting instances and such. The only overhead is syntactic. Eventually, HKP will let us write a functor typeclass, but honestly, I doubt it comes up much in code. Really the place you want to be writing code that general is in libraries.

So I'd make sure that you discuss the pros and cons of Elm not having typeclasses.

I'm totally in agreement with the tail call issue, though I understand that it's a mostly technical reason that this hasn't been implemented yet.

Haskell is really walking the borderline between a strongly-typed and dependently-typed language (not that they're mutually exclusive). This is cool, but I think it's important to remember that there is still a niche for the benefits that you can get from a simpler type system, and the benefits of having something that will be more widely adopted by a user-base that's used to coding in JavaScript.

[Paul Chiusano]

I think I may have participated in some of those earlier discussions. :) At the time, it sounded very reasonable. The reason I'm now asking for more of an official statement and timeline is that I could see it being the case that there are always "other things more important". I'm just not sure what to expect for the future, and I'm not even sure if Evan himself is convinced of the value of these features. Having an official stance would be helpful to people who might be considering using Elm.

> there are more important things to focus on right now to gain adoption.

This is sort of a philosophical question, but is the primary goal a) to develop the best technology possible, or is the primary goal b) to make Elm popular and widely adopted? These things aren't always in conflict, but if they are perceived to be, I'd kind of like to know which goal wins out.

> (Typeclasses will likely not be copied over from Haskell but instead be a combination of the existing extensible records and optional arguments as present in Agda. I'm personally looking forward to seeing if the extensible part of Elms records will increase the power of these typeclassy things :) )

Scala basically used this approach, as it has first class modules with subtyping, and implicit parameters. The only thing extensible records buy you is it lets the interfaces be anonymous, rather than named. But this turns out to not be important, since any time you abstract over something you almost always want a named interface (with associated laws) anyway, otherwise you have no idea whether the implementation makes any sense! Typeclasses a la Haskell also provide a property that's very important (and somewhat underappreciated) - there is always a single, unique instance of a typeclass for a given type, which means you can reason about functions like `union :: Ord k => Set k -> Set k -> Set k`. Using implicit parameters (a la Scala) doesn't give you this guarantee - you can't be sure the two sets are ordered the same way!

That said, I'd be happy with anything that lets me define Monad, Applicative, and the like, so I can avoid repeating myself over and over again. :)

Paul

[Paul Chiusano]

> Until that time, I'd like to pursue the "scrap your type classes" approach which allows you to do explicit dictionary passing through some combination of higher-kinded polymorphism and rankN types. 

That seems like a reasonable approach to me. I too am not entirely happy with typeclasses and think there's room for other designs.

When do you think we can expect HKP and rank N types? Actually, can you give any kind of timeline for what you see as the non-controversial changes? 

> As a meta comment, I want people to focus their creative power on making cool stuff right now. The bulk of future users do not care if we have the coolest lazy data structures and fanciest types. They are not going to switch until they see that we have made cool apps. That's what Elm is for, and we need to demonstrate to people that it works before we show them all sorts of cool extras.

Evan, you make it sound like these features are totally unnecessary ("cool extras") but are just being requested by people who like "fancy types" for no good reason. I have to ask - do you actually think that? The reason people like these things is *because they are useful for building stuff*! In fact, if you want people to build cool stuff, providing a powerful language to do so is a pretty good strategy. :)

Also, even if "the bulk of users" don't care about fancy language features, they certainly do care about the existence of high quality libraries... and high quality libraries often use language features that are currently missing from Elm. I think I've brought up this same point before. It's sort of presenting a false dichotomy - we have to choose between the type theorists in their ivory towers, or the humble front end programmer trying to get something accomplished. Well, no, I don't accept that dichotomy! More powerful language features can benefit everyone.

Paul

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/oyrODCgYmQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[John Mayer]

So there are a couple of things in "Elm" which I largely consider to be orthogonal:

1. A runtime and library for dealing with signals, i.e. all of the "First-order FRP" stuff
2. A runtime and library for dealing with Elements, Forms - pretty much all of Elm's graphics (including Inputs/Handles which is coupled with the above)
3. A transpiler that adds static typing, algebraic data types, modules, and other stuff (remember: first-class functions + memory management are already part of JavaScript)
4. Tooling for delightful web development

I see PureScript as basically a language which focuses hard on #3, with the goal of mimicking Haskell, so it's not surprising that they're "ahead of us" in terms of sexy types. You could probably implement an FRP library in PureScript. Same with Elements. Nothing's really stopping you; let us know how it goes! Or fork Elm; whatever. Let's be real: I don't currently see a ton of people submitting PRs to add these features, nor do I envision a mailing list thread convincing Evan to change his priorities.

It's totally subjective, but from my vantage point (and I write real-world web programs, though that doesn't make me an absolute authority), what's important isn't the tower of abstractions, but rather the delightful experience of coding. When I wrote my first Elm program, I would say I appreciated FRP 60%, Elements and Forms 30%, and basic static typing 10%. And the type system was pretty bad back then! So I don't really buy into the need for all this. UIs are pretty narrow and the bulk of the code you write for UIs just doesn't need crazy libraries. It is by-and-large a bunch of plumbing and a bunch of declarative view code. Those are the kinds of things that real world web developers build, and in those tasks Elm does very well.

So yeah. I'm happy with saying that this stuff is just low priority "cool extras". And I definitely agree with Evan that the best way to help Elm today is by making cool applications rather than iterating on the language core.

[Kim-Ee Yeoh]

On 10/25/14, Evan Czaplicki <eva...@gmail.com> wrote:
> The decisions on types are deliberate. Since very very early on, type
> classes have been requested by Haskell programmers. My opinion is that
> these features create serious accessibility problems in Haskell, even for
> people such as myself who came to Haskell already knowing Scheme, Standard
> ML, and OCaml. I was three years in to Haskell before Monad Transformers
> were clear to me.

Worth making is the distinction between those who want type classes
because they want 'overloading' and those who want type classes to
manage effects monadically.

The 'overloading' requesters don't fit the profile of haskell
programmers, e.g. see

https://groups.google.com/forum/#!topic/elm-discuss/YLgfGhFaXxM

They 'don't really know Haskell', they say.

The type classes they want are straight out of 1988 Wadler and Blott:
no effects, no kinds. They want arithmetic overloading and they want
equality overloading.

This first group is often obscured by the second group who demand
FAM-my effects, possibly because the latter are more outspoken?

To return to Paul's request on help presenting Elm in the best light,
I'd separate the two concerns. Elm addresses overloading with an
archival quality combination of Miranda and SML, just as they were
explained in section 2 of the 1988 paper.

As for effects, that concern is more bleeding edge and the monad story
is one of many being explored. Elm focuses on one effect: the Signal,
to the exclusion of all others. Not having as many effects anyway,
overloading over them isn't as compelling as in a general-purpose
language like Haskell.


-- Kim-Ee

[Paul Chiusano]

John,

> When I wrote my first Elm program, I would say I appreciated FRP 60%, Elements and Forms 30%, and basic static typing 10%. 

I get what you're saying. And I won't try to convince you of the value of these features. I think we should just leave it at saying that it depends on the sort of code you write. Of course, you can write useful programs without any of the features I mentioned. But some people find these features extremely useful and rely on them heavily to good effect. I don't think it's fair to hint that these people aren't "real world" programmers (whatever that means exactly). That label unfortunately gets used a lot to discount people's experiences, basically anyone who finds "advanced" language features useful becomes by definition someone who isn't a "real world programmer" and is therefore someone whose experiences and views can be discounted. I consider this a very ugly part of tech culture, and it creates divisions between people that I don't think need to exist. (Sorry for the minor rant - I don't think your statements are coming from a bad place, this is just a topic I am sensitive about. :)

I don't really want this thread to drag on and turn into a debate about whether these features are useful or not and I'm sorry if my earlier comments added fuel to that fire. :) Evan has already responded to many of my questions, but the main thing I'd like to be able to close things out is some sort of answer to this clarifying question I asked earlier in the thread - 

> When do you think we can expect HKP and rank N types? Actually, can you give any kind of timeline for what you see as the non-controversial changes?

The answer could be "I don't know, ask me in a month or two" but something more definite one way or the other would be very helpful.

Thanks, and let me reiterate that I think Elm is a great project. Despite my complaints with the language, the platform has overall been a joy to use, and has gotten me excited about doing front-end development, something I've deliberately avoided for a long time. :) My wanting some of these features is coming from a place of hoping an already awesome platform becomes even more awesome!

Cheers,

Paul :)

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/oyrODCgYmQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Richard Feldman]

This is a topic very near and dear to me! Here is my exact timeline for coming to Elm:

1. Considered it 2 years ago for a major HTML5 Canvas project where we really wanted static typing. (Paul - ask Runar about that project sometime; he was on the back end.) Concluded Elm wasn't close enough to production-ready yet.
2. This year, heard about PureScript, got very excited. Eagerly planned to start my first major PureScript project as soon as purescript-react was ready.
3. purescript-react got tangled up in some API concerns and progress ground to a halt. (It remains stalled today, sadly.)
4. The "Blazing Fast HTML" post came out. Learned that elm-html was (A) already capable of implementing TodoMVC, (B) had a great API, and (C) benchmarked better than React and Om.
5. Started spending (without exaggeration) a simple majority of my free time rewriting a large side project in Elm.

I can't speak for anyone else on this list, but my passion is for making great user experiences. In general I like functional programming and static typing because they make my life easier as I pursue that goal, and in particular I like Elm because it's the most enjoyable experience I've ever had pursuing that goal. A language with Elm's present characteristics that is *usable right now* is an incredible breath of fresh air for anyone who's been choking down "what's the best option out there: Ember or Angular?" for so long.

The difference in priorities between Elm and PureScript has been huge for me. For example, Elm doesn't yet have a way to sequence effects, whereas PureScript's Eff monad provides an FFI to arbitrary JS effects. Despite this, my revealed preference is to write all my effectful code in JS ports and have access to elm-html for my display logic, as opposed to writing everything in PureScript but living without an elm-html analog. Building a great UX in a powerful language using only direct DOM manipulation is like cutting grass with a high-end toenail clipper: pretty soon even the rusty lawnmower of JavaScript starts sounding appealing.

I totally appreciate Paul's points about wanting more powerful features to make our lives easier when building real things in Elm. Long-term, I want those too! But code duplication is pretty far down the list of evils I'm used to suffering as a front-end Web developer, and it's not an exaggeration to say that I am literally using Elm today instead of PureScript because of the way its feature set has been prioritized.

My wish list for Elm has nothing to do with HKP or rank-N, because those make my Elm experience nicer and my Elm experience is already unfathomably nicer than the experience I'm used to--namely, JavaScript. What I want most are things that let me spend more time writing Elm and less time writing JavaScript! At a feature level that means things like sequencing effects, and at a community level that means selling points I can relay to my Team Imperative coworkers, to persuade them them that their experience with Elm will be much better than the experiences they've had trying to enter the (unfortunately newbie-hostile) world of FP in the past.

[Jonathan Leonard]

In my opinion, any language which forces code duplication on its users is either a) not yet fully formed or b) not powerful enough for my tastes. [And it does seem that Evan would like us to believe it is a) for as long as possible-- I share Paul's concern that this may always end up being the case]. As Richard pointed out, elm does have tremendous advantages so it doesn't make sense to ignore the language completely. Therefore, I think if Evan persists in refusing to admit 'advanced' features then he will ultimately find himself with a coffeescript (or sweet.js) on his hands and elm becoming a mere 'target'.  Ideally, someone would make a purescript <-> elm bridge so we could have the best of both worlds (although this may be rather difficult/impossible). Another option is that the already prolific frontend frameworks (React.js, Om, Reagent, Angular, etc) will just incorporate the best parts of elm and render it moot.

And I think the underlying motivation for keeping elm dumbed down is misguided. There are only two types of frontend developers:  those who have no formal CS background and those who do.  Dumbing down the language to go after the first group to the detriment of the second group is not prudent. Much better would be to educate the educatable and raise the quality of life for everyone. Going after the group of folks who can not or will not understand these advanced features doesn't seem like the best approach for a language that is already as unapproachable as it could ever hope to be for the very same 'target' audience it seeks.

--Jonathan

[Joey Eremondi]

Have you read this? Before you dismiss Evan's stance as misguided, make sure you fully understand it.

1. There are always limits to avoiding duplication. It's not like Elm forbids any generic code. You can still write functions and modules and all that fun stuff. And, you can still simulate typeclasses with records of functions. So saying that Elm forces code duplication is inaccurate: it can do what TypeClasses can, just with a bit more syntactic overhead, but in a way that I think comes with some serious advantages.

2. HKP will allow for more general code. However, applicative's infix zoo leads to some of the least comprehensible Haskell code I've ever seen, and monads have some serious issues (see Transormers). So this makes sense as a long term goal.

3. Being simple is not the same as being dumbed down.

4. In some cases, unnecessary generalization can be as bad as premature optimization.

5. Elm's mantra isn't that things should be dumbed down. It's that things should be planned, and when they're done, done right. Haskell has evolved from theory developments. That's great, but there are times you can tell it has a bunch of different ideas that have been cobbled together. It's module system is far from optimal. There's no good solution for combining monads. Haskell keeps introducing new notations (list comprehensions, do notation) then advising against using them.

If Elm hastily adds too many features, I think it risks becoming like C++: it has every feature you could possibly want, but put together in a way that makes them awkward to use, unable to change because of backwards compatibility.

[Jonathan Leonard]

On Sunday, October 26, 2014 3:59:16 PM UTC-7, Joey Eremondi wrote:

Have you read this? Before you dismiss Evan's stance as misguided, make sure you fully understand it.

Not sure about how that post is as relevant to this discussion but since you brought it up, here is my opinion on it: I don't consider enums, sum types, algebraic data types (both product and sum), type unions or our very own 'union type' to be advanced concepts. And it seems a little silly to spend so much time and energy thinking about how to name this 'new thing' when pretty much any programmer I know could spend about 5 minutes on Wikipedia and instantly grok ADTs (and whatever one chooses to name them). But the list of features that Paul mentions in this thread is definitely *more* advanced [even if slightly] than mere ADTs and it's Evan's position with respect to those features (and not ADTs) that I responded to.

1. There are always limits to avoiding duplication. It's not like Elm forbids any generic code. You can still write functions and modules and all that fun stuff.

Are functions generic? And modules first-class (a la SML)? Functions and modules are fine for avoiding duplication at one abstraction level but experienced programmers quickly find that they would like other degrees of freedom (namely higher orders).

And, you can still simulate typeclasses with records of functions. So saying that Elm forces code duplication is inaccurate: it can do what TypeClasses can, just with a bit more syntactic overhead, but in a way that I think comes with some serious advantages.

Actually it was Richard who brought up the point that elm forces duplication. I just assumed that was accepted as a fact (and when I wrote some code early on in elm, it certainly could have benefitted from typeclasses).

2. HKP will allow for more general code. However, applicative's infix zoo leads to some of the least comprehensible Haskell code I've ever seen, and monads have some serious issues (see Transformers). So this makes sense as a long term goal.

The existence of the ability of some people to use advanced features to write a mess should not preclude everyone else being permitted to use those features. After all, there are many skillful people in writing messes in even the lowest orders of programming logic (e.g., enterprise Java developers). It only takes a single degree of freedom for some!

3. Being simple is not the same as being dumbed down.

Agreed. But, as was the case with 'union type', the perfect seems to be the enemy of the good. I think it takes a certain level of vanity in fact to think that innovation is desirable or even possible in *every* single language feature. And while everyone debates endlessly, some very basic features are lacking.

4. In some cases, unnecessary generalization can be as bad as premature optimization.

There's never been an instance in my life when I've factored something and regretted it later. I know there has been a sizable backlash against DRY recently but in my opinion it has no merit (and I've never seen the evidence in my own experience of something being 'over factored'). I would love to see examples of this (but every time anyone has put one forth it has been a matter of 'incorrectly factored' rather than 'over factored').

5. Elm's mantra isn't that things should be dumbed down. It's that things should be planned, and when they're done, done right. Haskell has evolved from theory developments. That's great, but there are times you can tell it has a bunch of different ideas that have been cobbled together. It's module system is far from optimal. There's no good solution for combining monads. Haskell keeps introducing new notations (list comprehensions, do notation) then advising against using them.

If Elm hastily adds too many features, I think it risks becoming like C++: it has every feature you could possibly want, but put together in a way that makes them awkward to use, unable to change because of backwards compatibility.

I actually agree entirely with this paragraph. And I would add Scala to the list of 'bad examples' as well. But in my opinion something like typeclasses is rather well established and basic.

--Jonathan

[John Mayer]

I think that this thread is doing a pretty good job of bringing to the surface some great differences in opinion. Allow me to summarize so that we can debate the right things:

1) Differences in goals - "...we have not made a dent on the real goal, which is to get all the existing front-end programmers"

Evan wants Elm to grow in a way that predominantly converts the average front-end JavaScript programmer, rather than the average functional programmer. The average front-end programmer has access to high quality libraries and excellent tooling. The average functional programmer (and we'll use Haskell as example) has access to awesome language features for structuring code in elegant ways. In order to appeal to either group, you need to compete on the appropriate fronts.

The point is that it doesn't make sense to argue about the tasks (what to implement) rather than the goals (who is Elm targeting for growth in adoption) because Evan is going to spend his time to advance his goals. So either 1) directly argue against Evan's goals (to whom should Elm appeal) or 2) advance your own goals by doing the tasks yourself (i.e. open a pull request that implements type features, or rewrite FRP and Graphics in PureScript).

Q: Does Evan have the right goals? If not, what are the right goals?

Q: Are Evan's fears about the inapproachability of Haskell valid?

2) Disagreement about the consequences of adding advanced type features

2a) "My opinion is that these features create serious accessibility problems in Haskell"

I interpret that to mean that Evan believes that adding this functionality makes the language more difficult to use for everybody. A possible explanation for Evan's concerns is that once these features are included, then they will start showing up in all of the APIs of the major standard libraries, which would make the entire language more mentally demanding to use, thus alienating the average front-end programmer. 

Q: Is it true that advanced type features add more costs than technical beauty/efficiency benefits, to the detriment of adoption?

2b) "I do not yet feel confident that the pedagogy that must come with this power has been fully fleshed out"

I interpret that to mean that Evan believes that we shouldn't add an advanced feature until we know for sure we have a good way to explain it to raw beginner programmers.

Q: Is it true (and is it important) that the best way to teach programmers how to use advanced type features is largely undecided?

2c) "My view here is that there is no need to rush. When our community collectively needs this kind of feature"

This is the point of contention that everybody is addressing, but approaching from different personal perspectives. Note how, in the presence or absence of the above contexts, particularly that of the goals of Elm, this question changes:

Q: Does Elm need advanced type features today?

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

[Jonathan Leonard]

On Sunday, October 26, 2014 7:17:14 PM UTC-7, John Mayer wrote:

I think that this thread is doing a pretty good job of bringing to the surface some great differences in opinion. Allow me to summarize so that we can debate the right things:

1) Differences in goals - "...we have not made a dent on the real goal, which is to get all the existing front-end programmers"

Evan wants Elm to grow in a way that predominantly converts the average front-end JavaScript programmer, rather than the average functional programmer. The average front-end programmer has access to high quality libraries and excellent tooling. The average functional programmer (and we'll use Haskell as example) has access to awesome language features for structuring code in elegant ways. In order to appeal to either group, you need to compete on the appropriate fronts.

The point is that it doesn't make sense to argue about the tasks (what to implement) rather than the goals (who is Elm targeting for growth in adoption) because Evan is going to spend his time to advance his goals. So either 1) directly argue against Evan's goals (to whom should Elm appeal) or 2) advance your own goals by doing the tasks yourself (i.e. open a pull request that implements type features, or rewrite FRP and Graphics in PureScript).

Note that I did directly argue (albeit very briefly) against Evan's goals in my original post.

Q: Does Evan have the right goals? If not, what are the right goals?

No, the goal should not be to convert existing frontend developers to elm. The goal should be to produce elegant solutions to the problems that frontend developers face. If that means that some of the frontend developers are going to have to do some learning, well, so be it-- it's sort of a fact of life in this industry. I think the goal of purifying and simplifying the concepts and features/syntaxes imported from Haskell is laudable and should be furthered/supported.

Q: Are Evan's fears about the inapproachability of Haskell valid?

No. I think several people have mentioned that they had no trouble approaching Haskell (and I put myself in that group as well).

2) Disagreement about the consequences of adding advanced type features

2a) "My opinion is that these features create serious accessibility problems in Haskell"

I interpret that to mean that Evan believes that adding this functionality makes the language more difficult to use for everybody. A possible explanation for Evan's concerns is that once these features are included, then they will start showing up in all of the APIs of the major standard libraries, which would make the entire language more mentally demanding to use, thus alienating the average front-end programmer. 

The nice thing about libraries is that they (just like the features we are debating) are optional. If you don't want to learn advanced features, don't use advanced libraries that use them. But I think the real hackers out there (in the PG sense of the word) like advanced features and like learning them.

Q: Is it true that advanced type features add more costs than technical beauty/efficiency benefits, to the detriment of adoption?

2b) "I do not yet feel confident that the pedagogy that must come with this power has been fully fleshed out"

I interpret that to mean that Evan believes that we shouldn't add an advanced feature until we know for sure we have a good way to explain it to raw beginner programmers.

Features are mechanistic. They don't like your anthromorphizing about them anyway. Just look at them like little moving parts/ gears/ etc in an intricate Swiss timepiece. Analogies do more to confuse than just plain explanation/definition.

Q: Is it true (and is it important) that the best way to teach programmers how to use advanced type features is largely undecided?

2c) "My view here is that there is no need to rush. When our community collectively needs this kind of feature"

This is the point of contention that everybody is addressing, but approaching from different personal perspectives. Note how, in the presence or absence of the above contexts, particularly that of the goals of Elm, this question changes:

No, that's not true. There is a plethora of material on advanced Haskell features out there.

Q: Does Elm need advanced type features today?

'Need' looks very different from the potent end of the 'power continuum'-- advanced programmers (or 'library authors' if you prefer [but everyone should strive to become their own best 'library author']) don't like operating as 'human compilers'. They prefer to have the machines do everything possible for the machines to do.

--Jonathan

[Joey Eremondi]

Ahhh, sorry. The ADT post, about half way down Evan has a message where he nicely sums up the Elm position. I thought I'd linked to it directly...

[Alexey Zlobin]

>> Q: Is it true (and is it important) that the best way to teach programmers how to use advanced type features is largely undecided?

> No, that's not true. There is a plethora of material on advanced Haskell features out there.

Bunch of materials isn't a course. Clean goal, structure and gentle repetition mandatory to make a course approachable by practicing industry engineers. Agenda and feedback are also attract people. "plethora of material" is only useful for full-time students with geeky mindset, who have time and will to research gaps and waste on useless duplication in random flow of articles.

[Joey Eremondi]

I attended a very interesting talk by Greg Wilson at Splash 2013 who said that one of the main barriers to industry incorporating research was the lack of open access publications. Once students leave their university it's much harder to get at recent research without an institutional subscription.

[John Mayer]

Ok, great.

"No, the goal should not be to convert existing frontend developers to elm."

I'm pretty sure that this comes from the greater goal of language adoption and applying the technique of focusing on the largest market. Which of those is flawed? That language adoption is a bad goal, or that focusing on the average developer (largest market) is not the best way to drive total adoption?

[Jonathan Leonard]

On Monday, October 27, 2014 3:05:28 AM UTC-7, Alexey Zlobin wrote:

>> Q: Is it true (and is it important) that the best way to teach programmers how to use advanced type features is largely undecided?
> No, that's not true. There is a plethora of material on advanced Haskell features out there.

Bunch of materials isn't a course. Clean goal, structure and gentle repetition mandatory to make a course approachable by practicing industry engineers. Agenda and feedback are also attract people. "plethora of material" is only useful for full-time students with geeky mindset, who have time and will to research gaps and waste on useless duplication in random flow of articles.

I was actually including courses/tutorials and "clean goal, structure and gentle repetition" in the "bunch of material" designation. I'm not sure why you think the material would only be useful to students. I am a professional and I rely on research material a great deal during my day to day developments (especially when starting a new language). Researching gaps and divining the signal from the noise is part of what makes a good researcher and professional. School itself should have given professionals the tools they need to do such throughout the rest of their lives (but I'm sure it can be learned on the job remedially as well).

--Jonathan

[Jonathan Leonard]

I definitely believe that if you solve the problems in an elegant fashion, popularity will take care of itself. It always strikes me as highly ironic how many people like to tell themselves "I'm smart enough to figure this out and use it but no one else is." It is really a high form of arrogance. And, even if that were so, do you think Einstein or Leibnitz or van Gogh or Mozart or Newton or Hawkings would care if their ideas were "too difficult for the world to understand"? I think that these guys would just go ahead and unleash their genius on the world and leave it up to the world to figure it out (if it ever does). So, if we truly are dealing with genius here that is what I would suggest we do as well. And, if it isn't genius territory, then don't worry about the world-- they will be able to understand it-- just make it as clean and simple as possible for your own tastes and do good marketing.

--Jonathan

[Joey Eremondi]

Newton invented calculus, but Leibniz notation got adopted because it was easier to use and understand. Genius is useless if it's not accessible.

[Jonathan Leonard]

Take another look:

http://en.wikipedia.org/wiki/Notation_for_differentiation

Newtonian notation is used in certain fields (and quick glance at the two as a professional with requisite understandings shows a trivial translation between).

Also, the "clean and simple as possible for your own tastes" qualification applies to making things accessible. But absent features will *never* be accessible. The debate here is about whether to add features or not. By all means, make the features accessible-- but in order to do that you must actually implement/expose the features (in some way).

--Jonathan

[Sean Corfield]

On Oct 27, 2014, at 11:54 AM, Jonathan Leonard <joha...@gmail.com> wrote:
> I definitely believe that if you solve the problems in an elegant fashion, popularity will take care of itself.

And yet this is the crux of the issue: Haskell has elegant solutions to all sorts of problems people have in the real world and yet it remains "unpopular". There are all sorts of reasons for that, and the dismissiveness that many Haskell advocates have for several of those reasons is also one of those reasons.

Time will tell, ultimately, whether Evan’s goals with Elm (including approachability and the desire to convert front end programmers) are going to be realized, but _I_ think they stand a better chance than Haskell's (or PureScript’s) desire to "build it and they will come", where "it" is the elegantly solved problem…

Comparing Elm to PureScript is an interesting academic exercise (as are all language comparisons) and if you’re presenting to a Haskell meetup, they’re going to be inherently more favorable to PureScript and view Elm’s goals as "lesser", in the same way that they already view nearly all other languages as "lesser". That’s fine. No one should criticize Haskell developers for preferring languages that are "more like" Haskell. Just bear in mind the set of Haskell developers is a lot smaller than the set of front end developers that Elm is targeting.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Paul Chiusano]

Hi everyone, 

This is turning into an interesting discussion and I'm very tempted to wade in, but honestly, I'd just like an answer to my earlier question about timeline for the non-controversial features. HKP + rank-N + the existing record system would at least provide a path for addressing most of the immediate code duplication problems and would, incidentally, be a nice testbed to see how well that works out. Whatever people come up with using this combination of features, it doesn't need to be used by the standard library, and therefore I don't think it needs to be something that newcomers are exposed to right away, if that is a concern. In short, it seems like a win-win.

Paul :)

[Dobes Vandermeer]

On Mon, Oct 27, 2014 at 1:05 PM, Sean Corfield <se...@corfield.org> wrote:

On Oct 27, 2014, at 11:54 AM, Jonathan Leonard <joha...@gmail.com> wrote:
> I definitely believe that if you solve the problems in an elegant fashion, popularity will take care of itself.

And yet this is the crux of the issue: Haskell has elegant solutions to all sorts of problems people have in the real world and yet it remains "unpopular". There are all sorts of reasons for that, and the dismissiveness that many Haskell advocates have for several of those reasons is also one of those reasons.

Time will tell, ultimately, whether Evan’s goals with Elm (including approachability and the desire to convert front end programmers) are going to be realized, but _I_ think they stand a better chance than Haskell's (or PureScript’s) desire to "build it and they will come", where "it" is the elegantly solved problem…

Comparing Elm to PureScript is an interesting academic exercise (as are all language comparisons) and if you’re presenting to a Haskell meetup, they’re going to be inherently more favorable to PureScript and view Elm’s goals as "lesser", in the same way that they already view nearly all other languages as "lesser". That’s fine. No one should criticize Haskell developers for preferring languages that are "more like" Haskell. Just bear in mind the set of Haskell developers is a lot smaller than the set of front end developers that Elm is targeting.

It seems like historically it isn't the "elegant" languages that catch on, not by a long shot.  Just take a look at C, C++, Javascript, Java, Ruby, and Python - some of the most popular programming languages of the last few decades.  None of them are especially great examples of carefully researched and designed language that let people create the most elegant solutions.  If one looks closely there were probably seemingly languages available at the time that could have fit the bill.

Actually if you look closely at these languages, they caught on for different reasons.

Javascript caught on because it was built into a web browser and the other browser makers adopted it as well.  This is sort of the "king maker" approach to popularity - your language gets "picked" by someone or something that is popular for other reasons which drives wide adoption.  I believe C and Ruby followed this path as well, with UNIX and with Ruby on Rails.

The story around Java is a bit more complicated, but for myself personally Java originally took off because of its cross-platform capabilities and its tools and libraries.  C++ was great at cross-platform but didn't come out of the box with many useful classes like sockets, hash tables, and so on.  And C++ wasn't garbage collected, which adds a whole new class of bugs to hunt down.  Python and Ruby weren't really around and it seems like most other languages we were aware of couldn't run very well on Windows, Linux, AND Solaris.  On the tools side, Java developed some great IDEs with as-you-type error checking and refactoring tools that have yet to be matched by even the best Python and Ruby IDEs.

Python I think took off because of its really nice libraries, it was very suitable as a scripting language to replace bash scripts because of its simple but powerful file manipulation libraries, yet it had enough cool features to scale up to writing real applications, which I now use it for.

As for Elm, I don't know what it's popularity story would be... but I doubt that it will solely be based on solving the problems in an elegant fashion.  It's probably something else that catches people's attention, like the time travelling debugger.  Even if the language lacks type classes something like that might do the trick.  Or not ...

 

[Evan Czaplicki]

The plan goes until mid-February right now. The plan is to finish up elm-package and elm-make. There are a bunch of improvements to the standard libraries in the pipeline along with these changes. I'm not sure when that release will happen. We'd like to improve the HTTP story in the Nov/Dec cycle so maybe that'll all get bundled together. All of these tasks may affect the prioritization of what comes later, possibly touching on stuff described here. In Jan/Feb I'll be in Budapest writing Elm code for Prezi stuff, hopefully getting the team in a good place and writing a nice blog post about what's going on there.

At that time, we'll assess what "the most important thing is" and go from there. The things I learn seeing how dreamwriter progresses and from CircuitHub and from Prezi and from anyone else making stuff will be the primary data for prioritization.

I feel like I'm just repeating myself here, so hopefully that answers your question about timing. That's the best timeline I can give at this time.

A weird thing here is that you have framed these features as if there are no tradeoffs, like other features need feature requests and concrete examples and evidence, but your features are exempt for some reason. Like what makes this more important than "a nice way to describe transitions and animations"? (rhetorical question!!!) In any case, I'm booked for a couple months so I'd prefer that we revisit this when it's plausible for me to work on it. More generally, these are things I think about, and I'm doing the best I can to progress quickly!

[Jonathan Leonard]

Yes, but the main problem of the approach you mention is that the people who would be put off by typeclasses and such are most likely already put off by elm-- after all it is quite a divergence from the usual they are accustomed to. And the people who aren't already put off by elm would greatly appreciate more advanced features. I think you can certainly have both-- there's no need to inundate newcomers will all of the advanced features either-- most of the introductory tutorials and all the compelling demos (reverse debugging, live coding, etc) would remain the main attraction without modification. It's just that more experienced developers would be happier with more advanced features and newcomers can venture into that space if and when they please.

--Jonathan

[Paul Chiusano]

Hi Evan,

Okay, thanks for the reply. And I appreciate all the hard work you are putting into Elm!

> A weird thing here is that you have framed these features as if there are no tradeoffs, like other features need feature requests and concrete examples and evidence, but your features are exempt for some reason. Like what makes this more important than "a nice way to describe transitions and animations"? (rhetorical question!!!)

I did not mean to imply that there are no tradeoffs - there is definitely a limited amount of your time and an infinite list of things to do, so you have to prioritize. :) But are you asking why it is useful to be able to define abstractions like Applicative, Monad, and Traversable (whether via typeclasses or HKP + rank-N types + records)? And are you saying we need to justify the desire to define these abstractions with "concrete examples and evidence"? I'd be happy to do that (and I'm sure many others could help out), but you have to recognize that functional programmers have been using these abstractions for many years, in every typed functional language that supports them, and they've proven tremendously valuable and useful! (independent of IO) I consider them to be fundamental to computing, in fact I like to joke that if aliens exist, they have probably discovered monads, also. :) And even if one doesn't have experience using these sorts of abstractions, it can be shown that they solve a code duplication problem that would otherwise exist (e.g., functions like lift3 and sequence can be defined once and for all, for all Applicatives, rather than once for every data type).

Here's something to consider when prioritizing work - gaps in libraries are easy to work around. Many members of the community can easily write libraries that don't yet exist. Libraries are just normal Elm + JS code, so if I encounter a situation where there isn't a library for what I want, I can write it! But very few people can add new language features (like those that involve making major changes to the typechecker). So one way of thinking about prioritization is that it's beneficial to work on tasks that remove yourself as a bottleneck so that the community can proceed on development in a more distributed, massively parallel fashion. :) I also think that giving library writers powerful tools and ways to avoid repeating themselves is a good way to attract people to Elm who are willing and able to write high-quality libraries. The diversity of approaches to libraries can be a good thing as designs are being worked out, and it gives you more to draw on when deciding on designs for the standard library. 

Basically, there are *always* going to be more libraries and library functionality that need writing. But when you write a library, you've just solved one problem. Features like HKP + rank-N types / typeclasses are like an investment in the whole community, and they can have huge leverage.

Paul :)

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/oyrODCgYmQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Jonathan Leonard]

On Monday, October 27, 2014 1:39:29 PM UTC-7, Dobes Vandermeer wrote:

On Mon, Oct 27, 2014 at 1:05 PM, Sean Corfield <se...@corfield.org> wrote:

On Oct 27, 2014, at 11:54 AM, Jonathan Leonard <joha...@gmail.com> wrote:
> I definitely believe that if you solve the problems in an elegant fashion, popularity will take care of itself.

And yet this is the crux of the issue: Haskell has elegant solutions to all sorts of problems people have in the real world and yet it remains "unpopular". There are all sorts of reasons for that, and the dismissiveness that many Haskell advocates have for several of those reasons is also one of those reasons.

I don't believe the final chapter is written yet with respect to Haskell--I still think its best days lie ahead. And, one could say that it has already exerted a tremendous influence on the wider industry (reactive programming, optional lazy evaluation over collections, async/await notation and LINQ in C# (via F#), for comprehensions in Scala, and the list goes on...).

Time will tell, ultimately, whether Evan’s goals with Elm (including approachability and the desire to convert front end programmers) are going to be realized, but _I_ think they stand a better chance than Haskell's (or PureScript’s) desire to "build it and they will come", where "it" is the elegantly solved problem…

Comparing Elm to PureScript is an interesting academic exercise (as are all language comparisons) and if you’re presenting to a Haskell meetup, they’re going to be inherently more favorable to PureScript and view Elm’s goals as "lesser", in the same way that they already view nearly all other languages as "lesser". That’s fine. No one should criticize Haskell developers for preferring languages that are "more like" Haskell. Just bear in mind the set of Haskell developers is a lot smaller than the set of front end developers that Elm is targeting.

It seems like historically it isn't the "elegant" languages that catch on, not by a long shot.  Just take a look at C, C++, Javascript, Java, Ruby, and Python - some of the most popular programming languages of the last few decades.  None of them are especially great examples of carefully researched and designed language that let people create the most elegant solutions.  If one looks closely there were probably seemingly languages available at the time that could have fit the bill.

Of that list actually Ruby and Python aren't all that bad (and Javascript is mostly equivalent sans all the quirks). The success of these dynamic languages in fact probably was a reaction to the unwieldy compilation and inflexibility of C/C++. But one could also look at the success of these languages as the beginning of the ascendence of LISP to its rightful, more prominent place on the programming language landscape. And with Clojure came along next to essentially complete the circle. The same could very well happen with Haskell (i.e., the public finally realizes its mistake in hasty dismissal). Maybe Evan will be Haskell's Rich Hickey.

Actually if you look closely at these languages, they caught on for different reasons.

Javascript caught on because it was built into a web browser and the other browser makers adopted it as well.  This is sort of the "king maker" approach to popularity - your language gets "picked" by someone or something that is popular for other reasons which drives wide adoption.  I believe C and Ruby followed this path as well, with UNIX and with Ruby on Rails.

Yes, but Ruby on Rails was only possible with a sufficiently powerful language (Perl, Python or any LISP dialect would also have sufficed but the public perception of LISP probably would have held that back). But, yes, it was pretty much luck that DHH chose to use Ruby instead of the many other viable languages.

[Laszlo Pandy]

On Tue, Oct 28, 2014 at 4:15 AM, Jonathan Leonard <joha...@gmail.com> wrote:

Yes, but the main problem of the approach you mention is that the people who would be put off by typeclasses and such are most likely already put off by elm

I think this is the core of the issue where we will have to agree to disagree. I don't believe that the people who would be put off by typeclasses will be put off by Elm.

The whole point of Elm is to make functional programming accessible to a wider audience who of people who are put off by Haskell. If you say that this audience doesn't exist, then what is the point of Elm? Why don't we all just use Fay or PureScript?

Since we don't have any data on either side to tell whether that audience exists or not, I think we will just have to agree to disagree.
 

[Sean Corfield]

On Oct 27, 2014, at 10:00 PM, Jonathan Leonard <joha...@gmail.com> wrote:
> I don't believe the final chapter is written yet with respect to Haskell--I still think its best days lie ahead.

Quite possibly true - and I certainly wouldn’t be upset if Haskell went on to become hugely popular / mainstream. As I’ve said a few times on this list, I was pretty excited when Haskell appeared and hoped it would help FP go mainstream :)

> And, one could say that it has already exerted a tremendous influence on the wider industry (reactive programming, optional lazy evaluation over collections, async/await notation and LINQ in C# (via F#), for comprehensions in Scala, and the list goes on…).

And you could say that earlier languages (Hope, ML, KRC, SASL, Miranda) exerted a tremendous influence too - particularly Miranda, which as a piece of proprietary software was one of the reasons that Haskell came to exist in the first place.

(SASL and Miranda were the direct influences on my functional language, SURE, which was used to teach FP to undergraduates for a few years, in the mid-80’s, at my university but never saw the light of day outside that campus!)

[Jonathan Leonard]

On Tuesday, October 28, 2014 3:10:48 AM UTC-7, Laszlo Pandy wrote:

On Tue, Oct 28, 2014 at 4:15 AM, Jonathan Leonard <joha...@gmail.com> wrote:

Yes, but the main problem of the approach you mention is that the people who would be put off by typeclasses and such are most likely already put off by elm

I think this is the core of the issue where we will have to agree to disagree. I don't believe that the people who would be put off by typeclasses will be put off by Elm.

Ok, let's. But first let's agree on what we're agreeing to disagree on. Allow me to summarize:

Your (and the official elm position) is:

There exists a large constituency of frontend programmers who:

a) are comfortable with first-order types just not higher order types.

b) are comfortable with higher-order logic/functions but cannot imagine how the same could apply to the type system.

c) are not willing to educate themselves with respect to higher orders and types.

d) are comfortable with quite a lot of abstraction really just not too much of it.

My position is that yes this constituency does not exist (or is in fact quite small). We have to exclude the following from the above group:

a) extremist anti-types Rubyists, Pythonistas etc. These people will never be won (unless they suddenly see the value of type inferrence). They are essentially the 47%.

b) middle-aged (or older) C++ programmers comfortable with template metaprogramming.

c) non-professional programmers (they would not meet requirements a, b & d above and would likely be the group I referred to as being "already turned off" on elm).

The only group that remains (and that I think you are going after in fact) would be millennials with a CS degree who have only ever worked professionally in Javascript, Python or Ruby.

My experience with this group is that they are in fact a curious and willing to learn group (assuming of course that the extremist anti-types dynamic guys haven't gotten a hold of them--which should be the case as their CS program would most likely have covered why types are good).

Is that a fair summary? 

--Jonathan

[Jonathan Leonard]

On Tuesday, October 28, 2014 3:10:48 AM UTC-7, Laszlo Pandy wrote:

On Tue, Oct 28, 2014 at 4:15 AM, Jonathan Leonard <joha...@gmail.com> wrote:

Yes, but the main problem of the approach you mention is that the people who would be put off by typeclasses and such are most likely already put off by elm

I think this is the core of the issue where we will have to agree to disagree. I don't believe that the people who would be put off by typeclasses will be put off by Elm.

The whole point of Elm is to make functional programming accessible to a wider audience who of people who are put off by Haskell. If you say that this audience doesn't exist, then what is the point of Elm? Why don't we all just use Fay or PureScript?

Oops, I forgot to respond this one in the last post. I think elm's novelty lies in a) its implementation of FRP (Signals and such) b) elegant [integrated] handling of html/view/styles and c) the reverse debugger and other such IDE features that are opened up as possibilities due to a). Fay & Purescript (and I'd throw ghcjs in there as well) don't have those (but if they were to suddenly get them, then, yes, I think elm would lose most of its appeal).

[John Mayer]

Looks like something's in the works:

https://github.com/bodil/purescript-signal

Haven't taken a close look, but they did adopt my squiggle notation!

--

[Alex Neslusan]

I'm a non-professional hobbyist programmer without any formal training and I got into Elm. I even convinced a couple of friends in the exact same hobbyist with no training category to switch from doing stuff in Python to checking out Elm and they really like it.

[Rudi Chen]

Jonathan, if there is a narrow range of group of people that are curious and comfortable with higher-order functions and other functional features, but just not enough to learn higher-order types, it would indeed be a very small group of people. I would certainly assume that if they learned that much, why not all the way through - it's not that much more to learn. Am I understanding your summary of Elm's position correctly?

Now, if Elm goes after that group of people, and only that group of people, it will seem like wasted effort.

Could Elm go after people that have no experience at all with any functional language constructs? Maybe at most a Javascript lambda copied over from some StackOverflow answer. Seems difficult - I have a fair amount of experience with functional programming, but am still far from my usual level of programming productivity when I use Elm. But I learned functional programming somewhere. My first exposure was to F# (I used to be a C# person), but it could have been Elm if it existed 3 years ago. Is there any fundamental reason about Elm why I wouldn't have been able to learn awesome FP ideas from Elm instead of F#? If not, why would I need to be comfortable with FP features prior to learning Elm? I just never heard of them before. And at the time, my level of mathematical education was still limited to computing derivatives and integrals.

Let's look at Rubyists, Pythonistas, etc. I don't have any numbers, but I think the 47% number you gave is in the right ballpark, as far as front-end developers are concerned. I've met a couple of people your refer to as extremist, who sprout about the virtues of their language even though they don't really know anything other than Java (one of the most verbose languages out there). Is 100% of that 47% of dynamic language users all extremists? Have the majority of them even looked at a functional programming language before? If they haven't, is there any reason they can't be sold on Elm (or Haskell, or OCaml, or ...)?

Similarly, if we consider the group of people using imperative, statically typed languages (C++ in your example, I assume we could also include Java, C#, Obj-C, etc users). Have most of them even looked at functional programming languages before to decide they didn't like it?

But let's assume all those people are indeed lost causes. Well, there's still college students who haven't learned much of any programming language, thus don't have an opinion of any of them.

I'm just a nobody who has never worked a full-time job in the software industry, but it doesn't look to me that Elm can only target hardcore functional programmers.

--

[Jonathan Leonard]

Hi Rudi,

Thanks for the response and the perspective. I should say that the 47% number was probably just a lame attempt at a joke (or at least an American-centric one). See:

https://www.youtube.com/watch?v=M2gvY2wqI7M

:)

[But it may in fact be the proportion of people who will never be convinced that types are good].

Regarding your point (and Alex's) about non-professionals:

The way I see it there are two types of non-professionals out there: those who want to grow and learn and those who are content to just hack around (i.e., those for whom technology is just a means to an end and have no desire to dive in and learn more than what they perceive to be the absolute bare minimum). I would guess from your responses (and the fact that you are here at all) that you guys would fall into the former category. And when I listed non-professionals previously, I was referring to the second type of non-professional.

And I think when we drill down into that category the path to enlightenment is the same as for formally-educated CS students. By following tutorials and reading papers/books/etc, this group will quickly find themselves in that narrow group that you mentioned (and they must at least already be in that narrow group if they are able to use elm at all) and from there will be just fine moving further into advanced FP concepts. As you rightly put it, there's no reason to stop at first-order types if you understand higher-order logic.

--Jonathan

[Jonathan Leonard]

P.S. Just to clarify: yourself & Alex (and other curious non-professionals) would still not fall into elm's apparent target constituency as you would fail test c) (i.e., by being "willing to educate [yourselves] with respect to higher orders and types"). Also, it should be noted that the second list I mentioned was just some of the big groups to be excluded from consideration (i.e., not an exhaustive one).

--Jonathan

[Jeff Smits]

Jonathan, to me it seems the key difference in opinion that's keeping this argument alive is a difference in expectation of how many people Elm can steal from the "mainstream".

Evan (as I understand it) has an optimistic view that if he is careful to explain advanced features in the right way, he can get a lot of people to use Elm. This means slowly and carefully choosing features that combine well with the current language, and can also be explained well to all kinds of programmers. Most Haskell material is not geared towards this, so it takes time and effort to (a) pick features that are well-understood/not experimental, and seem like the best solution to the problem when compared with how other languages do it, (b) find a good narative to introduce them in an accessible way.

Your view (if I understand correctly) is more pessimistic on how many people from the mainstream can be won over. From that viewpoint, it makes sense to have faster integration of more advanced type features because people who come to Elm will be open to learning those based on complicated* documentation from Haskell.

* at least for average mainstream front-end developers

If I understood all this correctly, then this is basically the difference in opinion where you can agree to disagree.

[Laszlo Pandy]

On Tue, Oct 28, 2014 at 11:43 PM, Jonathan Leonard <joha...@gmail.com> wrote:

There exists a large constituency of frontend programmers who:

....

c) are not willing to educate themselves with respect to higher orders and types.

You are presenting a false dichotomy here. It's not: either you are not willing to learn higher order types, or you are willing to learn and you will have no problem with learning them now.

There are the extremes:

Group A: never willing to learn or use higher-order types

Group Z: clever people who love more powerful features, so they would love to see Haskell-style higher-order types in Elm

But there also groups B, C, D, etc. who aren't opposed to learning something new and powerful, it's just too much effort for them. And there are groups W, X, Y who use Haskell but find it hard to remember how to use higher-order types properly (this is me). And let's not forget about everyone in between who think the way Haskell implements higher-order types is too complicated, but would love to use them if they were more straightforward.

It's not about whether you want to educate yourself or not. Is a wide spectrum of
(1) how much effort you require to internalize the concept (some people are just smarter than me) and
(2) how much time your are willing to put in to educate yourself.

I am saying there are lots of people for whom higher-order types does not come easily, and finding a new way to present it in Elm will bring down the amount of time they have to invest to learn it, and increase the probability that they can educate themselves in their limited time.

[Paul Chiusano]

Hi guys,

I think this argument--about whether there is a group of people who might be comfortable with Elm's existing feature set, but not a feature set which allows abstractions like Monad and Applicative to be defined--is sort of missing the point. I think we can all agree that there is some learning curve in getting comfortable with these sorts of abstractions.

The real question is whether the mere existence of certain language features will make Elm as a whole less accessible, regardless of whether these features are used in the standard library or emphasized at all in the standard documentation. I have not seen an argument for why this would be the case. Here's a scenario:

* Elm implements some feature set that enables these abstractions. (Whether it's typeclasses or rank-N types). The standard library stays as is. The language docs get a small "advanced features" link that no one has to read.

* People who care about such things now have a more powerful language, and can stop complaining about things here on this list. :)

* Elm continues to be just as accessible to newcomers.

In other words, there is a big difference between the language having a certain feature set and the standard library looking exactly like Haskell, where you are forced into learning about these abstractions pretty much from the start.

I don't think Scala is the greatest example of all things, but this is roughly the path that it went through. Scala introduced type constructor polymorphism + implicits, which allowed the ability to define Applicative, Monad, etc. There was some debate about whether to add these things to the standard library, but it became clear that there were fundamental differences of opinion regarding the direction of the standard library, so the Scalaz library was created. This eased a lot of the pressure and tension, because people who cared about such things could just use the Scalaz library (and start their own mailing list) rather than arguing about it constantly on the main Scala mailing list and elsewhere. 

Since the introduction of scalaz, Scala has remained just as accessible to Java programmers and many people start out programming Scala as if it were Java with different syntax and some type inference (in fact, to this day there is a large segment of Scala programmers that have only vaguely heard of Scalaz). Over time, though, lots of people heard more about FP and decided they want to learn more about it and start leveraging it more in Scala. That's why I co-wrote a book about how to do just that, because there was so much demand for it!

In short, I see no real reason why Elm can not be more powerful as a language and yet simultaneously welcoming of people at all levels of experience in FP! If someone has a concrete argument about why this is not possible and why Elm's core language must remain limited for an indefinite period of time, I would like to hear that so we can discuss whether there's any truth to it.

Paul :)

On Wed, Oct 29, 2014 at 7:10 AM, Laszlo Pandy <laszlo...@prezi.com> wrote:

On Tue, Oct 28, 2014 at 11:43 PM, Jonathan Leonard <joha...@gmail.com> wrote:

There exists a large constituency of frontend programmers who:....c) are not willing to educate themselves with respect to higher orders and types.

-- 

You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/oyrODCgYmQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Laszlo Pandy]

Good point Paul.

Once thing that Evan has said in the past was that he is very careful
to add things like syntax which cannot be changed easily. I think the
main reason to not add feature X now is that if in 6 months Evan finds
a much better way to implement it or a better syntax, it would be very
painful to remove the old way. By then people will have written lots
of code, and there will likely be no quick fix (like renaming . to <<
in 0.13).

[Paul Chiusano]

Hi Laszlo,

If that were the main fear, then I'd rather Evan ask the people who would use such features (and accompanying syntax) how they feel. Personally, I'd rather have support for these features sooner (because I will take great advantage of them and save myself lots of repetitive work!). If I have a small cost later to make a mechanical upgrade my code if/when syntax changes, that is fine with me, I still come out ahead.

But I think people can do their own calculations about whether using a feature is "worth it" to them given that the syntax may change. It's not really much different than the calculations people already do with respect to libraries whose APIs are experimental and aren't guaranteed stable. If the library is useful enough to you now, you accept that the maintenance cost may be higher when using the library. *Not* having the feature or library means people don't even get to make this choice!

I do understand the not wanting to just implement some complex feature (like typeclasses) when there's a desire to explore alternate approaches. Which is why implementing rank-N types + the existing record system seems like such a nice compromise to me. It's a non-controversial feature, makes the language much more powerful, and need not IMO affect the accessibility of Elm unless it is used pervasively throughout the standard library.

Paul :)

[Alexey Zlobin]

> so the Scalaz library was created. This eased a lot of the pressure and tension

I'd say it's not that simple. Scalaz also pulled together all Java critics and eventually made them less tolerant to people who just don't use Scala or doing it in not advanced enough way.

Some of contributors are now anti-scala evangelists, who find Haskell acceptable for mediocre programmers and enjoy they excellence in Idris or something :)

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

[Paul Chiusano]

Alexey -

I'm not entirely happy with how things have played out in Scala, either, and I have my own thoughts about how it could have been different. But please don't nitpick my point there, which was that giving people who found FP in Scala important their own outlet was beneficial in the sense that it eased the need to get consensus from everybody (which was becoming a source of tension on the mailing lists and elsewhere). The people who liked the approach of scalaz could use that library, and the people who didn't like it or didn't want to learn about it could keep doing their own thing.

I'm a big believer in solutions that let people independently pursue their own ideas of what is important and useful. No language community can remain a monoculture indefinitely. C++, Java, Javascript, Haskell and Scala, etc are not monocultures - there are a diversity of different views and styles, and at this point these communities are developed enough that I find it hard to even generalize about them as a whole.

Programming languages are a tool, and people will always have different ideas about the best way to use the tool. But that is okay. Just like not all artists need to agree on the best style for painting, not all Elm programmers need to agree on the best style of programming in Elm. I welcome this diversity, and I also welcome people advocating for their favored approaches (not by being insulting to other people, but with robust discussion of the ideas, with participants being as polite and kind as possible). These are good things. Newcomers to Elm can decide what style they prefer, and Evan can have a certain style blessed as standard through its use in the standard library and documentation.

Paul :)

[Jonathan Leonard]

Your view (if I understand correctly) is more pessimistic on how many people from the mainstream can be won over. From that viewpoint, it makes sense to have faster integration of more advanced type features because people who come to Elm will be open to learning those based on complicated* documentation from Haskell. 

* at least for average mainstream front-end developers

Nope, that's not it at all. I'm long on Haskell even. I think the mainstream will be won over to Haskell eventually (or a derivative of Haskell like Agda or Idris). So, I think it'd be a stretch to say that I'm pessimistic about the mainstream being won over to elm.

But, I seriously think you guys are underestimating the number of *ordinary* programmers who are going to be turned off by such a one-dimensional and inflexible type system. Isn't the influx of all the OO programmers asking for ad-hoc polymorphism evidence of that? Sure, there are a lot of programmers out there who don't care about code duplication (although I think using the term 'programmer' to refer to them is a stretch) and they are going to write bad code in whatever language they touch. But there are also a lot of programmers who do care about it and in fact see eliminating it as the very essence of the craft. It is the second group that will be won over to Haskell or a derivative of it (not necessarily elm [especially since it is front-end only]).

--Jonathan

[Jonathan Leonard]

Sure. No one is arguing against simplifying these features if and when they are finally introduced. We are merely arguing against the assertion (and it's apparently disproportionate impact on the overarching 'elm philosophy') that adding them will turn [additional] people off to the language. Paul has provided an escape hatch to avoid addressing the assertion directly (namely making the features optional) and I have presented a direct argument against the assertion.

--Jonathan

[Sean Corfield]

On Oct 29, 2014, at 4:10 AM, Laszlo Pandy <laszlo...@prezi.com> wrote:

On Tue, Oct 28, 2014 at 11:43 PM, Jonathan Leonard <joha...@gmail.com> wrote:

There exists a large constituency of frontend programmers who:

....

c) are not willing to educate themselves with respect to higher orders and types.

You are presenting a false dichotomy here. It's not: either you are not willing to learn higher order types, or you are willing to learn and you will have no problem with learning them now.

Not only is a false dichotomy, it’s a really offensive categorization that allows the type system advocates to simply dismiss folks who don’t want these features as being "uneducated" or "unethical".

As far as I’m concerned, this thread is proving completely pointless because Jonathan has already made up his mind that PureScript is "better" because it has some features from Haskell that he thinks everyone should use - and he clearly thinks very little of people who don’t share his opinions on type systems...

[Laszlo Pandy]

This thread is way too long, but I am not so negative. I think it is somewhat constructive.

Paul managed to focus Jonathan's argument to whether we can add features without making the language less focused on new users. We still don't agree, but I am getting a better idea of what they are asking for, and I hope they are getting a better idea of what we are afraid of.

I don't expect to be in agreement, but I hope by the end of this we will all be able to articulate better why we think Elm's strategy is better and have a better explanation than just: feature X is too complicated.

[Dylan Sale]

Metacomment: I thought I would drop this here, perhaps someone will read it.

http://www.brainpickings.org/2014/03/28/daniel-dennett-rapoport-rules-criticism/

Dylan Sale

--

[Jonathan Leonard]

There exists a large constituency of frontend programmers who:

....

c) are not willing to educate themselves with respect to higher orders and types.

You are presenting a false dichotomy here. It's not: either you are not willing to learn higher order types, or you are willing to learn and you will have no problem with learning them now.

Not only is a false dichotomy, it’s a really offensive categorization that allows the type system advocates to simply dismiss folks who don’t want these features as being "uneducated" or "unethical".

But the problem here is that we already have a type system. And, if it stays in its current level of maturity it would be nothing more than a huge validation to all the extremist anti-types types who insist that "types get in the way" and "slow the flow, man", etc. In its current form, the type system does in fact do just that.

And, I must ask: do you say this as someone who actually does understand what the features entail and what benefits they offer? I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas (but I suppose it is possible). They're certainly not perfect but they make life a *lot* easier/ more enjoyable/ happier. Why do you think Paul (and other advocates) would misrepresent that when they speak from their own daily experience? What's in it exactly for him? And, as I said before, I applaud the efforts to distill these ideas/features to their barest/purest form and standardize on naming and such.

Regarding the 'offense' and 'condescension', I think this post responds to those claims quite a lot better than I could:

http://superginbaby.wordpress.com/2014/10/28/suddenly-the-opposite-appeared/

As far as I’m concerned, this thread is proving completely pointless because Jonathan has already made up his mind that PureScript is "better" because it has some features from Haskell that

he thinks everyone should use - 

Did I say that? I certainly don't think it. I think that all other things being equal (i.e., if Purescript had FRP/signals, elegant HTML/style integration & reverse debugger) then yes Purescript is better. But, currently that isn't the case and elm has some novel features. It's unfortunate that we have to pick between the two in fact.

and he clearly thinks very little of people who don’t share his opinions on type systems...

I don't know how to respond to that exactly though I'm not entirely fond of people ascribing to me things that I neither said nor think.

--Jonathan

[Sean Corfield]

On Oct 29, 2014, at 11:01 PM, Jonathan Leonard <joha...@gmail.com> wrote:
> And, if it stays in its current level of maturity it would be nothing more than a huge validation to all the extremist anti-types types

Er, maybe you should read that back… you’re painting everyone who doesn’t agree with you as an extremist.

> And, I must ask: do you say this as someone who actually does understand what the features entail and what benefits they offer? I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas

And this is exactly the sort of condescending stuff that puts people off the Haskell community. As soon as someone doesn’t agree with you, you question their ability. Lovely.

[Joey Eremondi]

I think this might signal the time to end this discussion. (Heh... Signal...).

1. This discussion isn't going to change anything. Elm has its philosophy, Haskell has its.

2. This discussion is actually causing stress and harm.

So, let's just stop responding. It's not doing any good. We're not making any progress. Neither side will convince the other.

It' doesn't matter who has the final word. For now, let's just focus on our constructive discussions of features and proposals. There's way too much cool stuff happening with Elm for us to get hung up on this debate.

[Jonathan Leonard]

> And, if it stays in its current level of maturity it would be nothing more than a huge validation to all the extremist anti-types types

Er, maybe you should read that back… you’re painting everyone who doesn’t agree with you as an extremist.

Nope, not everyone. I'm referring to a very specific group of people.

> And, I must ask: do you say this as someone who actually does understand what the features entail and what benefits they offer? I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas

And this is exactly the sort of condescending stuff that puts people off the Haskell community. As soon as someone doesn’t agree with you, you question their ability. Lovely.

So I think we have our answer-- no, you don't even understand what you are rejecting. Brilliant.

Just saying "I disagree" isn't enough in science. You have to put forth actual coherent arguments.

--Jonathan

[Paul Chiusano]

I agree, this conversation has gotten ugly. I'm sorry if I contributed to that in any way.

Jonathan, I share some of your frustrations but I think you should be much more careful in how you say things. Whether you think it's valid or not, some of your responses are exactly the sort of thing Evan is probably concerned about. He does not want a community in which threads like this in the norm. And I agree.

Sean, whether or not you think your characterizations of Jonathan are accurate, I think some of your comments were unhelpful and uncharitable toward Jonathan.

What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests. Unlike Joey, I'm not convinced there's a fundamental impasse, but perhaps we can discuss these things another time.

Paul

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/oyrODCgYmQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Jonathan Leonard]

I agree, this conversation has gotten ugly. I'm sorry if I contributed to that in any way.

I think it's pretty clear when it got ugly. And, I think we should also consider the source of that ugliness. I'm not quite sure why dynamic language advocates would just wander into a forum about a statically typed language but apparently they do.

Jonathan, I share some of your frustrations but I think you should be much more careful in how you say things. Whether you think it's valid or not, some of your responses are exactly the sort of thing Evan is probably concerned about.

The only concern of Evan's that anyone has pointed me to has been regarding how to maximize the popularity of the language.

He does not want a community in which threads like this in the norm. And I agree.

I honestly thought the thread was valuable and positive until Sean Corfield jumped in and took it to a whole other place.

Sean, whether or not you think your characterizations of Jonathan are accurate, I think some of your comments were unhelpful and uncharitable toward Jonathan.

Not only that but they were also exemplary of poor reading comprehension and cloudy reasoning.

What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests. Unlike Joey, I'm not convinced there's a fundamental impasse, but perhaps we can discuss these things another time.

I also agree that there doesn't need to be a fundamental impasse but since there is obviously so much resistance/friction I know where I will be investing my time when it comes to frontend Haskell implementations.

--Jonathan