Hacker News Reader

Comment by tubehouse | Hacker News Reader

I don't agree with this. Presumably this is going to be a long lived language. They should fix the problems as early as possible so that generations of developers don't have to keep reliving the same pain.

View on HN

As painful as it is in the short run, I am inclined to agree with this.

A story I heard once that I love to retell is that after Stu Feldman wrote the first version of 'make' for Unix, he realized that the syntax was borderline unusable, but he didn't want to fix it because he already had 10 users.

I've also heard that Chris Lattner didn't want to release Swift when he did, but was pressured by Apple into doing so. There's no question in retrospect that it wasn't ready, and I think it's entirely fair to beat up on Apple for pushing it out too soon. Nonetheless, since it is out, I think they should do their best to get it right.

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

-- Stu Feldman in The Art of Unix Programming

Disclaimer: I'm purposefully stretching to come to this conclusion, think of it as me transcribing an idle thought

I think people are taking out their frustration with C++ on Swift by saying it's fine to churn the language so we don't end up with a mess like C++ because they just despise the way the past of C++ has marred the present by existing, no matter how hard the language is trying to be in the present.

They feel Swift should move fast and break things so that we don't have to live with the mistakes of the past like C++ does.

The problem is even if we think what Swift is doing is perfect and let it solidify, odds are in the future we'll still come to despise it, and the parts we despise will eventually be old and well used enough they can't reasonably be changed by breaking stuff, and then it will be time for a new language to repeat the cycle.

(Replace C++ with Java or some other older language as preferred)

I think his main complaint is that Apple should stop publishing sample code (which they update sporadically at best) in Swift when the language is changing so much. At WWDC this year I believe virtually all code shown on screen was Swift, but ObjC would have been fine for almost everything.

More broadly, I think Apple should have marketed Swift as "beta" until at least v3, to really make clear (especially to managers) what it means to have a language with constant source-breaking changes.

" should stop publishing sample code (which they update sporadically at best)"

Ah? No. 'Sample code' is essential, often more valuable than the docs.

They are a $700 Billion dollar company.

You know what they can afford to do?

Have more sample code, better documentation - and update all of the goddam samples, moreover, to make it clear in each sample, which version applies.

You cut the quote off too early, I think they should have sample code in ObjC rather than Swift

Objective C is going to "die" fast. It's basically an Apple only language, and the community is quickly moving to Swift.

If you don't know either language, simply compare the code. Objective C is a much noisier language.

https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...

Apple doesn't dwell on the past. Most of their examples are in Swift for a reason.

I think that's completely reasonable and maybe the article would have been better with the much more sensible complaint that an official Apple code sample last updated at the end of October last year doesn't work in un-obvious ways today. That's just sloppy and frustrating and shouldn't happen - at a minimum it should be marked (temporarily) obsolete.

Reply on news.ycombinator.com