The only thing that makes me sad is that because of their focus on secrecy, they're doomed to relearn all that we learned along the way. Having played with the swift playground stuff, just an hour long conversation could've made a big difference.
> because of their focus on secrecy, they're doomed to relearn all that we learned
That's wrong, condescending and misses the point. Wrong because the developers were not cut off from learning what was learned by others. Condescending in the way it implies that there's a royal "we" of people that should be consulted whenever any programming language is conceived. And it misses the point because some types of learning are learned better by making the mistake yourself rather than accepting the wisdom of authorities.
Anyway, I don't see how Swift's life cycle is any different from other most other languages, except that its inevitable celebrity has been tempered by its parents' protectiveness. The number of people expressing interest in nurturing a language in its formative stages grows in proportion to its viability. Swift went from experiment to viable as soon as it got chosen as the path forward from ObjC.
> just an hour long conversation could've made a big difference
Apple has huge numbers of programmers on staff, including many compiler hackers, many kernel hackers, many with practical experience building and maintaining APIs and developer tools. They employ literally thousands of programmers who will be end users of Swift. To suggest that your opinion is more valid than theirs is hubris.
Let's say you take direct inspiration for something you're working on and you know someone's been there and thought a lot about it. Wouldn't it make sense to ask them about it? It's certainly true that some mistakes are better learned by making them yourself, but a whole lot aren't. Hell, half the time it's just stuff you're too close to see anymore.
The Swift playground is strikingly similar to many of the things we've done in Light Table. It's wonderful that Apple is taking that and running with it and I want these things to end up out there and make things better for devs. But I could've helped them skip some of the crap along the way and I've worked with other large organizations to help them do exactly that.
> To suggest that your opinion is more valid than theirs is hubris.
My opinion is no more valid, but given that their work looks fairly like our own, I certainly have the benefit of past experience. This isn't about hubris. I have a unique perspective in this particular case, one that no one else will have, as the creator of one of the things they were "heavily influenced" by. I'd rather they took advantage of that so that they can continue to push things even further and not fall into some traps that we did at Microsoft and with LT itself.
In any case, I'm sorry I seem to have offended you. My goal is not self aggrandizement, it's just to help do my part in making things better for us all.
Well, don't hesitate to give them feedback now. They're staying it's still quite in a fluid state and will change before release. Plus I'm sure they'd always be grateful for feedback, and if it improves the lot of millions of developers (they say now 9M registered Apple devs), you've done the world a great favor.
“There is no limit to what a man can do so long as he does not care a straw who gets the credit for it.” Charles Edward Montague
On the other hand by keeping it secret and internal they avoided making bad decisions due to defensiveness and stubbornness.
An example of this is Go; they don't actually take input from outsiders (generics) and when they have had to give in to outside ideas they implement it poorly just to be different (exceptions as panic). They would rather people put in a no-op printf to avoid the unused package error rather than letting it be a warning because of their own self-righteousness.
Apple's secretive process may not be ideal, but there are far worse processes out there.
Wow, I'm not sure how to begin responding to that.
Go has taken a lot of suggestions from the open source community. Check the Go 1 mailing list discussions for examples. But panic existed before the opensource release and is not a substitute for exceptions, and nobody has actually proposed a viable generics implementation. The unused variable/package thing is a fundamental to the project's goals of working well at scale, and tools like goimports alleviate the pain (sometimes the answer is tools, not language changes).
Overall I'm pretty dismayed by your characterisation of Go as an open source project. We have a lot of great contributors from outside Google and your ignorant comments do them a great disservice.
I realize I'm in the Lion's Den. I feel that if you stepped outside the Google employee and Hacker News bubble you would see Go stubbornly refusing to have modern features, as I do.
I've been programming for 30 years and have written code that is in every Linux distro, and yes I did read the Go mailing list occasionally in the early days. But if it makes you feel better to call my opinions ignorant then I hope that's working out for you.
I agree with you. There is a lot to like in Go, but even I can see (and I've only been programming for ~10 years) that it ignored a lot of good stuff from other languages.
They keep saying they would add generics if they feel they could "do it right" but I'm starting to not believe that. I like that the language tooling is extremely disciplined and enforces even small things, like style, but this rankles a bit considering other parts of the language design seem a bit inconsistent or haphazard. Just IMO, of course.
> I've been programming for 30 years and have written code that is in every Linux distro
A very strange argument from authority considering Ken Thompson is one of Go's designers...
Considering the fact that 700 people attended the inaugural Go conference, and the variety of speakers (http://gophercon.com/schedule/), I think it's safe to say that Go has gained traction far beyond the Google employee and HN "bubbles".
The argument of authority of Go designers is actually my point. By designing the language in public (even before having source available) they now don't want to admit their errors, and neither do their supporters, because they are authorities, supposedly. I'm thinking of Pike in particular.
By keeping these discussions private, the Apple team did not need to protect their egos or their authority. We do not know who is responsible for which decisions at which points in the design, and they don't feel the need to defend their choices in public.
The Go team has admitted several errors publicly (e.g. var binding for range loops, some standard library design) on multiple occasions. Those errors won't be changed because we consider preserving backward compatibility more important. You could say that holding on to backward compatibility is "defensiveness and stubbornness", but it's really just making a different decision to what you may have done in the same situation.
In fact, your premise is almost entirely incorrect. Probably 95% of Go's language design happened before it was open sourced, so it's in exactly the same situation as Swift. The Go language hasn't changed a lot since November 2009.
I wasn't calling your opinions ignorant. I made several factual corrections about your post. You also made further incorrect statements about the development timeline of go (dsymonds corrected you there). No offense was intended, but in general I'm of the opinion that you should get your facts straight when criticising something publicly.
Also I've gotta laugh at "lions den". I've been reading HNers (like yourself) broadly condemn Go for nearly five years.
And are you going to laugh all the way over to r/programming? There is some criticism on HN. Where there are no holds barred it's really brutal. I don't blame you as a Go developer for avoiding those forums.
> incorrect statements about the development timeline of go (dsymonds corrected you there).
Go authors retconned their decision making process in talks, lists, and on the web, which in terms of feeling defensive about it now is the same thing.
You said the Go team "[designed] the language in public". I pointed out that there's only a small amount of difference between the first public unveiling of Go and its current state, which you can verify for yourself.
You said the Go team "now don't want to admit their errors". I pointed out that we've admitted lots of errors, publicly, which you can verify for yourself.
Your criticisms seem scattershot and just don't make sense.
I stopped regularly visiting /r/programming before I started working on Go. The standard of discourse is too low; too many people eager to dickwave by sharing their negative opinions. HN can be bad but at least I can have a vaguely sane conversation here from time to time.
> The only thing that makes me sad is that because of their focus on secrecy, they're doomed to relearn all that we learned along the way.
But you're not focused on secrecy, so you can publish the lessons you've learned along the way publicly. That way, everyone, including Apple, can skip some of the mistakes. Wouldn't that be the case?
I would be very interested to hear what you think might have benefitted from the experiences of LightTable. Are they things you think could evolve convergently in the future, or are they mutually exclusive design choices?
When he said they hope to redefine how computer science is taught, that's a great goal (and to an outsider Swift looks great) but have they spoke to an academic about that idea?
If they take the Microsoft approach of being nice to schools that'd be awesome - much better to teach kids Swift than how to use Office. So if they're talking about schools, there's probably some private ones that would be interested but it'd take a crazy effort to crack teaching in schools on a wide scale.
Universities, not a chance. It might be great but it's not going to be an academic's choice of teaching language however good it might be for that.
And with those nice closures, generics, monadic patterns, ... They even have a nice way to introduce useful abstract concepts at lower level classes (not that they couldn't make it without... It's just funnier and with higher incentive if you can build ios apps out of it)
Such is the way of Apple though.