3 ms·

So my point was actually about the specifics of picking up a language to do a new project, and then complaining about it. (Hence my example of writing a seriou

So my point was actually about the specifics of picking up a language to do a new project, and then complaining about it. (Hence my example of writing a serious book in a language you don't know.) I think you really go into superlatives here. It's not fair for you to say "15 seconds", for example. 15 seconds is how long you've been reading this comment. (I just timed myself, okay maybe 10-13 seconds.) I also think that "a few hours" is an exaggeration on your part. Let's pick a language you've never used - take Objective-C which is similar to C# and C, C++ which you've already listed, and I think you've never programmed in it, because if you had you would probably have listed it. Okay, so now make a serious iOS app in Objective-C in "a few hours". As in, have one by this time tomorrow. See? It's crazy. That's not how it works. Maybe the weeks and months and decades run together for you, but there is a huge difference between doing something for a few months or a year, or doing something for a couple of weeks as our author reports. I don't like his kind of blog posts, and it is a whole category - there is this whole type of blog post where you pick something you've never used, use it to do something new, and then complain about it, all within the space of your first week or two using it. It strikes me as kind of ridiculous. Especially with a provocative title like "Elm is wrong." Literally, it's like Tolstoy writing War and Peace in Swahili, a language he didn't know, and then writing a blog post "Swahili is wrong" -- all within the space of two weeks of when he first learned Swahili. I might be exaggerating slightly, but I think my analogy holds. It's almost farcical.

mmarx 10y ago
> Okay, so now make a serious iOS app in Objective-C in "a few hours". As in, have one by this time tomorrow. See? It's crazy. That's not how it works. But then making an iOS app requires picking up frameworks/libraries, not only learning Objective C, which was exactly GP's point: >> Libraries and frameworks take a lot more time than languages.
- logicallee 10y ago
  From the article: "Unfortunately, Elm isn’t a library. It’s a language, which just happens to have a great library" I don't know why we're arguing about this. It's another blog poster writing about something new they tried for one particular project, and in this case literally "why it's wrong". (After two weeks.) It's hard to take seriously.
  - deleted 10y ago
    [deleted]
pka 10y ago
You seem to miss the point. Elm is particularly easy to pick up for people coming from Haskell. Maybe not in 15 seconds, but 15 minutes is a totally reasonable estimate. The author can without doubt write a large project in Elm. His complaints were about missing the conveniences of abstraction Haskell-like languages provide, and he is more than qualified to talk about it. Decomposing records into tuples of comparables has probably crossed his mind :)
- logicallee 10y ago
  >15 minutes is a totally reasonable estimate [coming from Haskell]. The author can without doubt write a large project in Elm. Well, all right. In general I would say that is not true even for languages that are close, but there are exceptions and I suppose I can take your word for it.
  - pka 10y ago
    It's only because Elm is basic Haskell minus a lot of stuff. So basically if you know Haskell you already know Elm (so you need the 15 minutes to get up to speed wrt ports and subscriptions or whatever), but at the same time miss the stuff that has been left out that you take for granted, hence the failed attempt of the author to get some of that back.
    - logicallee 10y ago
      That could have been presented much more clearly in the article. It would be interesting to compare with the opinion/experience of someone who didn't know Haskell, well, right? (Though in that case perhaps the learning curve is too steep, maybe Elm isn't meant for that.)
      - elbear 10y ago
        Actually, that's the thing: Elm is designed for people who don't know Haskell. It's designed for JavaScript developers who are attracted by the "no runtime exceptions" claim. If you're coming from Haskell, you'll see Elm as a dumbed down, stripped version of Haskell, which will trigger in you the feelings it triggered in the OP.
mikekchar 10y ago
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.

mmarx 10y ago

> Okay, so now make a serious iOS app in Objective-C in "a few hours". As in, have one by this time tomorrow. See? It's crazy. That's not how it works. But then making an iOS app requires picking up frameworks/libraries, not only learning Objective C, which was exactly GP's point: >> Libraries and frameworks take a lot more time than languages.

logicallee 10y ago
From the article: "Unfortunately, Elm isn’t a library. It’s a language, which just happens to have a great library" I don't know why we're arguing about this. It's another blog poster writing about something new they tried for one particular project, and in this case literally "why it's wrong". (After two weeks.) It's hard to take seriously.
- deleted 10y ago
  [deleted]

pka 10y ago

You seem to miss the point. Elm is particularly easy to pick up for people coming from Haskell. Maybe not in 15 seconds, but 15 minutes is a totally reasonable estimate. The author can without doubt write a large project in Elm. His complaints were about missing the conveniences of abstraction Haskell-like languages provide, and he is more than qualified to talk about it. Decomposing records into tuples of comparables has probably crossed his mind :)

logicallee 10y ago
>15 minutes is a totally reasonable estimate [coming from Haskell]. The author can without doubt write a large project in Elm. Well, all right. In general I would say that is not true even for languages that are close, but there are exceptions and I suppose I can take your word for it.
- pka 10y ago
  It's only because Elm is basic Haskell minus a lot of stuff. So basically if you know Haskell you already know Elm (so you need the 15 minutes to get up to speed wrt ports and subscriptions or whatever), but at the same time miss the stuff that has been left out that you take for granted, hence the failed attempt of the author to get some of that back.
  - logicallee 10y ago
    That could have been presented much more clearly in the article. It would be interesting to compare with the opinion/experience of someone who didn't know Haskell, well, right? (Though in that case perhaps the learning curve is too steep, maybe Elm isn't meant for that.)
    - elbear 10y ago
      Actually, that's the thing: Elm is designed for people who don't know Haskell. It's designed for JavaScript developers who are attracted by the "no runtime exceptions" claim. If you're coming from Haskell, you'll see Elm as a dumbed down, stripped version of Haskell, which will trigger in you the feelings it triggered in the OP.

mikekchar 10y ago

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.