I do the hiring here. Thats hilarious. A conversation with Comic Book guy. Ok, I’ll google all your comments in future to see if they reference a 1960’s Russian TV program abandoned after 2 months.
Do you really think that both the OP and I did not know the ability existed in ObjC (among other languages) or that I would really tell you to turn in your geek badge because you did know?
The reference is also not all that obscure. Not as obvious as a Monty Python or Star Trek reference perhaps but not obscure either.
Very interesting discussion. Very insightful and thoughtful logic and reasoning behind ascii's point of view. There's something to be said about maintaining your portability and agility by staying lean and mean. But it's not like Microsoft didn't try to make a play for portability and small form factors with Windows CE. I'm not sure if Microsoft's inability to quickly produce an iPhone competitor was more determined by their technology decisions or their business strategy. I think it's primarily the latter, the business strategy stumbled for them, but once they were exposed by their actions on the business side they didn't have the right technology to react quickly enough to the disruptive threat of the iPhone and its App Store ecosystem. I believe it was the App Store model that disrupted Microsoft and the PC market as much the iPhone did although you could argue that the two are intertwined. Tens of thousands of cheap snack sized apps versus big fat integrated do-everything apps that shipped on at least one DVD (and sometimes more) and cost hundreds of dollars. Apple's decision to open up the iPhone as an open app platform (even if curated) was a broadside shot that the PC juggernaut was not prepared to handle. The iPhone with an Apple-only app store would still be a compelling smartphone product and possibly a market leader but it would not have set the stage to disrupt the entire PC industry like it has in its different form factors including iPad and AppleTV.
Microsoft's addiction to selling Big $ OS and Big $ Office licenses at a time when PC vendors were still on a healthy growth phase provided as much of an impediment to Microsoft meeting the Apple disruptive force as did their own technology factors. I don't think Microsoft's efforts around providing more accessible programming frameworks and languages like .NET and C# (and VB.NET) was the reason for them falling behind. Those technology and toolset innovations were the right things to do for sustaining their existing businesses at the time, which they had to do. In retrospect they could have positioned themselves to be better prepared to handle the disruption that the iPhone and App Store represented by having a leaner and more portable stack in hand. But retrospection is always easier than prediction and the nature of disruptive innovation is that many things you do to sustain your current business and current customers sets you up to fail when disruption hits. That's why you have to have a multi-pronged strategy and not have a singularly focused investment strategy either in technology or business. Apple's efforts to improve their current toolset is necessary and provides incremental improvements for some existing customers. If this is Apple's only play then yes they are making themselves more susceptible to disruption for iWatch, iRing, and iFollicle potential form factors. One would hope that Apple is preparing themselves for multiple potential scenarios that could occur over the next several years and not bet the farm on one approach or milking one cow to death.
Thanks for taking the time to read and understand the point I was trying to make. I think your version of Microsoft's history is probably more accurate than mine but I stand by my model of what the near future holds and the best way for Apple to prepare for it.
It's 2014. I'm freaking tired of .h files and c language syntax cruft. A more modern language is a welcome replacement for ObjC/C/C++. ObjC is effectively useless outside the Apple ecosystem anyway.
Agreed. Anything that help release coding from the deathgrip of the graybeards (which is also a great album title) is fine by me. The reaction of the old timers to this is hilarious. "Whut? People don't likes teh pointers? Ah, they're not real coders! Feh!" Good riddance to old farts.
Where I work it costs more to write software than it does to design, build and test hardware, and the hardware side includes the EEs writing VHDL for FPGAs. Something is seriously wrong there.
Agreed. Anything that help release coding from the deathgrip of the graybeards (which is also a great album title) is fine by me. The reaction of the old timers to this is hilarious. "Whut? People don't likes teh pointers? Ah, they're not real coders! Feh!" Good riddance to old farts.
These guys?
As people get older, it tends to be harder to learn new things so the resistance to new things is understandable but if there's a better way forward, it's time to make the shift. The following point mentioned earlier might harm adoption:
"You cannot import C++ code directly into Swift. Instead, create an Objective-C or C wrapper for C++ code."
For heavy C++ codebases, people might think if they have to make wrappers for the C++ anyway, they'd be as well sticking with Objective-C. I wonder how well the real-time feedback works when mixing code types.
You keep forgetting that everyone on Wall Street is waiting for an iWatch that will sell in the tens of millions of units at $300 a pop. Did you see any iWatch? No. Did you see any new AppleTV? No. So it makes sense that investors quickly sold off their shares because they can't make any money from Apple this week. Wall Street wanted to see hardware, not software at the developers conference. Software simply doesn't make investors salivate when it comes to Apple.
Apple stock is up $7 today. Pretty miraculous if everyone "sold off their shares". DO you want to recant your statement? You see yourself to be on the pulse of investors and having the pulse to predict everything they do- maybe you should finally admit you don't have a clue what you talk about, and most of your rants are full of shit?
Agreed. Anything that help release coding from the deathgrip of the graybeards (which is also a great album title) is fine by me. The reaction of the old timers to this is hilarious. "Whut? People don't likes teh pointers? Ah, they're not real coders! Feh!" Good riddance to old farts.
As an old fart, I can tell you that your interpretation to that reaction is probably mostly wrong. Those of us who have been programming for a long time and have been in fact exposed to multiple programming languages and environments have that reaction because there is nothing new or revolutionary about Swift as a programming language. I haven't taken an in-depth look at Swift yet - but, from the parts of the presentation I have seen, the code samples, and discussion - it appears to be yet another hybrid functional/imperative programming language that will remain proprietary to Apple. And there is nothing really new and revolutionary about the tooling either - VS has had an interactive console for F# (I use F# as an example because Swift appears to be very similar syntactically) for quite some time. I'm sure that many of those "old farts" are looking forward to having a modern language and toolset to add to their tool belt - but, since they have seen it all before they aren't going to jump up and down like this is the best thing since sliced bread. Only the young and inexperienced would do that - since they don't know any better.
Sorry guys but releasing a new programming language is something companies do when they don't have any really *good* ideas about where to go next.
Yeah, Objective-C, Apple sure had NO CLUE what they were doing when they pulled that one out. We should all still be coding in BASIC, because anything newer is “not a good idea.”
Yeah, Objective-C, Apple sure had NO CLUE what they were doing when they pulled that one out. We should all still be coding in BASIC, because anything newer is “not a good idea.”
Come off it.
Actually Objective-C didn't originate with them. Next licensed it from the creators. Apple picked it up from Next and improved upon it.
Quote:
Originally Posted by Marvin
These guys?
As people get older, it tends to be harder to learn new things so the resistance to new things is understandable but if there's a better way forward, it's time to make the shift. The following point mentioned earlier might harm adoption:
"You cannot import C++ code directly into Swift. Instead, create an Objective-C or C wrapper for C++ code."
For heavy C++ codebases, people might think if they have to make wrappers for the C++ anyway, they'd be as well sticking with Objective-C. I wonder how well the real-time feedback works when mixing code types.
I'm not sure how you would use a C wrapper there. That seems really strange. On a side note, that will probably be me one day (especially the beard).
Quote:
Originally Posted by SolipsismX
It's shaping up to be the best language in the 'verse.
I'm not sure about the language, but I like how the book assigns the value 42 to many of their example variables.
Check out Unity. It has exactly this (and better) since 2006 and deploys to iOS amongst others.
And I have been coding on the Amiga using AMOS in the 80s which had exactly the same principe of realtime feedback, ofcourse within context of the capabilities of the hardware.
Large studios have creating their own tools supporting their needs to have realtime feedback for years.
What you are describing, including the video you shared, is not innovative of 'visionary' at all. But then again you are living in the Apple reality distortion field and/or you make a sport out of disagreeing with fellow members.
I was turned onto a video by GatorGuy a few years (years?) ago. Can’t find the link. Maybe he can. I have the video downloaded, but uploading it again would be unnecessary.
EDIT: FOUND IT.
<iframe src="//player.vimeo.com/video/36579366?title=0&byline=0&portrait=0" width="580" height="326" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>
This guy’s giving a talk about software development and the power that could be afforded to developers if the coding software gave them realtime feedback. It blew me away, because that’s exactly what is needed! Being able to see where elements on the screen are going, changing them on the fly, building the world based on the realtime feedback, scrubbing through the execution, etc.
And Swift+Xcode ismuch exactly that.
I am absolutely thrilled by this. Can’t wait to see it in action.
This is what Apple has over Windows and Android. The mentally inadequate scream that features are being “copied” (ignoring that they’re not), while refusing to acknowledge that they don’t even have anything remotely like what Apple has on the back end.
From the icon, I expected the language to be called Peregrine. <span style="line-height:1.4em;">Swift works, too.</span>
Actually Objective-C didn't originate with them. Next licensed it from the creators. Apple picked it up from Next and improved upon it.
I'm not sure how you would use a C wrapper there. That seems really strange. On a side note, that will probably be me one day (especially the beard).
I'm not sure about the language, but I like how the book assigns the value 42 to many of their example variables.
NeXT bought ObjC from Stepstone Inc and improved it tremendously. Then we created the Openstep Initiative. Then Apple bought NeXT and the next major revision was ObjC 2.0.
Runtime introspection is also a feature of Objective C. What they mean I think, is that it will decide at runtime that your variable is an int, or a double depending on what you are assigning it to. That code has still been compiled. However you can absolutely still generate compile time warnings, that’s all over the document. Therefore the final code is compiled not run on an interpreter or JIT. The playground is probably interpreted though.
Utter garbage, as anyone who develops on it would agree.
What you are describing, including the video you shared, is not innovative of 'visionary' at all. But then again you are living in the Apple reality distortion field and/or you make a sport out of disagreeing with fellow members.
If I remember correctly, Metal only works on the A7 processor.
It only `works' on the A7 as the A7 is the most recent and first 64 bit processor design for the iOS platform systems. When the A8 arrives, Metal will be leveraging it as well.
Metal will not be in OS X. You have 3 major GPGPU vendors, none of which will come together and incorporate with Apple a standard API for Metal. We have OpenGL for that.
Apple moving the entire system for OS X to OpenGL 4.4 and/or 4.5/5.0 makes for a lot of legacy cruft removed and thus a large increase in performance that Metal resolves for game devs. It's analogous to Mantle.
Mantle controls the Game Console world with AMD having the sole relationship for the next 5 years. Apple controls its embedded ecosystem end-to-end, so Metal optimizations will be leveraged, until those short-comings in OpenGL are resolved by having OpenGL ES and OpenGL being current across iOS and OS X.
Yosemite is UI polish. I'm a fan..they didn't go too crazy. I'm thinking OS X 10.11 may bring some huge changes to the underpinnings (new filesystem anyone?)
Thanks for this post. I'm sure that there are people happy with the GUI modifications. And there is no doubt that developers took note of all the new API's. But as a sysadmin, I really would have like to have heard if they did anything to the actual operating system itself.
And good call on the new file system. I would like to see Apple pick up where they left off with 10.5 and complete the ZFS integration. I do realize that ZFS is available to OS X via both commercial 3rd party resources and open source, but I would rather see it come from Apple.
There is no real reason why swift can't be as efficient...it depends on the compiler. Also Java can be compiled to native binary if desired. The syntax isn't all that relevant. Google could do that tomorrow if they wanted. C++/CX is MS' version for WinRT.
Well, you're delaying a bunch of stuff that is normally done at compile time until runtime, that can't take no time, especially on a resource constrained device. If you have a way to make it take no time, please backport this to the compile time stage so I can have an instantaneous compiler, which would be great.
If you agree that it will take some time, but there will be additional information available at runtime that will allow the compiler to make optimizations such that the finished product will run so much faster it will make up for the compile time, I encourage you to look at something else they announced at WWDC. What they have done is integrate testing with profiling with compiling. So basically you write your test classes, and Xcode uses those to profile your app, and this profile is fed to the compiler at compile time, so it knows where the runtime hotspots will be. So provided you do adequate testing, the runtime compiler should have no additional information available than your compile-time compiler had.
Apple has had success in the past when they have made clever "middle ground" technical decisions. e.g. the middle ground between manual memory management and a full-on garbage collector was ARC. And the middle ground between run-time compilation and compile-time compilation is compile-time compilation assisted by a runtime profile.
Quote:
Originally Posted by nht
Except that developer productivity also means faster time to market and, in this case, even more developer lock in.
Being the only product in the market is another way ensure developers choose your platform.
NeXT bought ObjC from Stepstone Inc and improved it tremendously. Then we created the Openstep Initiative. Then Apple bought NeXT and the next major revision was ObjC 2.0.
That is a much better description than my own.
Quote:
Originally Posted by Tallest Skil
Utter garbage, as anyone who develops on it would agree.
Get da clue yourself.
I didn't think you would hate Unity. Why is that? I'll admit to having very little experience with it.
Comments
Do you really think that both the OP and I did not know the ability existed in ObjC (among other languages) or that I would really tell you to turn in your geek badge because you did know?
The reference is also not all that obscure. Not as obvious as a Monty Python or Star Trek reference perhaps but not obscure either.
Very interesting discussion. Very insightful and thoughtful logic and reasoning behind ascii's point of view. There's something to be said about maintaining your portability and agility by staying lean and mean. But it's not like Microsoft didn't try to make a play for portability and small form factors with Windows CE. I'm not sure if Microsoft's inability to quickly produce an iPhone competitor was more determined by their technology decisions or their business strategy. I think it's primarily the latter, the business strategy stumbled for them, but once they were exposed by their actions on the business side they didn't have the right technology to react quickly enough to the disruptive threat of the iPhone and its App Store ecosystem. I believe it was the App Store model that disrupted Microsoft and the PC market as much the iPhone did although you could argue that the two are intertwined. Tens of thousands of cheap snack sized apps versus big fat integrated do-everything apps that shipped on at least one DVD (and sometimes more) and cost hundreds of dollars. Apple's decision to open up the iPhone as an open app platform (even if curated) was a broadside shot that the PC juggernaut was not prepared to handle. The iPhone with an Apple-only app store would still be a compelling smartphone product and possibly a market leader but it would not have set the stage to disrupt the entire PC industry like it has in its different form factors including iPad and AppleTV.
Microsoft's addiction to selling Big $ OS and Big $ Office licenses at a time when PC vendors were still on a healthy growth phase provided as much of an impediment to Microsoft meeting the Apple disruptive force as did their own technology factors. I don't think Microsoft's efforts around providing more accessible programming frameworks and languages like .NET and C# (and VB.NET) was the reason for them falling behind. Those technology and toolset innovations were the right things to do for sustaining their existing businesses at the time, which they had to do. In retrospect they could have positioned themselves to be better prepared to handle the disruption that the iPhone and App Store represented by having a leaner and more portable stack in hand. But retrospection is always easier than prediction and the nature of disruptive innovation is that many things you do to sustain your current business and current customers sets you up to fail when disruption hits. That's why you have to have a multi-pronged strategy and not have a singularly focused investment strategy either in technology or business. Apple's efforts to improve their current toolset is necessary and provides incremental improvements for some existing customers. If this is Apple's only play then yes they are making themselves more susceptible to disruption for iWatch, iRing, and iFollicle potential form factors. One would hope that Apple is preparing themselves for multiple potential scenarios that could occur over the next several years and not bet the farm on one approach or milking one cow to death.
Thanks for taking the time to read and understand the point I was trying to make. I think your version of Microsoft's history is probably more accurate than mine but I stand by my model of what the near future holds and the best way for Apple to prepare for it.
It's 2014. I'm freaking tired of .h files and c language syntax cruft. A more modern language is a welcome replacement for ObjC/C/C++. ObjC is effectively useless outside the Apple ecosystem anyway.
Agreed. Anything that help release coding from the deathgrip of the graybeards (which is also a great album title) is fine by me. The reaction of the old timers to this is hilarious. "Whut? People don't likes teh pointers? Ah, they're not real coders! Feh!" Good riddance to old farts.
Where I work it costs more to write software than it does to design, build and test hardware, and the hardware side includes the EEs writing VHDL for FPGAs. Something is seriously wrong there.
Unity and a few others were mentioned as engines already working on Metal support.
These guys?
As people get older, it tends to be harder to learn new things so the resistance to new things is understandable but if there's a better way forward, it's time to make the shift. The following point mentioned earlier might harm adoption:
"You cannot import C++ code directly into Swift. Instead, create an Objective-C or C wrapper for C++ code."
For heavy C++ codebases, people might think if they have to make wrappers for the C++ anyway, they'd be as well sticking with Objective-C. I wonder how well the real-time feedback works when mixing code types.
You keep forgetting that everyone on Wall Street is waiting for an iWatch that will sell in the tens of millions of units at $300 a pop. Did you see any iWatch? No. Did you see any new AppleTV? No. So it makes sense that investors quickly sold off their shares because they can't make any money from Apple this week. Wall Street wanted to see hardware, not software at the developers conference. Software simply doesn't make investors salivate when it comes to Apple.
Apple stock is up $7 today. Pretty miraculous if everyone "sold off their shares". DO you want to recant your statement? You see yourself to be on the pulse of investors and having the pulse to predict everything they do- maybe you should finally admit you don't have a clue what you talk about, and most of your rants are full of shit?
Agreed. Anything that help release coding from the deathgrip of the graybeards (which is also a great album title) is fine by me. The reaction of the old timers to this is hilarious. "Whut? People don't likes teh pointers? Ah, they're not real coders! Feh!" Good riddance to old farts.
As an old fart, I can tell you that your interpretation to that reaction is probably mostly wrong. Those of us who have been programming for a long time and have been in fact exposed to multiple programming languages and environments have that reaction because there is nothing new or revolutionary about Swift as a programming language. I haven't taken an in-depth look at Swift yet - but, from the parts of the presentation I have seen, the code samples, and discussion - it appears to be yet another hybrid functional/imperative programming language that will remain proprietary to Apple. And there is nothing really new and revolutionary about the tooling either - VS has had an interactive console for F# (I use F# as an example because Swift appears to be very similar syntactically) for quite some time. I'm sure that many of those "old farts" are looking forward to having a modern language and toolset to add to their tool belt - but, since they have seen it all before they aren't going to jump up and down like this is the best thing since sliced bread. Only the young and inexperienced would do that - since they don't know any better.
Sorry guys but releasing a new programming language is something companies do when they don't have any really *good* ideas about where to go next.
Yeah, Objective-C, Apple sure had NO CLUE what they were doing when they pulled that one out. We should all still be coding in BASIC, because anything newer is “not a good idea.”
Come off it.
It's shaping up to be the best language in the 'verse.
Yeah, Objective-C, Apple sure had NO CLUE what they were doing when they pulled that one out. We should all still be coding in BASIC, because anything newer is “not a good idea.”
Come off it.
Actually Objective-C didn't originate with them. Next licensed it from the creators. Apple picked it up from Next and improved upon it.
These guys?
As people get older, it tends to be harder to learn new things so the resistance to new things is understandable but if there's a better way forward, it's time to make the shift. The following point mentioned earlier might harm adoption:
"You cannot import C++ code directly into Swift. Instead, create an Objective-C or C wrapper for C++ code."
For heavy C++ codebases, people might think if they have to make wrappers for the C++ anyway, they'd be as well sticking with Objective-C. I wonder how well the real-time feedback works when mixing code types.
I'm not sure how you would use a C wrapper there. That seems really strange. On a side note, that will probably be me one day (especially the beard).
It's shaping up to be the best language in the 'verse.
I'm not sure about the language, but I like how the book assigns the value 42 to many of their example variables.
And I have been coding on the Amiga using AMOS in the 80s which had exactly the same principe of realtime feedback, ofcourse within context of the capabilities of the hardware.
Large studios have creating their own tools supporting their needs to have realtime feedback for years.
What you are describing, including the video you shared, is not innovative of 'visionary' at all. But then again you are living in the Apple reality distortion field and/or you make a sport out of disagreeing with fellow members.
Actually Objective-C didn't originate with them. Next licensed it from the creators. Apple picked it up from Next and improved upon it.
I'm not sure how you would use a C wrapper there. That seems really strange. On a side note, that will probably be me one day (especially the beard).
I'm not sure about the language, but I like how the book assigns the value 42 to many of their example variables.
NeXT bought ObjC from Stepstone Inc and improved it tremendously. Then we created the Openstep Initiative. Then Apple bought NeXT and the next major revision was ObjC 2.0.
Runtime introspection is also a feature of Objective C. What they mean I think, is that it will decide at runtime that your variable is an int, or a double depending on what you are assigning it to. That code has still been compiled. However you can absolutely still generate compile time warnings, that’s all over the document. Therefore the final code is compiled not run on an interpreter or JIT. The playground is probably interpreted though.
http://www.theregister.co.uk/2014/06/02/apple_aims_to_speed_up_secure_coding_with_swift_programming_language/
Swift incorporate the dynamic run-time capabilities of ObjC.
Utter garbage, as anyone who develops on it would agree.
Get da clue yourself.
If I remember correctly, Metal only works on the A7 processor.
It only `works' on the A7 as the A7 is the most recent and first 64 bit processor design for the iOS platform systems. When the A8 arrives, Metal will be leveraging it as well.
Metal will not be in OS X. You have 3 major GPGPU vendors, none of which will come together and incorporate with Apple a standard API for Metal. We have OpenGL for that.
Apple moving the entire system for OS X to OpenGL 4.4 and/or 4.5/5.0 makes for a lot of legacy cruft removed and thus a large increase in performance that Metal resolves for game devs. It's analogous to Mantle.
Mantle controls the Game Console world with AMD having the sole relationship for the next 5 years. Apple controls its embedded ecosystem end-to-end, so Metal optimizations will be leveraged, until those short-comings in OpenGL are resolved by having OpenGL ES and OpenGL being current across iOS and OS X.
Yosemite is UI polish. I'm a fan..they didn't go too crazy. I'm thinking OS X 10.11 may bring some huge changes to the underpinnings (new filesystem anyone?)
Thanks for this post. I'm sure that there are people happy with the GUI modifications. And there is no doubt that developers took note of all the new API's. But as a sysadmin, I really would have like to have heard if they did anything to the actual operating system itself.
And good call on the new file system. I would like to see Apple pick up where they left off with 10.5 and complete the ZFS integration. I do realize that ZFS is available to OS X via both commercial 3rd party resources and open source, but I would rather see it come from Apple.
There is no real reason why swift can't be as efficient...it depends on the compiler. Also Java can be compiled to native binary if desired. The syntax isn't all that relevant. Google could do that tomorrow if they wanted. C++/CX is MS' version for WinRT.
Well, you're delaying a bunch of stuff that is normally done at compile time until runtime, that can't take no time, especially on a resource constrained device. If you have a way to make it take no time, please backport this to the compile time stage so I can have an instantaneous compiler, which would be great.
If you agree that it will take some time, but there will be additional information available at runtime that will allow the compiler to make optimizations such that the finished product will run so much faster it will make up for the compile time, I encourage you to look at something else they announced at WWDC. What they have done is integrate testing with profiling with compiling. So basically you write your test classes, and Xcode uses those to profile your app, and this profile is fed to the compiler at compile time, so it knows where the runtime hotspots will be. So provided you do adequate testing, the runtime compiler should have no additional information available than your compile-time compiler had.
Apple has had success in the past when they have made clever "middle ground" technical decisions. e.g. the middle ground between manual memory management and a full-on garbage collector was ARC. And the middle ground between run-time compilation and compile-time compilation is compile-time compilation assisted by a runtime profile.
Except that developer productivity also means faster time to market and, in this case, even more developer lock in.
Being the only product in the market is another way ensure developers choose your platform.
NeXT bought ObjC from Stepstone Inc and improved it tremendously. Then we created the Openstep Initiative. Then Apple bought NeXT and the next major revision was ObjC 2.0.
That is a much better description than my own.
Utter garbage, as anyone who develops on it would agree.
Get da clue yourself.
I didn't think you would hate Unity. Why is that? I'll admit to having very little experience with it.
You mean the guys who are still coding on OS/2 with OpenDoc?
You are an example of your own post.
Unless you are talking about the open source port of OS/2, the operating system in question was replaced years ago by EComStation.
http://www.ecomstation.com/