or Connect
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Apple expected to unveil 'iWatch' alongside 'iPhone 6' at Sept. 9 event
New Posts  All Forums:Forum Nav:

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

post #121 of 144

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

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #122 of 144
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.   

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #123 of 144
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).


Edited by auxio - 8/28/14 at 7:29am
 
Reply
 
Reply
post #124 of 144
Quote:
Originally Posted by Mac-Daddy View Post

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'.
"Few things are harder to put up with than the annoyance of a good example" Mark Twain
"Just because something is deemed the law doesn't make it just" - SolipsismX
Reply
"Few things are harder to put up with than the annoyance of a good example" Mark Twain
"Just because something is deemed the law doesn't make it just" - SolipsismX
Reply
post #125 of 144
Quote:
Originally Posted by asdasd View Post


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.

Quote:
Originally Posted by auxio View Post

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)

Quote:
Originally Posted by asdasd View Post

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.   

Quote:
Originally Posted by auxio View Post

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:



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




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 1smile.gif
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #126 of 144
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.


Edited by auxio - 8/28/14 at 10:01am
 
Reply
 
Reply
post #127 of 144
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.

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #128 of 144
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
 
Reply
post #129 of 144
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.

Originally Posted by helia

I can break your arm if I apply enough force, but in normal handshaking this won't happen ever.
Reply

Originally Posted by helia

I can break your arm if I apply enough force, but in normal handshaking this won't happen ever.
Reply
post #130 of 144
Quote:
Originally Posted by mstone View Post

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.
post #131 of 144
Quote:
Originally Posted by auxio View Post

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.

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.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #132 of 144
Quote:
Originally Posted by auxio View Post

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

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.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #133 of 144
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.


Edited by auxio - 8/28/14 at 1:39pm
 
Reply
 
Reply
post #134 of 144
Quote:
Originally Posted by auxio View Post

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

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

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

Quote:
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.
Edited by Dick Applebaum - 8/28/14 at 2:29pm
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #135 of 144
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.


Edited by auxio - 8/28/14 at 2:57pm
 
Reply
 
Reply
post #136 of 144
Quote:
Originally Posted by auxio View Post

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

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.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #137 of 144
Quote:
Originally Posted by Dick Applebaum View Post

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

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
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.
Quote:
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++.
Quote:

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.
Quote:
It is ripe for disruption!
Not really! At least at this point in time Swift isn't a suitable replacement for C++.
Quote:

BTW, I remember when CoBOL was the cross-platform programming language -- I even taught classes in it -- on several platforms in several countries.

I don't think you grasp the difference here.
post #138 of 144
What is with all the what ifs?
Quote:
Originally Posted by Dick Applebaum View Post

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
Quote:
Don't you think MS will use Swift when they write apps for Macs and iDevices?
For user interface code maybe.
Quote:
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.
Quote:
What if IBM/Apple make significant inroads into the MS domination of enterprise IT?
Wishful thinking.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:

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.
Quote:
But, if I were MS, it would make sense to have a skunk-works project to implement Swift -- just in case!
Why?
Quote:

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

MS won't give up keys to the castle.
post #139 of 144

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

 
Reply
 
Reply
post #140 of 144
Quote:
Originally Posted by auxio View Post

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.
Quote:
 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.
Quote:
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.
post #141 of 144
Quote:
Originally Posted by DocNo42 View Post

Quote:
Originally Posted by mstone View Post

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.
post #142 of 144
Quote:
Originally Posted by Marvin View Post

Quote:
Originally Posted by DocNo42 View Post

Quote:
Originally Posted by mstone View Post

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!
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #143 of 144
Quote:
Originally Posted by wizard69 View Post

Quote:
Originally Posted by auxio View Post

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.
Quote:
 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.
Quote:
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 ...
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #144 of 144
Quote:
Originally Posted by Dick Applebaum View Post


Mmm ... what if we had a programming language that used RPN ...

Talk about productivity -- I can write that program in one line of code!
Ambi?
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Future Apple Hardware
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Apple expected to unveil 'iWatch' alongside 'iPhone 6' at Sept. 9 event