7 ms·
Are the elm overlords still hell bent on "thou shalt program our way or not at all" Because that kind of dogmatism is a complete show stopper for languages tha
by grandinj 8y ago
Are the elm overlords still hell bent on "thou shalt program our way or not at all"
Because that kind of dogmatism is a complete show stopper for languages that want to be deployed on even medium term projects.
- andrepd 8y agoCan you explain what you mean?
- jxub 8y agoOne of the reasons behind the poster saying it is that the interop between Elm and vanilla JS is quite painful especially compared to the likes of BuckleScript.
- rkangel 8y agoI would expect that interop wouldn't be trivial - the impedance mismatch between a mutable and immutable world would be difficult. I didn't know of BuckleScript though and that faces a similar problem, so it's interesting if it significantly better.
- sli 8y agoPureScript's interop is fairly easy, too. Just foreign imports, which I personally prefer over mixing languages like you might do in BuckleScript/ReasonML with their brace syntax (or might not), but it's still better than this weird message passing thing that Elm does.
- ctrl-j 8y agoDoes elm have a strict linter or something? In the end, it may be a showstopper for you, but go is the prodigal child of "my way or the highway", and it's doing just fine in many production environments.
- rkangel 8y agoCan you give an example of something that the "elm overlords" (I like the phrasing!) have railed against?
- mixedCase 8y agoNot the parent poster but: a) Type classes/interfaces. b) "Native JS for me, not for thee". Much like Go gatekeeps generics to the language authors only, Elm restricts native JS access only to the language runtime because devs "might get it wrong"; forcing them to use the ports system, where they have to type the use of even perfectly pure JS code as a side effect. c) The official package manager forbids the upload of any package that interacts with JS without the blessing of the BDFL. I'm aware on the tradeoffs of each case, I understand Evan's intentions; but I heavily disagree with them, which is why I don't entertain Elm as an option for production use anymore and would rather go with something like Reason despite being less knowledgeable about it.
- foldr 8y ago>Much like Go gatekeeps generics to the language authors only It would be more accurate simply to say that Go lacks generics. I don't know of many statically typed languages that have arrays but which don't allow you to type an array of integers differently from an array of strings. Go basically has that feature, plus built-in hashtables that are also type parametrizable. Characterizing that as some kind of huffy refusal to allow people other than the language authors to use generics is arguably inaccurate. Adding generics to Go would require fundamental changes to the type system, and would have some nasty interactions with interfaces. It's not a matter of flipping a switch.
- mixedCase 8y agoGo's omission of user-defined generics was a conscious decision by Go authors led by the belief that the benefit is not worth the complexity added and that devs would misuse it; yet this did not hold them back from special casing generic support for things they implemented themselves. This is what I'm comparing it to. What it would take to add generics to Go now is a separate matter. Feel free to link my Go commentary to my point on lack of type classes on Elm if you want to see it from the perspective of changing an existing language.
- zoul 8y agoWhere one sees dogmatism, other may see sticking to principles. Elm is not trying to be everything for everybody. I think that’s a feature. Accepting its strange, perhaps dogmatic ways made me a better programmer, even in other languages.
- peacetreefrog 8y agoI've been using Elm a few months for a serious project and really like it. That said, I do get the impression there is some drama at the top (among the overlords) and the direction they want (or others want them) to take things. I'm not even close to being an overlord or contributing anything to the language (just a consumer who has been very happy with how everything's been working so far) so the fact someone like me is even aware this is going on is mildly troubling. Other libraries I'm fairly familiar with (Pandas in Python, React etc) seem to tend towards quietly releasing without all the public drama among contributors. Not sure whether it's because it's a smaller community or more of the help/documentation is on places like reddit or discourse (where the overlords argue - vs something like stack overflow), or whether everyone involved just needs thicker skin. Either way, it's only a mild annoyance to me for now and I really like Elm overall. Would encourage anyone interested to check it out.
- Tehnix 8y agoDefinitely some tension, mainly concerning that there is primarily one gatekeeper, Evan, and he is very focused on 0.19, and therefore 0.18 (the current) is getting stale, and a lot of issues are not fixed/ignored. Problem is, 0.19 has been underway for a looong time, and is still unclear when it'll be done. They also have this weird thing were they are heavily pushing and promoting the language, and when you complain about these kinds of things, you'll often get back a "this is to be expected of such a 'young' language", which seems contradictory to their narrative of "look at all these companies using them in production". Personally, I quite like a lot of the parts of Elm. A bit too simplistic for my taste type system-wise, but that is also it's great strength when having to onboard/convince new developers or colleagues. That said, I'm waiting on 0.19 before seriously considering Elm any time again.
- lewisinc 8y agoThat's fair, but I think with Elm-Conf coming up it's worth it to keep an eye on at least.
- desireco42 8y agoJust give it a try, will you. You might discover this all has some sense and meaning to it.
- grandinj 8y agoSpecifically stuff like https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=16510267 is a showstopper. I maintain long lived applications. Sooner or later we __always__ have a need to call out to the host environment to work around limitations of the compiler/runtime. Not being able to do so, and the attitudes of the core elm team that prohibit such actions, make elm a non starter for me.
- ravloony 8y agoThis is one of the reasons why I chose Purescript for my team's projects. Also it's got a more complete type system, a simpler FFI, and compiles to less javascript. This is not to say that Elm is bad. O think it's great as a path into FP, and in fact _was_ my path in. But it does limit you in what you can do and learn. Also, Purescript has this interesting property of being hard to learn (because it is powerful), but dead simple to use (because it compiles to JS). So you only really get stuck on figuring out how to do things in PS, as opposed to how to get PS working, and therefore every time you get unstuck, you have leveled up. So it's hard, but rewarding. I'm probably off topic by now, but I do think that Purescript in the frontend is a better option for solid application development.
- eweise 8y agoPurescript looks like a great language and if you want to dive into the deep end of typed FP, then it looks like an excellent choice. One reason I went with Elm for our in-house customer support app, was because of the simplicity of the language. It does result in more boilerplate but I don't think the project would have been successful if the learning curve was steeper.