Apple expected to unveil 'iWatch' alongside 'iPhone 6' at Sept. 9 event

123457

Comments

  • Reply 121 of 149
    kent909 wrote: »
    Hopefully for the last time, there is not going to be an iWatch, next month or ever. Also, why is no one leaking or talking about the next iPhone being waterproof?

    Because maybe it isn't?
  • Reply 122 of 149
    asdasd wrote: »
    Thanks ... I do understand, and you presented the reasons well!

    Time marches on ...

    What if, a year or so, from now, Swift offers a superior solution [to all the advantages you mentioned] to C++ -- Could it be the lingua Franca you mention?

    It isn't cross platform so it can't. It's tightly coupled with iOS and mac now and with the cocoa frameworks. Even if some of it were ported its hard to see the advantage over C#.

    Help me understand ...
    1. The C++ cross platform advantage exists because C++ is not tied to any OS -- true?
    2. Because of this C++ programmers cannot (or should not) access underlying platform dependent API's -- true?
    3. C++ is self-contained. similar to Java -- true?
    4. Do C++ programs provide garbage collection/ARC or is that the responsibility of the programmer?
    5. Because it's been around a while, C++ has a less modern syntax, and more housekeeping, than other, newer, languages like Swift -- true?

    Your statement that Swift is "tightly coupled with iOS and mac now and with the cocoa frameworks" is true -- but I think that is just a means to an end.  Apple made Swift viable, day 1, because of this tight-coupling and automatic-bridging to Cocoa frameworks, But, as we speak, these frameworks are being reimplemented as Swift frameworks.

    My point here, is that it is possible that, in the near future, Swift will/could be a robust, self-contained package that does not depend on platform-specific frameworks. Much of this is possible because of modern clang/llvm implementations -- Soon, it might just be possible for Swift to deliver on the promise of Java: Write once, run anywhere!

    To satisfy the [cross-platform] needs of developers, the whole package:  IDE and Self-contained Swift:  could be made available on major platforms or online ... in the worst case, the developer would need to use a Mac for cross-platform Swift development ... But, a developement Mac, actually should be an advantage -- because you can run virtual copies of all the other major OSes on a single Mac.

    Again, I have zero experience with C++, but the stated (promised) advantages of Swift are:
    • fast running code
    • safe code -- if it compiles it will run.
    • clean code (little or no housekeeping and glue code)
    • readable, maintainable, self-documenting code

    Those sound like pretty big advantages to me!
  • Reply 123 of 149
    asdasd wrote: »
    As I mentioned earlier, initial XIB implementations required so much extra work that many abandoned the new way for the known way -- do it in code!

    "Swift generally gets you to the right way much quicker."

    That's a cogent remark -- I will quote you on that!

    I think that is partially because Swift makes it difficult to drag legacy [programming] baggage forward -- it almost goads you into looking for a better way. Once you realize that, it's almost like embarking on a fresh, new adventure -- like learning to program for the first time.

    Bindings are a maintenance nightmare.

    I just started using Bindings -- but, I suspect that what you say is true!

    I'll put a lot of that down to poor design of the Bindings programmer UI -- all these little knobs and switches spread all over the place.

    But after a few days, you can get your head around it -- and know where to look for things,

    IMO, Apple should provide an overall view fanout in outline/narrative form -- from a Bindings perspective -- so you can design/maintain Bindings from a high-level and let the IDE set all those little knobs and switches spread all over the place.

    This also assumes some pretty good default assumptions and a high-level way to tell the UI what you want, e.g.:

    You drag a NSTableview into the NIB/Storyboard, it generates a 2-column table by default and a popup asks you for the class that will be displayed in the table.

    If you don't specify a Class, the UI generates one, creates default bindings and populates the table with default data ... Name, birthdate for example.

    If you specify a class, the UI finds it then does all the above based on the class.

    In either case, you should be able to do a build and get a running, testable app.


    I think this is all doable, because the IDE knows where all those little knobs and switches are. For example, you can search your project for "caseinsensitive" and it will find and display any Storyboard elements containing that text ... A Binding for "localizedCaseInsensitiveCompare:" Sort Descriptors in my case.

    If the IDE can find them, the IDE should be able to generate them [reasonable defaults] and display them in a way conducive to understanding and maintenance.

    I hope that this is work-in-progress!

    Case in point: For my simple example, I want to change from a cell-based to a view-based table ... It should be a no-brainer -- but after an hour, or so, I can't figure it out :(
  • Reply 124 of 149

    iCouldn't care less about the iWatch. iBored again. Keep it.

  • Reply 125 of 149
    asdasdasdasd Posts: 5,686member

    Dick, bit off topic but there is good sample code on views for table views on the dev site. 

  • Reply 126 of 149
    asdasdasdasd Posts: 5,686member
    Quote:

    Originally Posted by Dick Applebaum View Post





    Help me understand ...

    1.  

    2. The C++ cross platform advantage exists because C++ is not tied to any OS -- true?

    3.  

    4. Because of this C++ programmers cannot (or should not) access underlying platform dependent API's -- true?

    5.  

    6. C++ is self-contained. similar to Java -- true?

    7.  

    8. Do C++ programs provide garbage collection/ARC or is that the responsibility of the programmer?

    9.  

    10. Because it's been around a while, C++ has a less modern syntax, and more housekeeping, than other, newer, languages like Swift -- true?

    11.  

    12.  


    Your statement that Swift is "tightly coupled with iOS and mac now and with the cocoa frameworks" is true -- but I think that is just a means to an end.  Apple made Swift viable, day 1, because of this tight-coupling and automatic-bridging to Cocoa frameworks, But, as we speak, these frameworks are being reimplemented as Swift frameworks.



    My point here, is that it is possible that, in the near future, Swift will/could be a robust, self-contained package that does not depend on platform-specific frameworks. Much of this is possible because of modern clang/llvm implementations -- Soon, it might just be possible for Swift to deliver on the promise of Java: Write once, run anywhere!



    To satisfy the [cross-platform] needs of developers, the whole package:  IDE and Self-contained Swift:  could be made available on major platforms or online ... in the worst case, the developer would need to use a Mac for cross-platform Swift development ... But, a developement Mac, actually should be an advantage -- because you can run virtual copies of all the other major OSes on a single Mac.



    Again, I have zero experience with C++, but the stated (promised) advantages of Swift are:

    • fast running code

    • safe code -- if it compiles it will run.

    • clean code (little or no housekeeping and glue code)

    • readable, maintainable, self-documenting code


    Those sound like pretty big advantages to me!

     

    Yes, but the language is not the framework. C++ is basically used in cross platform code to handle data manipulation and interactions with databases ( which are platform independent since SQL is mostly a standard).. I don't think too many people *even* use it for network api - those are possibly the same on UNIXEN but not guaranteed to work on Windows.

     

    To write a swift app which talks to the cocoa frameworks which is write once and run anywhere needs the compiler to generate code which will run anywhere, which involves adding the frameworks cross platform ( which NEXT actually did back in the day but its a lot of work), or to run in some kind of virtual machine, like JAVA. Neither is great.   

  • Reply 127 of 149
    auxioauxio Posts: 2,761member
    Quote:
    Originally Posted by Dick Applebaum View Post



    What if, a year or so, from now, Swift offers a superior solution [to all the advantages you mentioned] to C++ -- Could it be the lingua Franca you mention?

     

    For that to happen, Microsoft would have to adopt Swift and port all of the tools/APIs/Frameworks to Windows (as well as the Linux/Android folks).  Either that or Apple would have to find a reason to do the same.  Neither seem remotely likely given that it didn't really happen with Obj-C + Cocoa over the years (though check out the Cocotron project for an example of what that would look like).

     

    The reason C++ is cross-platform is because there is a committee of people dedicated to publishing standards for it which can be implemented across all platforms (and it has been ported to nearly every platform created in the last 25 years).  Swift only has Apple behind it, so it will mostly likely stay as an Apple-specific technology.

     

    The downside to this approach is, because it's so cross-platform, the native C++ libraries tend to be very low-level (i.e. you generally can only manipulate data -- not do things like show a window on the screen).  It also tends to move forward very slowly because of design-by-committee (it took over 10 years to get the C++11 language additions ratified).

  • Reply 128 of 149
    dasanman69dasanman69 Posts: 13,002member
    mac-daddy wrote: »
    So you're going to buy something you that you don't know 1) what it does 2) what it looks like 3) how much it costs? Wow.

    It's called 'faith'.
  • Reply 129 of 149
    asdasd wrote: »

    Yes, but the language is not the framework. C++ is basically used in cross platform code to handle data manipulation and interactions with databases ( which are platform independent since SQL is mostly a standard).. I don't think too many people *even* use it for network api - those are possibly the same on UNIXEN but not guaranteed to work on Windows.

    auxio wrote: »
    The reason C++ is cross-platform is because there is a committee of people dedicated to publishing standards for it which can be implemented across all platforms (and it has been ported to nearly every platform created in the last 25 years).  Swift only has Apple behind it, so it will mostly likely stay as an Apple-specific technology.

    The downside to this approach is, because it's so cross-platform, the native C++ libraries tend to be very low-level (i.e. you generally can only manipulate data -- not do things like show a window on the screen).  It also tends to move forward very slowly because of design-by-committee (it took over 10 years to get the C++11 language additions ratified).

    Is that what this is about -- the majority of C++ programs are glue to:
    1. connect to SQL DBs (or use an existing connection from a higher-level, platform-dependent language/API)
    2. read/write/manipulate the SQL data
    3. pass the SQL data to a higher-level, platform-dependent language/API for presentation
    4. disconnect from SQL DBs (or depend on a higher-level, platform-dependent language/API)

    asdasd wrote: »
    To write a swift app which talks to the cocoa frameworks which is write once and run anywhere needs the compiler to generate code which will run anywhere, which involves adding the frameworks cross platform ( which NEXT actually did back in the day but its a lot of work), or to run in some kind of virtual machine, like JAVA. Neither is great.   

    auxio wrote: »
    For that to happen, Microsoft would have to adopt Swift and port all of the tools/APIs/Frameworks to Windows (as well as the Linux/Android folks).  Either that or Apple would have to find a reason to do the same.  Neither seem remotely likely given that it didn't really happen with Obj-C + Cocoa over the years (though check out the Cocotron project for an example of what that would look like).

    In the form of telling you questions:

    So, if I understand correctly, C++ is used mainly for low-level [SQL] data interface and manipulation and is platform-independent because it does not use any platform-specific APIs?

    However, someone must provide (and maintain) cross-platform APIs for C++ to interfacethe various SQL DB flavors?

    AFAICT, most modern platforms are implementing, or have implemented clang/llvm constructs?


    Here's the real question: If the above are true, couldn't C++, Swift or any other language be implemented with clang/llvm and be cross-platform by ignoring platform-specific APIs?

    Here's a bit of Swift code that does not use any OS X or iOS APIs:

    1000

    Here's the same Swift code that fails because it attempts to use a Cocoa API

    1000


    So, to match the main C++ cross-platform usage, Apple could :
    • write and maintain interfaces to the various DB flavors
    • rely on a 3rd-party (.org) to write and maintain interfaces to the various DB flavors
    • make the Swift Compiler/runtime available as an Online Service
    • make the Swift Compiler/runtime (sans OS X iOS APIs) available ala WebKit

    The, the Windows Swift programmer, iOS/OSX Swift Programmer and 'Nix Swift programmer could write both platform-indecent and platform-specific Swift code.

    Edit: Noticed the Mistype-Ahead typo ... decided to leave in -- made the case better than I :)
  • Reply 130 of 149
    auxioauxio Posts: 2,761member
    Quote:

    Originally Posted by Dick Applebaum View Post

     

    Is that what this is about -- the majority of C++ programs are glue to:


    1. connect to SQL DBs (or use an existing connection from a higher-level, platform-dependent language/API)

    2. read/write/manipulate the SQL data

    3. pass the SQL data to a higher-level, platform-dependent language/API for presentation

    4. disconnect from SQL DBs (or depend on a higher-level, platform-dependent language/API)


     

    Unfortunately, asdasd confused you a bit.  When I talk about the broad topic of "data-manipulation", I'm talking about how to structure, process, and save/load data in your applications.  Not just interacting with SQL databases (for which there are no APIs in the standard C++ library anyways).

     

    For example: say you have a cross-platform application which can save to a file and reload it again (to use your own app as an example: say you wanted to allow the user to add/remove entries from the table and then save/load them again).  If you used purely Swift code to do that on OS X, you'd then need to write similar C++ or C# code for the Windows version of your app.  Then, if you later decide to add features to your application which require more/different data to be saved, you'd need to update both the Swift code and the C++/C# code to support that.

     

    By using shared C++ code to save and load your file, you have one unified place where you can update features/fix bugs for all platforms.  This ensures consistent file saving/loading behaviour across all platforms and makes changing/updating your file format much easier in the long run.

     

    If you're interested in the topic of separating the handling of data from the presentation of that data in the UI, have a read through this Wiki page.

  • Reply 131 of 149
    asdasdasdasd Posts: 5,686member
    Quote:
    Originally Posted by auxio View Post

     

     

    Unfortunately, asdasd confused you a bit.  When I talk about the broad topic of "data-manipulation", I'm talking about how to structure, process, and save/load data in your applications.  Not just interacting with SQL databases (for which there are no APIs in the standard C++ library anyways).

     

    For example: say you have a cross-platform application which can save to a file and reload it again (to use your own app as an example: say you wanted to allow the user to add/remove entries from the table and then save/load them again).  If you used purely Swift code to do that on OS X, you'd then need to write similar C++ or C# code for the Windows version of your app.  Then, if you later decide to add features to your application which require more/different data to be saved, you'd need to update both the Swift code and the C++/C# code to support that.

     

    By using shared C++ code to save and load your file, you have one unified place where you can update features/fix bugs for all platforms.  This ensures consistent file saving/loading behaviour across all platforms and makes changing/updating your file format much easier in the long run.

     

    If you're interested in the topic of separating the handling of data from the presentation of that data in the UI, have a read through this Wiki page.


     

    Well yes, I said that SQL is *mostly* a standard, not quite. Yes, there are no standard C++ APIs, but plenty of example code to talk to SQL database, a fairly common way of structuring data. The rest of your post is correct of course.

  • Reply 132 of 149
    auxioauxio Posts: 2,761member
    Quote:

    Originally Posted by Dick Applebaum View Post



    Here's the real question: If the above are true, couldn't C++, Swift or any other language be implemented with clang/llvm and be cross-platform by ignoring platform-specific APIs?



    Here's a bit of Swift code that does not use any OS X or iOS APIs:



    ...

     

    Even your example is using APIs which are platform-specific.  You're calling the function println(), but how does println() work on OS X vs Windows?  It, in-turn, needs to be turned into lower-level commands which can display characters somewhere on the screen.

     

    The compiler (clang) can do this for you, but it needs to know where to find the implementation of println() on both OS X and Windows (i.e. in a standard/core library which is created for each platform).  This is the part that's missing for Swift and Obj-C on Windows: the libraries/frameworks which give you the APIs you can use in your program.  Without that, all you can do is declare classes, functions, and variables (but can't do anything with them).

  • Reply 133 of 149
    Originally Posted by tkrunner1738 View Post

    This shouldn't be news and warrant a push notification , that should be saved for factual news .

     

    It’s a rumor website.

  • Reply 134 of 149
    docno42docno42 Posts: 3,761member
    mstone wrote: »
    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.

    It's hard to see how something is going to be used before it's even out there and thus easy to dismiss it. And every time stuff like this gets dismissed and then goes on to be a blockbuster success, the same naysayers will do it again with the next thing.

    Sure, some stuff is obviously bad, but if you look at essays like this http://asktog.com/atc/apple-iwatch/ there is more than enough functionality that would have broad appeal to a wide variety of people and hardly qualify for niche status.
  • Reply 135 of 149
    auxio wrote: »
     
    <span style="line-height:1.4em;">Is that what this is about -- the majority of C++ programs are glue to:</span>
    1. connect to SQL DBs (or use an existing connection from a higher-level, platform-dependent language/API)
    2. read/write/manipulate the SQL data
    3. pass the SQL data to a higher-level, platform-dependent language/API for presentation
    4. disconnect from SQL DBs (or depend on a higher-level, platform-dependent language/API)

    Unfortunately, asdasd confused you a bit.  When I talk about the broad topic of "data-manipulation", I'm talking about how to structure, process, and save/load data in your applications.  Not just interacting with SQL databases (for which there are no APIs in the standard C++ library anyways).

    For example: say you have a cross-platform application which can save to a file and reload it again (to use your own app as an example: say you wanted to allow the user to add/remove entries from the table and then save/load them again).  If you used purely Swift code to do that on OS X, you'd then need to write similar C++ or C# code for the Windows version of your app.  Then, if you later decide to add features to your application which require more/different data to be saved, you'd need to update both the Swift code and the C++/C# code to support that.

    By using shared C++ code to save and load your file, you have one unified place where you can update features/fix bugs for all platforms.  This ensures consistent file saving/loading behaviour across all platforms and makes changing/updating your file format much easier in the long run.

    If you're interested in the topic of separating the handling of data from the presentation of that data in the UI, have a read through this Wiki page.

    But, doesn't C++ need to know the underlying file system so it can read/write to Windows, OS X, Linux?

    So, how is a C++ app written to access the Windows file system executable on OS X and 'Nix?

    BTW,I do underst the MVC design pattern.
  • Reply 136 of 149
    auxio wrote: »
    <span style="line-height:1.4em;">Here's the real question: If the above are true, couldn't C++, Swift or any other language be implemented with clang/llvm and be cross-platform by ignoring platform-specific APIs?</span>



    Here's a bit of Swift code that does not use any OS X or iOS APIs:


    ...

    Even your example is using APIs which are platform-specific.  You're calling the function println(), but how does println() work on OS X vs Windows?  It, in-turn, needs to be turned into lower-level commands which can display characters somewhere on the screen.

    The compiler (clang) can do this for you, but it needs to know where to find the implementation of println() on both OS X and Windows (i.e. in a standard/core library which is created for each platform).  This is the part that's missing for Swift and Obj-C on Windows: the libraries/frameworks which give you the APIs you can use in your program.  Without that, all you can do is declare classes, functions, and variables (but can't do anything with them).

    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.

    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 ...

    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)?


    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:
    1. C++ is the cross-platform solution because: C++ already is the cross-platform solution
    2. Swift can never be the cross-platform solution because: C++ already is the cross-platform solution

    Somewhere, in this thread it was posted that C++ is a committee effort and evolves very slowly (dragging baggage forward)


    This disturbs me because it enforces the status quo in the rapidly evolving field of technology [programming]

    It is ripe for disruption!


    BTW, I remember when CoBOL was the cross-platform programming language -- I even taught classes in it -- on several platforms in several countries.
  • Reply 137 of 149
    auxioauxio Posts: 2,761member
    Quote:
    Originally Posted by Dick Applebaum View Post



    But, doesn't C++ need to know the underlying file system so it can read/write to Windows, OS X, Linux?


    So, how is a C++ app written to access the Windows file system executable on OS X and 'Nix?

     

    It does.  The C++ standard library has different implementations of it's standard library for all platforms.  Generally, it's implemented using the POSIX APIs on most platforms.

     

     But, I have an uneasy felling that the answers I'm getting are:

    1. C++ is the cross-platform solution because: C++ already is the cross-platform solution

    2. Swift can never be the cross-platform solution because: C++ already is the cross-platform solution



     

    C++ is the cross-platform solution because the standard library (and most of the major 3rd party libraries) doesn't make any attempt to try and draw UI elements (windows, buttons, text entry fields, etc) or handle UI interactions across platforms.  It only does the low-level stuff which is generally common to all platforms.  Once you get into doing any UI work, it's very very very very hard to do it in a sane way across platforms.  Especially given that it's advancing and changing all the time (e.g. all of the animation effects on iOS).

     

    The problem is that the vast majority of Swift's functionality is related to UI work, so it would not be easy to port.  The core parts of Swift (the language, the data containers, file I/O, etc) wouldn't be too hard to port.  But then you wouldn't get a lot of the benefits of it without having things like the playground and whatnot ported to other platforms.

  • Reply 138 of 149
    auxio wrote: »
    So, how is a C++ app written to access the Windows file system executable on OS X and 'Nix?

    It does.  The C++ standard library has different implementations of it's standard library for all platforms.  Generally, it's implemented using the POSIX APIs on most platforms.
     But, I have an uneasy felling that the answers I'm getting are:
    1. C++ is the cross-platform solution because: C++ already is the cross-platform solution
    2. Swift can never be the cross-platform solution because: C++ already is the cross-platform solution

    C++ is the cross-platform solution because the standard library (and most of the major 3rd party libraries) doesn't make any attempt to try and draw UI elements (windows, buttons, text entry fields, etc) or handle UI interactions across platforms.  It only does the low-level stuff which is generally common to all platforms.

    Very helpful -- Thx.

    Once you get into doing any UI work, it's very very very very hard to do it in a sane way across platforms. Especially given that it's advancing and changing all the time (e.g. all of the animation effects on iOS).

    The problem is that the vast majority of Swift's functionality is related to UI work, so it would not be easy to port.  

    Yes, I can see that.

    The core parts of Swift (the language, the data containers, file I/O, etc) wouldn't be too hard to port.  

    Yes! That's what I'm asking about ... essentially an equivalent to C++ (as you've described it) -- but with all the advantages (at that level) of a modern language ... fast, safe, readable, maintainable, etc.

    But then you wouldn't get a lot of the benefits of it without having things like the playground and whatnot ported to other platforms.

    But, I think you would.

    First, AFAICT, Playgrounds (REPL) are a function of llvm and can be used in tests, custom debugging constructs, from the command line, etc.

    Second, there you sit with the platform-independent Swift equivalent of the C++ portion of your app -- in a separate file, class or part of a Playground.

    Third, if you have a platform-dependent extension to the Swift compiler (like include Cocos or Include UIKit, etc.) you can issue those directives and then you can integrate developing the platform-dependent portion of your app with the platform-independent portion.

    Here, I expect that the owner of the platform, e.g. Windows, would map the Swift Constructs (like the UI) to the underlying platform APIs -- like Apple does with Objective-C.

    Then, as Apple is doing, over time re-implement the underlying APIs to Swift APIs -- streamlining and discarding baggage.


    Voila! You have a single, svelte, modern language with an IDE that allows interactive development and testing of platform-independent code as well as platform-dependent code -- the complete app!

    With virtualization, you can do this for all platforms on a single computer -- with a similar (or even common) code base.
  • Reply 139 of 149
    auxioauxio Posts: 2,761member
    Quote:
    Originally Posted by Dick Applebaum View Post



    Here, I expect that the owner of the platform, e.g. Windows, would map the Swift Constructs (like the UI) to the underlying platform APIs -- like Apple does with Objective-C.



    Then, as Apple is doing, over time re-implement the underlying APIs to Swift APIs -- streamlining and discarding baggage.

     

    A couple of other related points on the matter:

     

    - There are a number of fundamental differences between Windows and Mac UIs which would affect the ability to port a number of APIs.  For example, the menubar being at the top of the screen vs in the application window.  This makes a big difference in terms of having multiple windows in the same application instance vs running multiple application instances.  I could write an essay on all such differences, but I'll spare you.

    - Money and business sense: why would Microsoft spend money porting Swift to Windows when they already have C#?  Especially when it doesn't make any business sense for them to allow you to write apps for a competing operating system.  This is where Java fell down when Microsoft co-opted it on Windows and added their own extensions to the language: there was no business case for them to provide decent support for Java.  So when Sun sued them over the matter, they effectively cloned it and made C#.

     

    If it were to happen, it would have to be done by a 3rd party which has close ties with both Microsoft and Apple (so that they could move quickly adding support for new OS features to the common Swift platform), but with no particular allegiance to either one.  Such a thing would be unprecedented in the history of commercial computing technology.

  • Reply 140 of 149
    auxio wrote: »
    <span style="line-height:1.4em;">Here, I expect that the owner of the platform, e.g. Windows, would map the Swift Constructs (like the UI) to the underlying platform APIs -- like Apple does with Objective-C.</span>



    Then, as Apple is doing, over time re-implement the underlying APIs to Swift APIs -- streamlining and discarding baggage.

    A couple of other related points on the matter:

    - There are a number of fundamental differences between Windows and Mac UIs which would affect the ability to port a number of APIs.  For example, the menubar being at the top of the screen vs in the application window.  This makes a big difference in terms of having multiple windows in the same application instance vs running multiple application instances.  I could write an essay on all such differences, but I'll spare you.
    - Money and business sense: why would Microsoft spend money porting Swift to Windows when they already have C#?  Especially when it doesn't make any business sense for them to allow you to write apps for a competing operating system.  This is where Java fell down when Microsoft co-opted it on Windows and added their own extensions to the language (there was no business case for them to provide decent support for Java).

    If it were to happen, it would have to be done by a 3rd party which has close ties with both Microsoft and Apple (so that they could move quickly adding support for new OS features to the common Swift platform), but with no particular allegiance to either one.  Such a thing would be unprecedented in the history of commercial computing technology.

    From a programmer's perspective, how does C# compare to Obj-C? To Swift?

    Don't you think MS will use Swift when they write apps for Macs and iDevices?

    What if Swift proves to be a superior programming language/IDE to C#?

    What if IBM/Apple make significant inroads into the MS domination of enterprise IT?

    What if all the above prove that Swift offers significant productivity and maintainability advantages over C#?

    What if MS realizes that it needs Swift to protect it's declining install base?

    What if MS realizes that it need Swift to be competitive in the mobile (computer, tablet, phone, etc.) area?

    What if Apple outs Swift ala WebKit?


    If any of this plays out, I suspect it would take 12 - 18 months ...

    But, if I were MS, it would make sense to have a skunk-works project to implement Swift -- just in case!


    I don't think MS will be able to play the embrace and extend/subsume card with Swift -- been there too any times, already.
Sign In or Register to comment.