It's my understanding that Windows has (or soon will have) a clang/llvm implementation. So it stands to reason that this implementation will have access to the Windows file system, OS APIs, etc. -- and any programming language running using clang/llvm will be able to issue the equivalent of lprint, print, println() ... whatever.
Every compiler needs to have code written specific to a platform to implement certain functions, sometimes those functions are tied to operating system features. You can even find compilers that support hardware with no operating system at all.
Sure, C++ implementations already have this in place -- and any new clang compiler would need to implement it -- be it for C, C#, C++, BASIC, Swift ...
The point is there is incentive for a vendor to implement C++ for his platform. There is little incentive at the moment to port Swift to other platforms.
But isn't that one of the reasons that groups (including C++) are implementing clang/llvm -- because, it gives them cross-platform capability (among other significant advantages)?
People are moving to clang/LLVM for many reasons, the big reasons are as follows:
1. It is open source with a good license.
2. It is proven to be a state of the art suite of tools.
3. Specifically the C++ compiler is a fantastic bleeding edge implementation of the standard.
I really appreciate all the knowledge that you and asdasd have and the effort that you both have expended.
But, I have an uneasy felling that the answers I'm getting are:
C++ is the cross-platform solution because: C++ already is the cross-platform solution
Swift can never be the cross-platform solution because: C++ already is the cross-platform solution
C++ is cross platform because it was derived from C which was developed to support systems level programming. In other words it supports putting operating systems onto processors. So C or C++ is often the first programming language on a platform. Beyond that many "programming languages" are implemented in C++. So before you port your BASIC, COBOL or other trendy language you often need to have C/C++ implemented to port that language.
Somewhere, in this thread it was posted that C++ is a committee effort and evolves very slowly (dragging baggage forward)
Being slow is on purpose. You don't want a language to change too fast, especially one as advance as C++. Even today it is hard to find a language that supports as many concepts and is as flexible as C++.
This disturbs me because it enforces the status quo in the rapidly evolving field of technology [programming]
That is baloney honestly. In the latest standard, C++ is practically a new language. Beyond that the code bases supported by C++ often end up existing for decades. This is perhaps why the standards committee is so important. It assures a stable platform with a rational evolution program.
Contrast this with Swift which is under Apples control and by their admission probably won't be stable for two years. It just isn't possible for somebody to buy into a Swift port when it isn't clear where Apple is taking it. So I don't see people even considering a Swift port anytime soon.
It is ripe for disruption!
Not really! At least at this point in time Swift isn't a suitable replacement for C++.
BTW, I remember when CoBOL was the cross-platform programming language -- I even taught classes in it -- on several platforms in several countries.
From a programmer's perspective, how does C# compare to Obj-C? To Swift?
It depends upon your perspective but honestly I hate Objective C / Cocoa
Don't you think MS will use Swift when they write apps for Macs and iDevices?
For user interface code maybe.
What if Swift proves to be a superior programming language/IDE to C#?
The language and IDE are two different things. I can't speak to C# from experience but the language is well received. The problem isn't C# but rather the platform it is implemented on.
What if IBM/Apple make significant inroads into the MS domination of enterprise IT?
Wishful thinking.
What if all the above prove that Swift offers significant productivity and maintainability advantages over C#?
Doesn't matter, the critical parts of enterprise will never run on Apples hardware/software.
What if MS realizes that it needs Swift to protect it's declining install base?
I'm not eve sure where this nonsense comes from. Apple doesn't have the hardware to support most the enterprise world.
What if MS realizes that it need Swift to be competitive in the mobile (computer, tablet, phone, etc.) area?
MS has already lost that market.
What if Apple outs Swift ala WebKit?
People would still need to adopt it. There would need to be a compelling incentive to do so. At this point I don't see one.
If any of this plays out, I suspect it would take 12 - 18 months ...
Apple themselves have said that it will likely take two years.
But, if I were MS, it would make sense to have a skunk-works project to implement Swift -- just in case!
Why?
I don't think MS will be able to play the embrace and extend/subsume card with Swift -- been there too any times, already.
I agree with what wizard69 says about Swift: it's likely going to take the same path as Obj-C and be embraced by Apple only. Apple would need to create a formal language specification (there is a book for developers, but it's not a formal specification) and an independent committee comprised of members from the larger tech community if they wanted Swift to be cross-platform. I don't see the incentive for them to do that.
That being said, given what I've seen in the past, I have no doubt that MS and others are looking closely at some of the innovations in Swift
and will absorb them into their own technology stack at some point (much like they did with Java).
I agree with what wizard69 says about Swift: it's likely going to take the same path as Obj-C and be embraced by Apple only.
This appears to be the most likely avenue.
Apple would need to create a formal language specification (there is a book for developers, but it's not a formal specification) and an independent committee comprised of members from the larger tech community if they wanted Swift to be cross-platform. I don't see the incentive for them to do that.
Apple is hard to figure out here. I could see them offering up a standard in the same way they offered up one for OpenCL. Apple has been heavily involved in things like JavaScript and "C" standards too.
That being said, given what I've seen in the past, I have no doubt that MS and others are looking closely at some of the innovations in Swift
and will absorb them into their own technology stack at some point (much like they did with Java).
As much as I hate Windows, MS has some really smart people working for them. They most likely have been thiniking about the same ideas anyways.
I think the buyers of an Apple iWatch will be a very niche market.
lol - the personal computer was criticized as being appealing to a niche market and thus a fad or of limited appeal. Then the iPod, iPhone and iPad too.
I think the smartwatches that have been released so far have demonstrated that the market appeal is small if they are built a certain way. A wearable that is designed nicely with an always-on data connection would have more appeal.
iBeacons for example would be annoying if you walk near a store, get a notification and have to pull the phone out of your pocket but glancing at a watch is easier. Paying for things would be easier with a watch too as well as directions. If you get lost in a shopping center, you can just ask Siri 'where is McDonalds?' and it will tell you not only where you are but have walking directions to the store and then give you a voucher when you get there.
I think Siri would be more useful on a watch because it would become your primary means of using it and so it would become more like your personal assistant. Local voice decoding would be better though. They could have a local decoding engine that keeps getting updated even from server data to better recognize what you're saying.
I think the buyers of an Apple iWatch will be a very niche market.
lol - the personal computer was criticized as being appealing to a niche market and thus a fad or of limited appeal. Then the iPod, iPhone and iPad too.
I think the smartwatches that have been released so far have demonstrated that the market appeal is small if they are built a certain way. A wearable that is designed nicely with an always-on data connection would have more appeal.
iBeacons for example would be annoying if you walk near a store, get a notification and have to pull the phone out of your pocket but glancing at a watch is easier. Paying for things would be easier with a watch too as well as directions. If you get lost in a shopping center, you can just ask Siri 'where is McDonalds?' and it will tell you not only where you are but have walking directions to the store and then give you a voucher when you get there.
I think Siri would be more useful on a watch because it would become your primary means of using it and so it would become more like your personal assistant. Local voice decoding would be better though. They could have a local decoding engine that keeps getting updated even from server data to better recognize what you're saying.
Yes!
The major reason for an iWatch, IMO, is to keep your iPhone in your pocket or purse -- otherwise why bother!
I agree with what wizard69 says about Swift: it's likely going to take the same path as Obj-C and be embraced by Apple only.
This appears to be the most likely avenue.
Apple would need to create a formal language specification (there is a book for developers, but it's not a formal specification) and an independent committee comprised of members from the larger tech community if they wanted Swift to be cross-platform. I don't see the incentive for them to do that.
Apple is hard to figure out here. I could see them offering up a standard in the same way they offered up one for OpenCL. Apple has been heavily involved in things like JavaScript and "C" standards too.
That being said, given what I've seen in the past, I have no doubt that MS and others are looking closely at some of the innovations in Swift
and will absorb them into their own technology stack at some point (much like they did with Java).
As much as I hate Windows, MS has some really smart people working for them. They most likely have been thiniking about the same ideas anyways.
OK, you guys are beating me down ...
But, thanks for the well-thought and presented info!
Mmm ... what if we had a programming language that used RPN -- like APL.
Talk about productivity -- I can write that program in one line of code!
'Course I can't read it ... Understand it ... Maintain it ...
Comments
1. It is open source with a good license.
2. It is proven to be a state of the art suite of tools.
3. Specifically the C++ compiler is a fantastic bleeding edge implementation of the standard. C++ is cross platform because it was derived from C which was developed to support systems level programming. In other words it supports putting operating systems onto processors. So C or C++ is often the first programming language on a platform. Beyond that many "programming languages" are implemented in C++. So before you port your BASIC, COBOL or other trendy language you often need to have C/C++ implemented to port that language. Being slow is on purpose. You don't want a language to change too fast, especially one as advance as C++. Even today it is hard to find a language that supports as many concepts and is as flexible as C++. That is baloney honestly. In the latest standard, C++ is practically a new language. Beyond that the code bases supported by C++ often end up existing for decades. This is perhaps why the standards committee is so important. It assures a stable platform with a rational evolution program.
Contrast this with Swift which is under Apples control and by their admission probably won't be stable for two years. It just isn't possible for somebody to buy into a Swift port when it isn't clear where Apple is taking it. So I don't see people even considering a Swift port anytime soon. Not really! At least at this point in time Swift isn't a suitable replacement for C++.
I don't think you grasp the difference here.
MS won't give up keys to the castle.
I agree with what wizard69 says about Swift: it's likely going to take the same path as Obj-C and be embraced by Apple only. Apple would need to create a formal language specification (there is a book for developers, but it's not a formal specification) and an independent committee comprised of members from the larger tech community if they wanted Swift to be cross-platform. I don't see the incentive for them to do that.
That being said, given what I've seen in the past, I have no doubt that MS and others are looking closely at some of the innovations in Swift
and will absorb them into their own technology stack at some point (much like they did with Java).
As much as I hate Windows, MS has some really smart people working for them. They most likely have been thiniking about the same ideas anyways.
I think the smartwatches that have been released so far have demonstrated that the market appeal is small if they are built a certain way. A wearable that is designed nicely with an always-on data connection would have more appeal.
iBeacons for example would be annoying if you walk near a store, get a notification and have to pull the phone out of your pocket but glancing at a watch is easier. Paying for things would be easier with a watch too as well as directions. If you get lost in a shopping center, you can just ask Siri 'where is McDonalds?' and it will tell you not only where you are but have walking directions to the store and then give you a voucher when you get there.
I think Siri would be more useful on a watch because it would become your primary means of using it and so it would become more like your personal assistant. Local voice decoding would be better though. They could have a local decoding engine that keeps getting updated even from server data to better recognize what you're saying.
Yes!
The major reason for an iWatch, IMO, is to keep your iPhone in your pocket or purse -- otherwise why bother!
OK, you guys are beating me down ...
But, thanks for the well-thought and presented info!
Mmm ... what if we had a programming language that used RPN -- like APL.
Talk about productivity -- I can write that program in one line of code!
'Course I can't read it ... Understand it ... Maintain it ...