Swift was not given the chance to prove itself as a language
mastodon.social
mastodon.social
> Christopher Arthur Lattner (born 1978) is an American computer scientist, former Google and Tesla employee and co-founder of LLVM, Clang compiler, MLIR compiler infrastructure and the Swift programming language.
I have the sense that he and Apple knew exactly what they were doing. Using something established comes with it's own baggage and risks.
It's times like this I wish HN had 'fact-check' flagging for posts.
It was mandated from above.
> It's times like this I wish HN had 'fact-check' flagging for posts.
What exactly is not factual about the post?
It is likely that the litmus test came from his experience creating Objective-J. However, the Swift project began in the same timeframe, so even if we understand these things now, Objective-J shows that we didn’t back then.
Did the author mention Objective-J?
> It is likely that the litmus test came from his experience creating Objective-J.
So, your "fact check" is "it is likely"?
I have no idea what the second statement is trying to say.
The second statement is not n the context of this thread, I didn't look at the username and thought you were the original commenter I answered to :)
Again, it seems likely that his experience with Objective-J and it failing on those fronts is why he has come to think that way. If that is the case, then why would Apple magically have had the foresight he and his team lacked?
"I generally view that initial list (with some other items) as a kind of litmus test of whether it makes sense to write a new language:"
Therefore, Objective-J is the language that passed the test for him. But what did it actually bring to the table other than some interoperability with existing Apple APIs, which allowed direct use of Interface Builder? Which, as it happens, is also the same primary design goal Swift had.
The answer is: Nothing. Other projects at the time showed you could achieve 90% of same using plain old Javascript, despite Objective-J being clearly the better language, with already had a strong and mature ecosystem that was good enough. And therefore Objective-J should have never passed his litmus test.
Thus, his claims that he follows the litmus test is false. Or, more likely, has only become true in recent times due to his experience with Objective-J and how it failed on those fronts. But if that's the case then it is not clear how it applies to Apple as there was no reason for Apple to know any better back then either.
> You have a weird obsession
Where do you find relevance in this logical error?
Did he say that? Did he say he applied this test when he was creating Objective J 15 years ago? Did he say that Objective J passed this test?
Could it be that he applied his own experience, and experience of other languages and came up with the list as the result?
> Where do you find relevance in this logical error?
I find relevance in your weird obsession with the fact the author created Objective J 15 years ago and this somehow invalidates the points he's making.
I mean, you've now spent several comments and the last comment exclusively talking about Objective J. This is bordering on mania.
It is almost certain. I said that in the first comment and every single one that followed.
> I mean, you've now spent several comments and the last comment exclusively talking about Objective J.
I repeated the same thing several times because what I said was not understood by the recipient. Communication can be difficult and a different phrasing helps people here in good faith to understand what wasn't clear on an earlier attempt. As Objective-J was present the first time, it was necessary to include every time, else the message would have changed.
While you got the benefit of the doubt, with you now admitting that you are here in bad faith, what did you hope to gain from that?
I never admitted any bad faith because I never argued in bad faith.
However, this claim of yours perfectly describes how you approached the thread in the first place: you immediately assumed the worst of the person, assumed that person is arguing in bad faith, and presented your own negative bias and dislike as fact.
Since you are actually arguing in bad faith, I will not engage in this discussion any further.
Adieu.
Not so. You clearly stated that you were focused on my supposed "mania". That is an admission of bad faith. You know full well that even if it were true, it has no relevance to anything in this thread and is a fallacious diversion.
> you immediately assumed the worst of the person
I assumed nothing about the person until the person stated that he wanted to change the subject to talk about me. A random topic change is in bad faith, ad hominem is in bad faith, and bringing feelings to a discussion is in bad faith.
> I will not engage in this discussion any further.
Are you under the impression that this is a train station? You do not need to announce your departure. Logically, we understand you have stopped participating in the discussion when you stop participation in the discussion. This is another bad faith device.
Do better.
I don’t see how that follows, and think it isn’t true. They wanted [1]
a) a modern safe approachable [2] language
b) with excellent interoperability with their Objective-C code, so that it could gradually replace it.
c) that’s at least as time and space efficient as the Objective-C/C/C++ combo.
d) that they have control over.
d) alone implies they needed a new language, but even ignoring d), what were their options?
The ‘approachable’ in a) (IMO) rules out languages like rust (which also didn’t exist yet), b) implies they needed reference counting and strong typing, c) rules out anything interpreted or JVM-based.
[1] https://www.swift.org/about doesn’t mention most of these, but I don’t think that makes it untrue.
[2] I think they got that only partially. Swift looks like a simple language, but is not one (anymore)
They couldn’t have used an existing language without some serious compromises. The solution didn’t exist. The only choice was to go into uncharted territory.
> Swift didn't have to "earn" its place, prove that its benefits outweighed its downsides. The writing was on the wall, Apple was saying this is the future, which threw the entire community in to chaos
Italicized emphasis mine…I think that saying that the community was thrown into chaos is a bit of a stretch and a dramatization. There was no rug pull, you can still make Objective-C apps if you want to.
This was an exaggeration, for sure, but there was uncertainty: it wasn't a given that Apple would keep spending time on Objective-C and related libraries. Apple is well known for killing things, even long-established ones.
Is there something about Go that improves on that problem?
But even if you ignore that, there were plenty of choices: Go, D, Nim.
The key criteria was control.
> b) with excellent interoperability with their Objective-C code, so that it could gradually replace it.
The gap seems to have been closed somewhat, but RAM-wise I don’t think top of the line Android devices ever were far less capable, likely not even less capable.
For example: Apple still sells the iPhone 13 with 4Gb of RAM, the iPhone 15 has 6GB, the top of the line iPhone 15 Pro Max 8GB. The Google pixel 8 has 8GB, the Pixel 8 Pro 12GB RAM, and those aren’t the devices with the highest amount of RAM you can buy.
Having less RAM translates into having better standby time for the same battery size, or smaller batteries for the same standby time. I think that was and is important to Apple.
> But even if you ignore that, there were plenty of choices: Go, D, Nim.
I don’t see any of those qualify for the criterion “Or does there exist some other language that gets it close enough, plus has decades of work and stability going for it”
Go is from 2009, D technically from 2001, but in practice from 2007, when the standard library was replaced (https://en.wikipedia.org/wiki/D_(programming_language)#Histo...), NIM from 2008.
I emphasized the relevant part of your statement.
It's the bottom of the line Android devices that fall into the "far less capable" category
> decades of work and stability
Swift doesn't satisfy that criterion either. That's a no true scotsman.
Those who know, know.
Unfrequent is not how I would describe it.