Maybe Elm needs some sort of "Please do not use this language in production" sign, and no "Community" link at the top of the home page. There's nothing wrong with a group of folks making a language for themselves / their employers, perhaps putting it on GitHub because why not, but not having a home page at all and making it clear that this isn't a stable language for others to use and they will put much more emphasis on the feedback from their own experiences than from others'. There's definitely nothing wrong with them doing that until they get to a 1.0 they're happy with, and then releasing it to the community.
Indeed. I think somewhere along the way the line between "programming language" and "programming language implementation" has been blurred, where the language is the implementation. It used to be that in designing a programming language you didn't have to write a single line of code. e.g: https://en.wikipedia.org/wiki/ISWIM
I don't think there's anything wrong with the implementation being the language definition, but there has to be time left for reflection.
> Maybe Elm needs some sort of "Please do not use this language in production" sign
Except Evan has explicitly been pushing Elm for use in production. Like, hard. He even tells you how: http://elm-lang.org/blog/how-to-use-elm-at-work
That's the point of 0.X.Y supposedly.
> The core team has spent countless hours discussing these topics again and again. People get exhausted explaining and re-explaining themselves until they are blue in the face. Honestly, posts like this are what makes contributors want to quit
This is a disappointing mindset for them to have. If people have questions about design decisions, and express dismay about the real-world effects those design decisions have on them as production users of the software, then it's an opportunity to convert those passionate users into engaged contributors to the core, rather than considering them as abusive adversaries. If you are explaining things until you are blue in the face, that's a bug in your documentation - and sure, bugs are frustrating, but it's the sign of an effective developer to not let them cause emotional distress. (And while the original post was direct in its depiction of the BDFL, it was far from toxic in its wording, and not meant to be an ad hominem attack.)
Instead, the thread is locked, the poster is confused, there's even a slimmer chance of the blogger reintegrating into the community to stave off these types of issues in future releases, and the language is worse off for all of that.
I understand they are set in their ways and aren't interested in changing the language in ways some people want, but removing any and all posts that criticize them feels more like censorship than anything.
I was told, I was lucky not be be banned from the r/elm.
A month or so later someone else posted on r/elm referencing my prior post. So I replied back and said I was the OP and that I agreed with his view and how nothing has changed. That reply go me banned from /r/elm.
The elm forum has a very strict rules, almost dictatorial [1], Posters who demonstrate a Pattern of participation in Conflict may be banned from any Elm Forum....A Pattern may also arise within a single conversation.
...and that Reddit threat certainly doesn't give me any reason to change my mind on any of those points. :)
Edit: I should note, I sympathise with the situation the Elm project is in. The extremely limited resources they have for development mean they have to make some compromises, and I'm not sure they've even made the wrong ones, given their goal. If they waited until a 1.0 version before trying to get adoption the project would lose relevance, so they have to get people to use an unstable beta in production. If they didn't make breaking changes to enforce a vision on the project, you'd end up with a ugly soup like PHP. If they devoted significant time to dealing with the community, they might not get anything done. Golang has charted a similar course but has had way more resources (and still has made a number of people angry); Rust has kept people happier, but in exchange for a much more community-driven vision, and not without cost in terms of false starts and dropped features. Developing a new language as anything more than an exercise is very hard!
I have to admit that I was thoroughly confused at the locking and removal of the thread. It also means I didn't even have the chance to respond that I don't necessarily agree or disagree... I'm a new part of the community.
I'm still going to continue learning and implementing a few small projects that I have planned. However, I'm a little worried that I'm going to be burnt by some in this community calling real needed debate a diatribe and silencing people that don't agree with them.
Furthermore the discussion about type-classes is getting old. YES Haskell has them and NO Elm doesn't have them at the moment or maybe never. It's similar to the Go generic-type flame-wars that emerged in many Go discussions.
Has a much better FFI story with JavaScript than Elm, and has a more powerful type system (higher kinder types, etc). Row polymorphism makes writing pure code a joy, the effects system is unobtrusive. I actually enjoy programming purescript more than Haskell.
However, if you want an easy migration path, there is https://github.com/pselm/core Which is a drop-in replacement of the Elm 0.18 API in purescript. You can almost directly copy your elm code to it and it will work with minor changes
Components are these things that have a way to initialise themselves, an internal state, a way to receive messages and update their internal state, a way to compute from the internal state (ie rendering), and a way to reply to messages that are querying things (by having the message pass a callback for the reply as an argument). The only thing they have which is missing from standard oo is a way to pass up messages to their parent component.
After all that one must wonder what the point of using purescript for this is and why not just use a more object-oriented language fron the start?
I think anyone who is already comfortable with elm can look at that and be productive in purescript very quickly.
* Of course, with purescript there is going to be a bit less hand-holding. But the side-projects I see folks posting about in done with elm are done by folks that already do things on their own.
The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language.
It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.
Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're going to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be.
But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done.
But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped".
At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" -- which usually isn't true. It's much simpler to learn something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.
Use custom operators? Fuck you. Now go rewrite all the libraries you contributed to the community.
I think you mean "immaturity of the platform".
Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.
When you update this quickly (and for no reason), the learning resources go out of date too.
However this seems to have backfired. Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses.
Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev.
Evan is great person, I still remember fondly the time we had good long conversations at a conference. I started the first attempt at integrating Elm with React Native, and that was only possible through hacking the native modules in various ways. I figured I couldn't progress with this plan due to how restricted Elm is regarding native modules, but also other things like naming of community modules. Elm is strict not just as a language but also as a community culture.
What shocks me about the latest state of Elm and its community is how easily conversations get locked. Locking should be the last resort. What leaders block or ban indicates what they do not want to risk. There should always be the possibility of blocking to say that "we cannot afford having X in our community." and defend some basic principles.
In many communities, X is just personal attacks or harassment, that kind of thing. The consistent pattern I see in the Elm community management is that X is dissent. "We cannot risk having divergent discussions (polite or impolite) in our community" is message that restricts thought freedom and reinforces cult-like behavior. It's not a good thing to have in a community, specially in an open one on the internet where membership is fluid (unlike dissent in a company for example). Curbing dissent ultimately leads to lack of innovation (which comes from freedom to create without fear of rejection), which reinforces the status of the leader as the primary source of innovation, because whatever the leader does is assumed to be never rejected. I think these community dynamics are bad in the long run, it creates more feeling of rejection, decreases innovation, and centralizes even more responsibility and power to the BDFL.
That's not the only reason ReasonML will win. The BuckleScript JS compiler generates fantastic JavaScript, with no huge extra runtime at all. Also, ReasonML benefits from all the stability of OCaml's type checker. And, as you suggest, both ReasonML and BuckleScript are in my experience a much friendlier and open community to experienced devs and commercial users.
If you're comparing it to ReasonReact, you still have the React/ReactDOM Javascript dependency which is still ~30kb gzipped
However they also need to encourage users to build things so they can observe patterns and improve the language - often by removing the functionality developers relied upon (in the maintainers opinion wrongly.)
These pre v1 developers are going to get angry and burnt, the main problem is that Elm is ambitious and reliant on just one guy. 18 months with few warnings on breaking changes gives developers a long time to become reliant on deprecated functionality.
I've done some Elm development, the lack of documentation and support unless you hang out on chat channels put me off. I might try again post v1 but that feels a very long way away.
Not according to the homepage. According to the homepage you should install now and it's already used in production by major companies!
Evan is suffering the direct consequences of his actions because he tried to recruit people to the community and then fucked over their production projects.
For newbs/outsiders looking in, I think a lot of it has to do with a culture of validating people's experiences. That's difficult. If a user complains about it, the natural reaction can easily be to go defensive ("You're doing it wrong" or "we documented that here"). Rust has successfully fostered a culture of approaching it as an opportunity to learn something ("Why did you not see the documentation").
As far as I understand it, the native modules lockdown had to take place. Period. The one thing that most attracts myself (and many others, I'm sure) to Elm is the guarantees that the compiler gives you towards ensuring no run-time errors. Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee.
Note that you can't even compile native modules for your private modules.
I am sometimes frustrated by the way Elm is almost more a DSL for web apps than a complete language, but I also don't see anything wrong with closing an unsafe API in a language that's specifically about type safety.
It seems like complaining that Haskell doesn't give you instructed ASM blocks.
Well, Haskell doesn't give them out of the box, but it allows implementing and distributing all sorts of crazy unsafe stuff in libraries, including exactly this sort:
http://hackage.haskell.org/package/inline-c-0.6.1.0/docs/Lan...
I don't think that's true. In either case, being beginner-friendly above all else is a bad design goal.
> the compiler gives you towards ensuring no run-time errors
lol except for the part where you can cause infinite loops at runtime. whoops!
During next release they decided that primes as part of a name were not their cup of tea and removed it. Just like that. When I asked why was prime no longer allowed, since I couldn’t see any good reason behind it, I got the usual: “it’s pre-1 release you should expect things to change, etc.”
What left a bitter taste in my mouth was that this change had nothing to do with the language itself. It seemed as if they decided that using prime is not good style, so they forbid it.
I haven’t touched Elm since.
Exactly my point. They decided they don’t want to use it and they decided to enforce it to all their users. The reason I don’t want to have anything to do with their language.
It's not an aim to pretend that failures don't happen, especially when doing remote calls, and the types will be transparent in showing where this occurs.
These things happen in backend / distributed systems. They don't really happen in the browser, which is basically a self-contained sandbox that can make network requests. The browser code needs to handle those network requests maybe failing, but that's about it in terms of dealing with unpredictability. So, it's totally reasonable to think that a web-app should never be able to crash.
The type system forces the developer to deal with the error, so that, hopefully, the user of the app has a better experience than a non-responsive web page.
Crashes we cannot avoid through the type system is stuff like stack overflow or running out of memory.
Unless you have an infinite loop...
Elm's BDFL cannot make such claim, since he doesn't use it to build products closely similar in nature to most users of Elm. I think this is both good and bad. Its good in that Elm is more ideological in nature, since the creator is not motivated to break his ideologies by real world constraints. Its bad, because people who have those constraints must find ways to shoehorn the beautiful ideology, into the dirty real world. That's where a lot of the user pain comes from.
If you’re doing any real work on the web, you’re going to have to use external libraries and code and such. You’re not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system.
Also “no runtime exceptions” does not mean the application isn’t broken, does not absolve your developers from real testing and QA their changes.
Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.
What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that.
Occasionally you do find a serious error, though.
And runtime checks aren't free - they cost CPU, they can have their own bugs, and they can be tedious to write. "In general", rather than even try to be as careful in a dynamic language as you could be with an advanced type system, you'll just settle for not being careful.
From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible.
The sad reality is that very little pragmatism went into this release and now stuff like web-sockets won't work [1]. This is very surprising because web-sockets are an use case where the Elm-architecture really shines.
Things like this reinforces my idea that while Elm is a very nice language I wouldn't want to have it in production, or even in a side project, at least till it reaches 1.0 and becomes more stable.
Pretty much every language falls apart when it comes to FFI. In Haskell, a foreign function `Int -> Int` can print to the terminal. That's just the way it goes.
In any case, I would expect web-sockets to work out out the box in a language that is specifically designed to run in the browser.
If that's not working I'm sure that less common parts of the web platform aren't supported either. Normally I wouldn't care and implement stuff myself and contribute back, but it doesn't seem to be a realistic option in Elm.
I appreciate that what's there is generally of very high quality, but I cannot pretend that there aren't many missing pieces and, more importantly, no clear roadmap
Nope. That was what the Java people were saying a decade and a half ago about C# having operator overloading and it just didn't turn out to be apocalyptic madness with nonsense operator overloading all over the place....just didn't happen.
On the Java side we have the BigInteger, BigDecimal mess - https://www.baeldung.com/java-bigdecimal-biginteger
IMHO it is better to concentrate on getting the semantics right and not waste any goodwill on restricting syntax.
If you make a language for stupid people, that is fine, but I will not use it.
I love how low the cognitive load of adding features is. Having a small baby, it helps a lot.
That being said, some things really confuse me, and especially the way the governance model is accepted and cherished. We have a `almighty god` deciding what will and not be done, the accepted reason being that it's not 1.0 yet.
I mean, with 0.19 coming out, all IDE support went out the window and the answer from the author of the language is basically : 'changes are known since last May, things should have been done already. I don't even know what the status is'. Communication is at the minimum lacking tact. Others could say straight offensive for not-core users.
I understand PR is hard and not fun. But then find someone to do it for you, or act as to minimize it.
At the moment, the advantages of elm far outweight the issues for my personal use. But I really wonder about the long run, but I'm really afraid someone gets really pissed and forks the language in the long run, fragmenting and ending up destroying this great community. That would really be a waste.
And btw, I am (modestly) involved in the IDE support. So do check before being cynical <3.
Your response typifies the unpleasant atmosphere I've witnessed around Elm which is a shame as it's author and intentions seem so good.
Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure.
Or... more than 10 minutes, because you have to re-implement a library that was already written.
It offers an MVU framework: re-frame. There are others too. Its community is very friendly and helpful, it loves to discuss the language itself. No one seems to think of themselves as more knowing. It has never ever broken backward compatibility. It's a core tenet of the language to never break anyone ever. Finally, it has very good interop with JavaScript. And its getting better and better every release.
It's also ran by a BDFL, actually more like two. Rich Hickey as the BDFL of the standard language design, and David Nolen as current implementer and main maintainer of ClojureScript. But they're loved and admired. And if you disagree with their direction, you're free to add your own features as a macro, that's why they made the language a Lisp.
The language design prioritizes pragmatism. All discussion starts with: What exact problem are you facing for which there are no simple way to solve. And working backwards from real problems, solutions are added and new constructs are built.
The only thing is, it comes from a different school of thought opposite to strong static types. But it shares a lot in common, emphasis on pure functional code, immutability of variable and values. No OOP, everything is a function with support for higher order functions, closures and partial application. And the same focus on interactive live development.
If you don't mind losing the strong static types, I highly recommend giving it a try. You'll only miss the nice Elm error messages.
Just to clarify one point, though, Clojure/Script does support OOP, with protocols/records/types, it's just not the first thing we suggest people reach for in the language. As a community, we're much more likely to use boring maps/vectors/functions first, and switch to OOP when we really need type-based polymorphism, or extreme performance.
One consequence of not forcing everything to be OOP (like, e.g., Java) is an honest evaluation of where it makes sense, and where it adds nothing but complexity.
Protocols, records and types are not instances of OOP in my book. Polymorphism and abstract data types are concepts orthogonal to OOP and FP. The fact Clojure/Script has support for polymorphism and ADT does not mean it supports OOP.
If you want to claim it supports OOP, I'd say it does in the form of interop. Genclass, proxy, or defining classes in Java or objects in JavaScript and using them from Clojure/Script.
But, what is OOP exactly? We can debate this. I like to use Wikipedia's definition that it is languages where there is a construct, called an object, which groups together data fields and methods which can access and modify the data fields within.
Clojure/Script has no such construct. But one can define them in Java or JavaScript, and use them from Clojure/Script through interop.
The reason for that is simply that TypeScript has to fit in with JavaScript, while the others do not.
That said, I’ve never found Strong Typing to be that essential for front end dev. TypeScript is incredibly pragmatic, which is why it’s been so successful imo.
Nothing stops people from writing all their dependencies in TypeScript. But it’s not necessary to use it successfully.
Maybe someday Elm will adopt a more community-oriented approach, but I don’t think that is necessary right now.
Refusing, on principle, to be inter-operable with unchecked javascript code is a defining virtue of Elm.
edit: grammar
Yes, not having FFI is a feature. Brilliant.
Most languages have too many features anyway so removing them can be a positive thing.
This is completely unsubstantiated.
Not the point. The point is that it breaks backwards compatibility for the arbitrary prejudices of the Supreme Leader.
http://mithril.js.org - vdom lib - for the V http://meiosis.js.org - state pattern in conjunction with streams to give you the M/U
Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time.
this guy came from elm: https://github.com/pakx/the-mithril-diaries/wiki/Coming-From...
I'm reminded of Rich Hickey's great response (https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...) to a similar situation.
