
Once it goes Open Source
Will a Windows version be far behind?
Apple will release version 2.0 of its Swift programming language as open source, with the aim of getting it everywhere. "We think Swift is the next big programming language," Apple software engineering veep Craig Federighi said during Monday's keynote address at the annual Worldwide Developer Conference (WWDC) in San Francisco …
Unfortunately, VirnetX lobbed a sueball and won the case. Apple had to re-write the way FT operates in such a way that avoids those patents and in the process made it worthless as an OS project.
IIRC the patents were around P2P connections used in the old version, the re-write means the connections are now made through a central server.
So you'd either have to OS the server software as well - and rely on people setting up their own servers - or you'd have to route all of your FT communications through Apple's servers.
Neither of those options strike me as something you'd really want.
This post has been deleted by its author
(good news, always nice to see more language options available, though most peter out quickly enough.)
I keep on meaning to check out Swift myself but haven't gotten around to it.
For those who have wrestled with it already, how is Swift's support for namespaces/module/package names? Had a talk with someone claiming it wasn't very good compared to C#'s. Saw some verbiage claiming both ways on SO, none the wiser for it. Can you differentiate moduleA.someclassname from moduleB.someclassname and use both those classes, easily?
And on a more general note, what are the design features that you disagree with? (besides Apple's parentage if that's not your thing)
Basically, I expect that, like for any software, any documentation will concentrate on Swift's virtues. Any be somewhat silent about its shortcomings.
Sometimes it is good to follow along while knowing which weak points to pay attention to rather than finding out dead ends later.
p.s. Could we have a less disturbing nicer pic of Taylor? They do exist. Still no need for an audio option on this article however ;-)
I think Swift's main attraction is that it's one platform to bind them all :).
I suspect the cunning plan is that by bringing Swift into Open Source, Apple ends up with more people feeling capable of developing applications for iOS and OSX, but being able to code doesn't immediately imply an ability to make it user friendly.
It'll be interesting to watch what happens. Apple tends to be less into public beta testing so I don't think it's a big risk for coders to invest time in Swift (it's not going to disappear overnight), but what interests me is how quickly they will adjust any issues or add missing features. Apple has never struck me at being terribly good at communicating (and by that I mean two-way, not marketing :) ), and Open Source only really works with bidirectional engagement.
What would make it really interesting is if an Android SDK emerged from a 3rd party, which is possible if it's really Open Source. I don't think it would harm Apple much, but their reaction would be worth watching.
When did people forget that language <> platform ?
I blame Microsoft and Sun/Oracle. They successfully conflated the two with Java and C# but as others have demonstrated, this is still just a conflation, not an equation.
If you want to do Android development using Swift you already can.... Use RemObjects Silver, an implementation of Swift from RemObjects with backend compilers for .net, iOS/OS X or Java (and therefore Android).
Although hosted in Visual Studio, you can even launch directly into Android Studio for doing your Android layouts visually, if you wish. You also use Xcode Interface Builder for your iOS/OS X UI designs in projects for those platforms (although for technical reasons you can't launch directly into Xcode in the same way that you can with Android Studio).
From the same company, for all of these platforms you can also use C# or Oxygene - their own very slick implementation of a very modern Object Pascal (with much to recommend it over its curly bracketed brethren).
JLV wrote: "And on a more general note, what are the design features that you disagree with?"
I admit that I may not be entirely up to date with the newest developments, but from what I remember from reading about it a while back:
- The choice of reference counting GC. It is slow and it necessitates using weak pointer if you create cyclic structures such as doubly-linked lists. There are concurrent GC algorithms that would be much better.
- That only objects are boxed. This makes it impossible to create a recursive enumerate without using objects.
- A rather verbose syntax for enumerates, as well as a few other odd syntactic choices.
Q: Can you run .NET without the CLR ?
A: No. The CLR is by DEFINITION part of the .NET execution environment. Without it nothing runs.
Q: So the CLR runs the code. But what in Comp Sci terms is the CLR ?
A: It is a VIRTUAL MACHINE.
Q: Is it then true to say that all .NET code runs in a VIRTUAL MACHINE ?
A: Yes. And anyone that says or thinks otherwise demonstrates in so doing that they are unqualified to comment further.
Q: Ok smartass - what about MONO then ? That runs .NET code but it can't be in any .NET virtual machine because it is specifically not .NET but an alternative to it.
A: Ok dumbass... read Mono's own definition of what it is... "The Mono runtime [is an open source implementation of the .NET] VIRTUAL MACHINE."
If you tried to be sarcastic, you should have said so. Instead it seems you are just clueless. Then you used the trick to claim that everyone correcting your nonsense must be a "fanboi dialing it up to 11". That makes you clueless and a troll.
For those who are interested: Let's say I want my application to run on iOS 7 and newer devices, but I want to use iOS 8 features if they are available. Obviously I can't use them when the phone runs only iOS 7, so a check must be done.
if #available (iOS 8, *) {
// Code that runs only on iOS 8
} else {
// Code that runs on iOS 7
}
And this works at runtime. The same code ships to all devices, and does the right thing on every device. So if you upgrade the OS on your device, you get new features in your apps without downloading a new version. Which would be impossible with the #if in the C or C++ preprocessor.
I wouldn't be keen on adding syntactic sugar for something that smells of bad practice in the first place. Such runtime checks really should be used only to choose the appropriate interface implementation for your platform - littering your code with these directives will not help maintainability.
Also, if that's the real syntax you've just posted, it's horrible, and at odds with how directives are used already in Swift. I had expected something like this:
#if available( iOS_8 )
blahblah();
#else
blah();
sleep(1); // "it's time to upgrade your iThing, puny human"
blah();
#endif
I don't think you understand how SWIFT is implemented, and the example you post above clearly demonstrates it. I don't think you understand how compilers work, either.
Your example above is a gem of useless and clueless code bloat. What you are proposing is that, at run-time, the application should check if specific features are available. That's just dumb. For one, you'd have code which never executes. For two, you'd be needlessly checking if the code which never executes should be executed. Imagine having that run-time check in your example inside a switch() or a loop.
This is precisely why conditional compilation was invented in the first place. So that unnecessary feature-tested code doesn't end up where it doesn't belong.
Now it could very well be that SWIFT uses a two-stage compilation: Stage 1 from source code to LLVM bytecode, and Stage 2 from LLVM bytecode to binary opcode. In either case, the feature-tested code that wouldn't be available on a particular version of the OS would be eliminated during Stage 2 compilation. Just like conditional compilation eliminates unnecessary code by means of preprocessor conditionals in languages like C, C++ and others.
Like I said: clueless Fanboi Fail, dialing it up to 11.
And I almost forgot: in SWIFT, you can declare variable names in Unicode. Meaning, you can use Emoji as variable names. That's one feature I was dying for. Not.
Your example above is a gem of useless and clueless code bloat. What you are proposing is that, at run-time, the application should check if specific features are available. That's just dumb. For one, you'd have code which never executes. For two, you'd be needlessly checking if the code which never executes should be executed. Imagine having that run-time check in your example inside a switch() or a loop.
If you'd ever written an OpenGL* application you'd know these sorts of run-time checks are extremely common. Not all hardware is created equal. Unless you want to only ever code for the lowest common denominator you must check which features are available at run-time. It is not feasible to ship multiple binaries when the hardware you're programming against is as diverse as GPUs are. I suspect programming for the SoCs found in mobile devices is a similar situation.
*Possibly DirectX as well, although I have no experience with it.
> If you'd ever written an OpenGL* application you'd know these sorts of run-time checks are extremely common.
1. This isn't OpenGL.
2. OpenGL doesn't have its own compiler, nor is it a programming language. It's a collection of precompiled libraries.
3. Yes, I've written OpenGL in the past.
4. SWIFT is a compiled general-purpose programming language, not a special-purpose application-layer graphics library.
WHOOSH. That is the sound of my point flying completely over your head.
At no point did I suggest OpenGL was a programming language. You check at runtime for available features in the system's OpenGL implementation using whatever language you're writing in, be that C++, Java, Python or whatever.
Similarly with SWIFT, you check at runtime if the library you're attempting to use supports the feature you want. The only difference is that SWIFT has a directive dedicated to the job whereas usually you'd have to use if/else statements paired with query functions provided by the library.
> At no point did I suggest OpenGL was a programming language.
Then why are you - STILL - comparing OpenGL to a general-purpose, compiled, programming language like SWIFT? Because Apples - pun intended - and Oranges?
Do you even understand the difference between what a pre-compiled library can and/or cannot do at run-time, and what a compiler can do with source code at compile-time?
It appears that you do not.
Fanboi.
Are you really this dense or am I being trolled?
Then why are you - STILL - comparing OpenGL to a general-purpose, compiled, programming language like SWIFT?
I didn't compare the two. I'm using an OpenGL application as an example of when you need to check at run-time which code path to use because it is not possible at compile time. If it helps focus your mind assume the application is written in C++. I used this example because you implied run-time checking was something that should never be done when clearly it has valid uses.
Fanboi.
I don't own any Apple products.
> I'm using an OpenGL application as an example of when you need to check at run-time which code path to use because it is not possible at compile time.
That would be an implicit comparison, yes?. We're discussing SWIFT here, correct? Where does OpenGL or any other library's run-time feature tests fit into compile-time conditional compilation?
> you need to check at run-time which code path to use because it is not possible at compile time
Why is conditional compilation not possible at SWIFT compile-time? Who said that it isn't?
I've just explained to you that compilers try their absolute best not to emit this type of run-time checking crap. A compiler's first and foremost duty is to eliminate as much code as possible. Eliminate as in: No longer there. Gone. Deleted.
> assume the application is written in C++.
What does C++ have to do with OpenGL? OpenGL is written in C, not C++. Run readelf -s /usr/lib/libGL.so or /usr/lib64/libGL.so; you won't find any mangled symbols. It's all C. Even the proprietary blobs from NVidia or AMD/ATI.
Again. Why are you comparing what compilers do with what shared libraries do?
> #available is for run-time feature checks.
Awesome then. It's not just your typical Apple Pile Of Crap, it's a total and complete Pile of Crap. An optimizing compiler which includes feature test code for every single version of iOS under the Sun.
At least Android can optimize for the device the software is installed on.
so we finally have the memory safe systems programming languages. the cyber crime/war domain can now be shrunken to reasonable size again.
after decades of malpractice with the bug-enabler C, we return to the sanity of strongly typed languages. thanks to niklaus wirth and other allaman engineers.
lets hope we can turn the it ship around before people start to use paper files again.
Exactly - C has been the biggest problem in the industry costing billions per year just because you can point a pointer anywhere and overrun the end of arrays, etc. I think younger programmers are being better taught these days to appreciate type-safe language.
While a lot seems based on Eiffel (which Apple certainly knew about), there do seem to be C-style explicit kludges making it in like try-catch, etc. Eiffel's exception handling is so much more elegant, being a part of the language from the base up, you don't need explicit try-catch.
And why do they have to stick to the old-looking C syntax? Oh I'll answer that myself - because most of the industry is not ready to move past it. Something that used some beautiful typography to really expose the structure of programs in an intelligent editor would have been nice, but programmers usually are the last to accept such things.
Further to my previous post saying that Eiffel's exceptions were subtle because they were baked into the language and runtime, rather than explicit like try-catch, I just saw this rather nice quote:
"GOOD DESIGN IS OBVIOUS. GREAT DESIGN IS TRANSPARENT"
at http://www.alivemobile.com/approach/#ourapproach
...could have had this, if they had done mre than copying java. essentialy they had almost every thing in their labs wity the c# based os kernel. if they only had some original analysis on languages. anyway, the internetvgot it figured out. now ms cwill playvcatchup. el reg s not nice to use from a phone...
> ...could have had this, if they had done mre than copying java
C# is objectively (no pun intended) well ahead of Java in terms of feature completeness and has been for years. Dynamics, generics, Java only just got lambda expressions for Christ's sake.
I'll agree that the concept is similar but Hjelsberg's execution is far, far better than Gosling's.
For simple, text and graphics apps, people are already tooled and schooled in Phonegap. Which will already deploy to a bunch of targets. If you're doing games, you're probably already using Unity. Does Swift work with PC, Xbox One, Wii U, PS4? So, who's going to go through wanting multiple codebases for all of those platforms?
I have played with Swift writing a couple of demo applications on OS X. The problem I had was that at least 95% of the information out there is about writing code for iOS. While there is much in common there are substantial differences between the two operating systems particularly the UI.
Having said that I do like Swift as its easy to write half decent code.
I had the same problems learning C# - almost all of the documentation and tutorials are also telling you how to use .NET for Windows, and particularly Windows Forms, whereas most of my interest was in writing cross-platform control code.
However, C# as a language can be used to write code for any platform, and so can .NET, if you stick to its Portable Class Library core. If you are looking for a guide, I recommend "C# in Depth" by Jon Skeet (pub. Manning), but you do need to be proficient in another language with C-family syntax (C, Java, C++) before beginning it.
Incidentally, as noted elsewhere, C# is not necessarily a JIT-translated language. Although it is most often run via JIT compilation, you can pre-compile complete assemblies into native machine code at install-time. But mere native code does not a systems language make: C# lacks low-level memory access operators for one thing. Does Swift? It's not clear from the introductory docs...
I've got no problems with a bewildering array of different languages. It'd just be nice if we could choose one that's pretty good (I don't care which one) and each platform implements it.
I can see a need for other languages on very different platforms like the web, but iPhones, Windows phones, Android phones and desktops all do basically the same job. It'd be nice if I didn't have to port my code over from Objective C to Java to C#.