If you had followed what Owens has written and done in Swift, you know that he has worked and pondered the language quite a bit. Dismissing it as due to "blub" is disingenuous.
Aside from brushing away the value of his opinions, such a statement also implies that Swift is in some way sufficiently removed from mainstream languages as to feel "foreign". That is not true. Swift is a pragmatic amalgam of features from many modern languages.
The issue here is that many of the ideas are not fully realized and stunted to work within the constraints for the language (such as seamless C/ObjC interop). This is what is causing generics to only be halfway there (and same with several other features). In generics, Swift aims for strictly typed, reified generics, but then leaves you only with very crude tools to create them with. Generics in Swift is an exercise in frustration. Owens' feelings for generics might have changed if the support had been more complete.
When it comes to programming language reviews I don't think there is any value in them regardless of who is doing the review. Steve Yegge in one of his epic posts explains why everyone should design a language from scratch to see what the process is like. Once you do that the magic and wonder disappears and you realize both how hard and easy it can be depending on what constraints you have. Here's a nice starting point http://nathansuniversity.com/.
You're the one who evoked "blub", essentially insinuating that the reason for his inability to appreciate the language was due to him not being used to it.
I addressed that, and your counter with that it's "hard to make a programming language"?
Of course it's hard. And the problem with Swift is that it tried to do so many things at once, even with the hard constraints it had. And this is precisely why the language ends up short of its goal.
Speaking of ObjC 3.0, the point of the author is simply that an incremental improvement on ObjC which simply removes redundant syntax from ObjC would have been just as useful but much easier to get up and running.
The features that Swift tries to incorporate are admirable and interesting for the most part, but the implementation falls short because it's quite simply too ambitious to even reach "usable" until 3.0 or something.
You're putting words in my mouth. I did not say "it is hard to make programming languages". It is a skill like any other that can be improved with sustained practice. My point is most of these conversations about the merits/demerits of languages are less than useless. Here's a programming language checklist http://colinm.org/language_checklist.html and another one about the history of programming languages http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m.... This post was just a variation of the checklist which indicates to me the author is not really interested in any kind of deep analysis of the language and is just publicly bitching and moaning. That to me is an indicator of the blub disease.
Regarding "blub" I already told you that this is unlikely given the amount of dialog and work Owens has done in the language so far.
He is one of the few people who has written in depth about the language (not tutorials)
If you didn't like my attempt to make sense of your non-sequitor about programming languages, you should perhaps reconsider your approach to commenting / writing.
Just saying that he is pulling opinions out of the blue ("not really interested in any kind of deep analysis") is blatantly false, as his other articles IN THAT BLOG amply demonstrates.
>Regarding "blub" I already told you that this is unlikely given the amount of dialog and work Owens has done in the language so far. He is one of the few people who has written in depth about the language (not tutorials)
Well, if said post is anything to go by, that's not saying much...
An uniformed post with several questionable arguments is totally fine to judge someone's understanding of a language.
And if it's the "last chapter" of his posts (that is, something he wrote after several previous posts exploring the language), it's even better to see if his opinions are "worth reading". In the sense that a first post with his initial impressions of the language would be more excusable not to be that good.
Plus, reading the "last chapters of books to see if they're worth reading" sounds a perfectly OK way to judge something like a technical book. If the last chapters are crap why would the previous be any better?
If you weren't talking about technical books, then the analogy doesn't applu. Tech posts are not some linear narrative like a book, where you don't read the last chapters because you'll might get some spoiler. In fact it's common to skip the first introductory chapters in tech books, since they are mostly intended for beginners.
Well, I told you that the blog forms a narrative, of which the entry forms a part. His reasons for reaching the conclusions in this entry is based on earlier investigations, which are detailed in previous blog entries. The accusation that this entry is lacking context is similar to claiming the same from reading the end of a book, in that of course it won't make any sense unless you actually have read the parts that form the context.
The his experiments with the language and basis for his statements is investigated in detail in the previous entries. When I point that out, you claim to be unwilling to read them because the last entry did not make sense. How is this NOT like having dismissed the last chapter as not making sense as a stand-alone story and refusing to read the rest?
The text we're discussing on the other hand is to be understood as an commentary on the language after using for quite a while.
To me (and just to put this in perspective, I've written well in excess of 10k LOC of Swift during the summer) his issues make perfect sense - when seeing them with a somewhat experienced eye. For example, issues with Swift generics isn't immediately apparent. It's only after using them for a while that you can say that the missing features ARE indeed lacking for everyday usage, and this is not just a theoretical problem.
Similarly, the problems with Optional isn't really obvious from the beginning. (And optionals seemed like such a win initially. Built in Optionals! The language built to support it everywhere. Seamless interop with ObjC. Safe unwrapping! Syntax sugar for flatmap etc etc. And then it ended up being just as much a burden as it was a help)
This would suggest that the very reason that you see this as "an uniformed post with several questionable arguments" is actually because you have very little experience in the language. Consequently you see what you believe are meaningless or "questionable" arguments, simply because you believe someone wrote the blog article with similar [limited] experience with the language.
Since his issues aren't obvious at a glance, you conclude that they are false, never entertaining the idea that they represent a much deeper understanding of the language than you have achieved.
Aside from brushing away the value of his opinions, such a statement also implies that Swift is in some way sufficiently removed from mainstream languages as to feel "foreign". That is not true. Swift is a pragmatic amalgam of features from many modern languages.
The issue here is that many of the ideas are not fully realized and stunted to work within the constraints for the language (such as seamless C/ObjC interop). This is what is causing generics to only be halfway there (and same with several other features). In generics, Swift aims for strictly typed, reified generics, but then leaves you only with very crude tools to create them with. Generics in Swift is an exercise in frustration. Owens' feelings for generics might have changed if the support had been more complete.