[mikekchar]

I find that there are times where I get into a "Someone is wrong on the internet" situation, but still think it's worth commenting. This is one of those times. My goal is not to win the argument, but rather I hope I can show you a different way to look at the situation. To be fair, the only reason I wrote my original reply to you was because you asked why people would down vote you.

Clearly 15 seconds is unreasonable, and in retrospect I regret having written that. As I am trying to convey what a reasonable amount of time is to understand a language, using unreasonable numbers is unhelpful.

From my experience, if you were to give me a legacy Objective-C application and ask me to fix a bug in it, it would take me much less than an hour to understand what I need to know to fix that bug. It would literally take me seconds to understand the syntax well enough to read the code, only being slowed down occasionally to look up syntax that I didn't understand. (To be fair, I have already fixed many bugs in Objective-C programs before, so I know exactly how long it took me -- despite not "knowing" the language at all).

If you asked me to write an Objective-C program from scratch, it would take me 10-20 minutes to get started. My main problem would be in choosing appropriate libraries. For example, I like to TDD, so finding a good test library would take me some time (though I can live with XUnit and the chances that there isn't one for Objective-C approaches zero).

If you ask me to make an iOS application, it would take me at least 1 day, probably 2, to get set up and start writing code. This, of course, has nothing to do with Objective-C and everything to do with figuring out how to get the build system working, etc.

It would take me at least a week to get to a point where I'm writing idiomatic Objective-C for iOS apps. It depends on how much code I could find on the internet. Free software is great for this, but there is precious little for iOS (in comparison to other platforms). On the other hand, if you asked me to write a GNUStep app, it would be much easier.

It would take me years before I was actually knowledgeable about iOS. No, scratch that. It would never happen. I have absolutely no interest in becoming an expert in iOS.

But let's back up here. How much knowledge would I need to have to critique Objective-C as a language. Again, I urge you to read the original blog post closely. The author opines that Elm is fundamentally broken as a strongly typed FP language because it doesn't have type classes. This is what he says is "wrong" about Elm.

He is correct. There are no two ways about it.

Now we can argue all we like about how Elm programmers can work around this deficiency. I think he's missing the point that Elm is aimed at programmers who do not want to deal with the complexity of a fully featured strongly type FP language. We can debate about how front end programmers (the likely target for Elm) will rarely run into situations where they absolutely need type classes... But he's correct in his statement.

He's expressed his opinion in an offensive way and he's turned a blind eye to the fact that people can still enjoy many of the benefits of the language, even with this obvious problem. But he has not made an error in his analysis.

And he didn't need weeks to discover this. It's very clearly stated in the tutorial. He could have saved himself weeks and read the damn thing. It would have taken him 20 minutes. And then he could write the same offensive piece and still not be wrong.

The reason I'm pointing this out is that it is beneficial as a programmer to realise what is easy and what is hard. Many young programmers (that is to say, programmers who have written only a few thousand or a few tens of thousand lines of code), conflate frameworks with languages. It's easy to miss the distinction between the features of a language and the features of a framework.

Why is it important? Because if you understand the features of a language it will serve you well going forward. There are only a few categories of languages in the world. Everything is just a different spin on that category of language. If you learn a few examples for each category, you will never have trouble finding work in your career. It will take you hours to jump from one environment to the next. I'm nearly 50. That's why I'm still employed.

But on the other hand, frameworks and libraries have endless variations. And you absolutely must understand certain details or else you will be in for a world of hurt in the future. The downside, though, is that the framework/library will give you no benefit at all when it is dead and buried. How many DB2 programmers did I go to school with that are useless today? How many MVC programmers did I work with that are useless today? .NET, iOS, Android, PHP, Rails, insert-flavour-of-the-moth-here. Before you are finished your career, they will all be gone (or good-as in terms of furnishing you a living wage).

The author seems well qualified to make the statements he makes. He does so obnoxiously, but obnoxious != wrong. He's spent much more than the amount of time he needed to come to his conclusions.

I get the fact that you hated his blog post (and that you hate obnoxious know-it-all blog posts in general). I hope I have convinced you to take another look and understand the distinction between what he's trying to say and what you thought he was saying. There is a lot of valuable stuff in there. Even if it is obnoxious.

[logicallee]

So is it fair to say that it is possible for me to conclude "xyz is broken" based on a single paragraph? For example, if I read the Wikipedia article on Perl 6, the second paragraph says "While historically several interpreter and compiler implementations were being written, today only the Rakudo Perl implementation is in active development."

So let me skip the part where I spend 2 weeks picking up a language!

Let's go straight to: "if an ostensibly open language only has one single implementation, it is fundamentally broken and underspecified and should not be used by anyone, period."

Is the part I quoted enough for me to conclucde that it's a broken language not fit for any use by anyone? Because the article that we're talking about has the title "Elm is wrong."

Can I say, "Perl 6 is wrong" without even bothering with coding in it for a few months?

[windwake12]

"Elm is Wrong" is a good click-baity title. It's not out-right lying, but opinionated sure. It leads me to want to know in what way it's "Wrong", somehow broken fundamentals, stupid API, bad implementation, or what have you.

Given the response in this thread, I can only surmise it was a well chosen title for a blog post.

[logicallee]

But HN has an explicit policy against clickbait titles, and usually edits them to be more descriptive.

[mikekchar]

Having a single implementation is quite a different situation than having a missing feature that most people would consider necessary.

A better example would be back in the old days perl had no intrinsic OO support. Instead it had a library that made a few things easier. But basically, the OO support was hashes that pointed to functions. There was no syntactic sugar at all.

As an OO language Perl was fundamentally broken. You could still write OO code in Perl (and I happily did so for a very long time). But, yes, there were many people who claimed that Perl should be avoided because of this. Eventually full OO support was added and those voices died down.

The difference between that situation and this situation is that the author of Elm (as I understand it) has absolutely no intention of adding type classes to Elm. He has specifically chosen not to have them because he thinks it complicates the language. I happen to think that for his target audience, he is absolutely right. I think it is a good decision.

However, for the author of the blog post, the decision is wrong. Elm is intentionally broken. The author does not want to fix it and the blog post author thinks that this decision is wrong.

He also complains about the maximum size of tuples. The author of Elm believes that you should only have small tuples because you should be using records instead. This is contrary to how FP languages tend to work. Usually you use tuples. Records are the strange structure to work with. Again, I agree with the author of Elm, but the author of the blog post has a completely valid point. In his opinion, Elm is wrong.

The author of the blog post found a way to get around several of the problems he was having with Elm, but it required him to add or remove fields in records. The author of Elm had disabled that feature because it was complicated. Given that doing this removes the only way the blog post author (and me too) has to work around the lack of type classes, he was upset. Even though I understand the blog post author's frustration, I agree with Elm's author. JS implementations are optimised for objects that don't change structure. Records are implemented with JS objects and so allowing the records to change structure will impact performance in ways that the Elm programmer won't expect. It's a pity, but shit happens. Of course the blog post author thinks this is wrong.

Finally, it's not like you are locked down here. You can easily write an extension in JS to fix the issues the blog post writer has. But the kicker is that JS extensions can not be distributed with the normal Elm tools without approval from Elm's author. And Elm's author has said that he doesn't want those things fixed. So even if you wrote a work around, you aren't allowed to distribute it.

So given all this, I hope you can see the blog post author's point. Elm is fundamentally broken. The Elm's author knows that is broken and refuses to fix it. The only way inside the language to work around the broken feature was removed and Elm's author doesn't care. You could fix the problem by writing an extension, but Elm's author has blocked that avenue as well. You are not allowed to fix this problem.

This is what he feels is wrong. I completely understand his point of view, even if I disagree with his conclusion. Your characterisation of the situation trivialises it. You assume that there is no way the blog post author can know what he is talking about because he hasn't used the language long enough. You haven't spent the time yourself to understand what the issue is and why the blog post author is upset. You just assume he is a dumb ass. That's why you were getting voted down.

I spent a lot of time trying to explain the situation to you, so I hope at some point you find it valuable (even if it doesn't seem so right now). Like I said, sometimes I get the impression that spending my time on things like this is worth it. In my past, some people have graciously spent similar efforts to help me understand something and eventually it was helpful to me. I hope that will be the case here.