Hey Apple, we're gonna tailor Swift as open source – indie devs throw down gauntlet A group of independent developers has launched a project to develop a free, open source implementation of Apple's Swift programming language. Dubbed Phoenix, the project is being developed under the auspices of Ind.ie, a group that claims to want to develop "consumer products that are beautiful, free, social, accessible, …
Apple likes to move slowly with new stuff, like how they had the infrastructure for third party apps in iOS from day one, but didn't announce it as a feature they made available until iOS 2.0.
Whan Lattner was asked a few months ago he said it hasn't been decided yet and there is a lot of stuff yet to do before it even goes to version 1.0, but that he and others would like it to be open source and included in LLVM.
"like how they had the infrastructure for third party apps in iOS from day one, but didn't announce it as a feature they made available until iOS 2.0."
You will need to cite a source for a statement like that, because it doesn't agree with anything I heard from inside Apple at the time, and it reads like revisionism to shore up the narrative that Apple planned the mobile app revolution, when in truth it took them as much by surprise as anyone else.
I think singing the praises of Stallmann, who famously danced on Steve Jobs' grave, isn't going to convince anyone at Apple. And nothing will convince Apple to release anything under the GPL license.
It is quite evident that the purpose of Swift is to make it easier to write efficient and safe software for iOS and MacOS X. And that Apple has no interest to make it easier to write efficient and safe software for anything else.
I don't agree with the second statement, based on the LLVM track record. It was first released in 2003. Chris Lattner was hired by Apple specifically to work on LLVM for them in 2005, where amongst other duties he has added to it technologies intended to make it easier to write efficient and safe software for iOS and Mac OS X: ARC being the most obvious one. Those are completely open source.
Apple has effectively owned LLVM for more than 80% of its life and hasn't made any attempt to close the source — which might have been legally possible (as the original author's ownership isn't subject to the licence he offers the rest of the world, but I don't know who else had contributed) but regardless could easily have been achieved in practice by having Lattner work on a new compiler that wasn't LLVM.
I'm willing to bet that Swift isn't open source because, as evidenced by Apple telling everyone that the exact final syntax is still up for grabs, the company doesn't want to commit to anything yet.
Unlike Clang and LLVM, the Swift-specific parts of the compiler toolchain are not open source. Apple has the resources and influence to ensure the success of Swift even if it is the only company using it at scale (cf. Objective-C). Nevertheless, powerful factions within the company are undoubtedly in favor of making Swift an open source project. The push to release Yosemite and iOS 8 has likely taken precedence so far, but I expect this issue to be revisited.
- http://arstechnica.com/apple/2014/10/os-x-10-10/23/#shape-of-the-future
I like the idea of a next-gen language that is C-inspired, a la D or Go. By that, I mean relatively simple and limited in its syntax, but still powerful, with a clean syntax and built for speed.
i.e. lump the C and Python/Bash/Ruby/LISP lessons together. Add a (small) smidgen of C++**/Java as required and stir.
Agree that Apple has little upside from actively promoting Swift to OSS, but will it quash it?
Wonder if they'll pull a Sun/Oracle and get all hissy on the API/test suite whatever...
Or will it be benign neglect* a la MS/Mono?
OTOH, what is the downside to Apple if Swift takes off? Can't see it being pushed by the other big players, so the competitive risk is low. Its unique selling point is probably largely tied to a clean integration to iOS/OSX APIs anyway. A good way to acquire some geek cred if it becomes popular? Java was good for Sun's profile, even if their own apps on it seemed to be the least polished of breed to me.
Still, sharing more than strictly necessary doesn't seem that much in Apple's DNA.
* actually, I have no idea how much/little MS has supported Mono.
** Not dissing C++ here. Languages like Swift don't need the full complexities of a low-level system language however.
I like the idea of next-gen language too. And Apple would benefit from making it either open-source or standardized (or both). Here is how it might work: if a language is freely available and attractive for wide audience, it will be used. The more it's used, the more developers familiar with it. This last point would directly benefit Apple ecosystem.
Looking at Swift, it seems well designed - and it also has the benefit of supporting shebang script syntax, so it can be used more universally (if made universally available). If it could be also used for scripting of dynamic web pages that would be ideal, I cannot wait for something to replace this abomination called PHP.
Open sourcing either the code or making the specification public are very good ideas for languages. Universities are then likely to pick them up and identify the nice and not so nice parts. I can see a reluctance to do this initially on Apple's behalf as they will want complete control over the first few versions to fit the MacOS / IOS world as good as possible.
Despite Apple's history of serious fuck ups when including open source stuff with the products they do have a reasonable track record with the open source projects they either steward or contribute to (CUPS, BSD, llvm). But WebKit has also shown how company priorities can scupper this: Apple actively resisted a lot of changes in WebKit which is why Google ended up forking it.
Putting a language under GPL is just posturing and helps no one.
Apple have a pretty good record in supporting OSS projects, although most of it dates to the OSX days, before iOS took over as the revenue earner, and when Apple was small enough to need to play nice with other systems. The CUPS printing system, zeroConf networking (Bonjour/Rendezvous), clang, WebKit, and lots of BSD improvements have all come from Apple.
What Apple do not do, however, is release under GPL, preferring the more permissive BSD licence, which may be why some of the more vociferous (and self-appointed) sections of the FOSS "community" are so negative towards the company.
Incidentally, to the earlier poster, Microsoft's attitude towards Mono has moved from benign neglect to active support (notably by open-sourcing all of the .NET documentation and API definitions) to ensure that Mono and .NET do not diverge in behaviour and function --- something that is in the interest of both parties.
It would be a good model for Apple to adopt if it wants people to care about its language. Right now, I certainly don't: What good is a language that I can only develop on 10% of the world's PCs, and deploy to 50% (and falling) of the world's portable devices? For all its typist-hostile syntax, at least Objective-C can seamlessly include C (or even C++) code.
Just head over to remobjects.com, purchase a license for their Elements cross-platform compiler suite and grab the beta of the 8.x release. This includes compilers for Oxygene (ObjectPascal), Hydrogene (C#) and Silver (Swift). All three language compilers can be used to target .NET, Java (including Android) and iOS/OS X. Swift is currently supported only in the 8.x beta, but has been in beta for a few weeks now (almost time to start saying "months") so should be ready for release fairly soon I should think (I have no way of knowing for sure).
C# and ObejctPascal support is well established (don't poo-poo the ObjectPascal support - it's a very sophisticated dialect of ObjectPascal).
In each case you are targeting and working directly in the native platform environment - when compiling for Java you link to and emit the Java byte code of the Java VM. MSIL for .NET and Cocoa for iOS/OS X etc. There is no cross-platform abstraction between your code and the platform.
There is some neat compiler tech and a supporting (optional) RTL that maps abstractions of type specifics onto platform specifics, so you can share platform neutral code across the different platforms, but platform specifics remain, well, specific, resulting in lightweight, efficient apps that are truly first-class citizens on each of the supported platforms.
And all this inside the familiar environment of Visual Studio (although they also have their own OS X native IDE also in beta, not as a replacement for Visual Studio, but as an OS X native alternative for those that might prefer it).
Apologies if this comes across as an advertorial for RemObjects - it isn't. I have no connection with them other than being a very happy and impressed customer who wishes to spread the word. Too many people seem to think that Xamarin is the only game in town as an alternative to a kit bag of Xcode, Eclipse and Visual Studio.
If the guys at RemObjects were able to produce a Swift compiler, why does this "ind.ie" bunch feel the need to whinge at Apple about the openness (or not) of the language hampering their efforts ?
... of SWIFT?
Yet Another Programming Language Nobody Really Uses? Like Go?
This is one of the major reasons so many terrible, no-good bugs creep up in software, and go undetected for years: layer upon layer upon layer of languages and frameworks, each of them with their different runtimes and peculiar quirks. Please say Hello to the geometric progression of compiler bugs.
NeXTSTEP - OS X and iOS's foundation - is not written in SWIFT - it's written in C and Objective-C. Then C++ was added. The Objective-C++ was added on top of that.
There already exist two systems programming languages with a proven track record: C and C++. You don't need SWIFT to write systems stuff. Nobody is going to rewrite systems-level stuff in SWIFT either. Most of the systems stuff is C anyway, plus assembler.
You want C++ abstraction of GUI toolkits because you don't want to program directly to Xlib or Xt? NeXTSTEP did a pretty good job of that. There are other GUI Toolkits available as well, written in C++. See Qt.
You desperately want to write apps in some Fat Pasty Goo Language? That's what Java is for.
So what exactly does SWIFT do that no other language could already do?
Yes, not being Java is a good thing. From a brief look at the manual, it looks like a nice, general purpose programming language; good for both ad-hoc scripting (a la Perl/Phython) all the way up to app development. It would be nice if Apple went for standardisation.
> http://arstechnica.com/apple/2014/10/os-x-10-10/21/
Read it. As expected, it's a marketing puff piece for Apple pretending to be a technical overview.
Here's an example of why SWIFT is Totally Awesome:
<QUOTE>
var c = a + b // this needs to be fast
CPUs have instructions for adding two numbers together. Integer values in a low-level language like C must be explicitly declared as such and are stored in memory in a format the CPU is able to consume without modification. The reward for this approach is that C integers can be operated on directly by a CPU’s ADD instruction. Said instruction is exactly what a C compiler will generate in response to some code that adds two integers.
</QUOTE>
As a compiler writer - that's what I do for a living - reading this is Pure Awesomeness. SWIFT can add two integers, and store the result in a variable. And the addition operation is performed by the CPU, which will operate directly on the two integers. And it's gotta be fast too, because the comment says so.
No other programming language can add two integers and store the result in a variable, today. Apple Has Done It Again. It's Magic!
And then, we move on to another Totally Awesome Feature of SWIFT: we can write a function which adds two integers - passed in as function parameters, and the function will return the result of the addition:
<QUOTE>
func add(a : Int, b : Int) -> Int {
return a + b
}
</QUOTE>
Yay for the SWIFT function declaration syntax. No other programing language can declare a function taking two integer parameters and returning the sum. Again, Apple Has Done It Again. This is a defining moment for computer science. We can now have functions taking parameters, operating on said parameters, and returning a result. All of it courtesy of Apple.
And the article goes on and on and on, with pretty graphics, about LLVM, and the LLVM IR, and how the LLVM backend transforms LLVM IR into machine code, and how this is, again, Totally Awesome.
Yet another interpreted scripting language. Because there weren't enough of them already.
The article is a very entertaining read. Not sure that was its intended purpose, though.
You might want to reread that article.
The point of that section is: the language was designed by the compiler author. In this specific case he wanted to make sure the plus operator could be defined per class without adding any baggage to a normal integer add — adding nothing, in machine code, beyond what the C would generate — and he wanted to do it without creating a special case. To which a discussion of how a modern compiler works is relevant because it helps us understand the mindset behind the new language.
Not a single line of that piece claims "Apple Has Done It Again". You're erecting a straw man.
No, I really don't need to re-read that article.
I don't care who designed the SWIFT language. It is a useless scripting language.
You might want to re-read what you wrote. I'll give you a hint: unless you are a compiler writer yourself, and you have a direct understanding on how compilers work, and what they do, you should refrain from playing compiler expert on the Internet, because you will get called on it. And this is exactly what's going to happen right now:
What you wrote about the differences between overloading the plus operator on a per-abstract-data-type basis vs. the builtin plus operator for native types makes absolutely no sense whatsoever. The semantics of the overloaded plus - or any other arithmetic - operator for abstract-data-types, is programmer-defined. What these overloaded operators do depends entirely on what the programmer wrote them to do.
The semantics of the plus operator for native types is always compiler-defined. Most of the time it reduces to an add of two registers, with the exception of complex numbers, where a pair of adds of two registers is involved.
The user-defined abstract-data-type overloaded plus operator can be defined to add (concatenate) or subtract strings for example. Can you explain how concatenating two strings of unknown size at compile-time, and storing the result in a third string, also of unknown size at compile-time, can be strength reduced to the native integer add case?
I can tell you right now that LLVM IR cannot, and does not do that. Nor can you store a string in a register.
Claiming that it is possible to apply strength reduction to an overloaded plus operator in such a way that it always reduces to the integer add case, and therefore only the integer add case ever needs to be emitted in machine code, is pure bullshit.
You can always prove that I am wrong, of course. The only thing you need to do is:
- write an example program in SWIFT, containing an user-defined overloaded add (plus) operator, operating on two strings, and post it here
- post the resulting LLVM IR of this SWIFT example program, showing that only the native integer add case is emitted for concatenating the strings
My previous comment simply pointed out that you had misunderstood the Ars article. It's a technical discussion of how Swift works and why it was designed as it is. It is not an evaluation of Swift versus other languages. It is not an evaluation of LLVM versus other compilers.
Similarly my post claims only to be about what the Ars article is meant to convey. It does not at any point make the claim that I know anything more about compiler writing than what is stated in the contents of that article.
But what I'm enjoying is that I accused you of constructing straw men and you responded with:
"Can you explain how concatenating two strings of unknown size at compile-time, and storing the result in a third string, also of unknown size at compile-time, can be strength reduced to the native integer add case?", something neither I nor anybody else had claimed or come close to claiming, before segueing into: "Claiming that it is possible to apply strength reduction to an overloaded plus operator in such a way that it always reduces to the integer add case, and therefore only the integer add case ever needs to be emitted in machine code, is pure bullshit."
I am honestly unsure whether you're just a brilliant satirist. Kudos to you if so.
You may be (or claim to be) a compiler writer, but this says nothing about your English language comprehension skills which would appear to be somewhat lacking.
Swift is not a scripting language. It is sufficiently high level that it can LOOK like one, which is why the article makes numerous and extensive comparisons to features in scripting languages (type inference etc) and explains how Swift takes those high level concepts but manages to apply it in a non-scripted language.
I'm afraid you really, REALLY do need to re-read the article.
"I don't care who designed the SWIFT language. It is a useless scripting language."
Interesting. I've been writing Objective C since the Preview of OS X. I decided to rewrite some of my apps in Swift and have pleasantly discovered a reduction in code complexity and an uptick in my satisfaction.
YOU may think it is "useless". Fine. No one is forcing you to use Swift. Write in C or C++ (we won't even start with the serious semantic issues with C++). The problem with user-interactive apps is that they depend on the speed of the user. Since few users operate at the Gigahertz level, most of your complaints are null and void.
In other words, you may have a point, it just isn't applicable.
As for being a compiler writer, huh, I happened to do my Master's work in compiler design. The goal of a language is to allow a user to MORE EASILY control the device. No language is a panacea - and I know quite a few (I stopped counting after 20 and these don't count the ones I designed). Some languages are more complex than others. Some are better designed than others.
But you don't like Swift. Okay, fine. You don't have to like it.
Whether you think it is useful or not is irrelevant. Whether you think it is a good language or not is irrelevant. A problem existed and Swift solves it quite nicely. Again, whether you think it does or not is irrelevant.
It's absolutely fine to have an opinion. However, your opinion is just that - it doesn't change or affect reality. It is just your opinion.
Since the Swift language has some good features, a multiplatform open-source version would be a nice thing.
However, Apple quite rightly lacks confidence in its ability to compete with Microsoft (and/or Google, in the case of the Android platform) without its own proprietary world. Vendor lock-in is needed because while the Macintosh and the iPhone are perceived as superior products, Apple is not able - no one would be able - to consistently maintain the level of superiority needed to justify the kind of premium prices they want to charge, to be the kind of company they want to be.
The problem with Apple is not that it lacks confidence, but it has too much confidence. If it had no confidence at all, it would make clone Wintel PCs and clone Android phones. If it had a more reasonable degree of confidence, it might make products that contribute something useful, but which are relevant to everyone, not just a few for whom money is not a consideration.
But at least Apple has managed to survive all these years. The Amiga and the Atari ST did not survive, and Nokia and Blackberry didn't do so well either. So while I'm disappointed in Apple for being irrelevant to most people, maybe charging high premium prices is the only way to survive in competition with the mass-market giants - to be able to be more innovative than they are on a base of much smaller sales.
If Stallman didn't write GCC, the probability is someone else would have written another open source compiler instead. I suspect an argument could be made that it would have been better done another way - for the last 20 years or so I've frequently run into bugs that turned out to be gcc bugs, not bugs in the code compiled by gcc. A compiler developed by someone else may have been able to do a better job if not shackled to someone going around with a hard disk platter on his head.
Here's one reason why gcc is losing mindshare:
*p++ = func(*p);
Guess when p is incremented?
... No, you'd think that, but apparently, because the C specification is silent on the matter, the super geniuses running gcc believe that gives them the freedom to generate this sequence:
++p;
result=func( *p );
*p=result;
Now, has anyone ever written code where that was the desired outcome? This kind of dumb pedantry is why clang is becoming popular. (This bug isn't mine, but I've been stung by similar gcc "technically correct, but bloody stupid" behaviour in the past)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
