- Joined: May 2005
- Posts: 19,539
- Select All Posts By This User
IBM has an army of 10,000's of developers/contractors around the globe, and a way to productize a custom developed app (they have another army of 10,000 tech writers and marketing folk). IBM sees enterprise problems, can develop the solution on the clients dime (client funded R&D), generalize it with a low infusion of product development $$, and push it out the door to every other enterprise client.
Given IBM's Analytics/Big Data bent, iOS integration into their analytics engines on big @ss IBM Virtual Data Center homed DB2 data farms is a big market. And in the Enterprise, keeping up with the Joneses, is par for the course.
As for Exxon Penetration... champagne? likely not. Assuming that half their employees use laptops, and half of those can switch, that's only 20K iPad sales. that's about 4 hours of sales. But if Exxon makes that move, then others will see less risk in it.
What you really want is something like the US Postal Service developing a custom app that makes an iPhone the primary mobile computing tool for a letter carrier (338,000 in the US alone).
Nurses/healthcare. 2.7Million nurses involved in healthcare. Assume that many more in allied-health (techs, transport, etc). IBM comes up with an iOS app for an iPad to talk to an IBM based medical records system... All those laptops on carts just fall out the window (literally, they take up more space in the charging bay).
The real benefit is that once IBM does it, the cost to deliver it to other business drops, it can scale down to small business (the real benefit of the cloud... I don't need a VM mainframe anymore, just an iPad, and a $100 month internet connect), and then it also drops for consumers (ditto).
No thank you, I have a hard enough time trying to get Siri to dial the correct Pizza service. Piazza Domination Hoes this is Elga, how may I punish you today, yeah, do you guys sell anchovies. I would like to see more IDE's offer better interfaces that incorporate a more visual approach to programming, elements you can simply drag and drop, easily selectable sources like database, RSS, other XML files, delimited files, selectable workable algorithms, etc. Out of the three main mobile OS's, iOS, Android and WM8.1 and the IDE's that are offered for them, I think I prefer programming with MS's tools, if you go here http://appstudio.windows.com, you can in 4 easy steps create a very usable app. Pretty cool little interface, I made an app in less then an hour that shows all of my subscriptions from AppleInsider, click on one, takes me to the last page, ready to post. It's a silly thing I know, but I have added notification support now that WM8.1 just got a Notification Center. Though I know how to write a Windows mobile app from scratch using Visual Studio, using a simple GUI that starts you with a working model is not only a perfect way to learn but makes it faster to produce simple tools, a lot of fun too. I also absolutely dig the virtual machine, it's so great that you can visualize your creation every step of the way.
Objective-C is extremely verbose. While typing may be only a small part of developing software, the more of it I have to do the more chance I have to make a typo. Also readability is essential for maintaining software. Objective-C can be UGLY. Reading extremely verbose code also leads to problems.
Swift aligns Apple with modern readability and syntax conventions of languages like Ruby, Groovy, Python and others. Yes, the vast majority of the real work is still done in libraries, but making those calls easier to parse (for the human) is very valuable.
While I'm primarily a Java developer, I've started using Groovy wherever I can because it cuts out a lot of verbose boilerplate that Java requires. I can get to the problem rather than writing lots of housekeeping code to keep Java happy.
I think Swift will make it easier for coders in other modern languages to jump in and out of Swift than Objective-C does.
Swift is indeed a big improvement wrt Objective-C. After a learning curve, it will reduce the development time for app developers. But the main drawback remains: like its predecessor it is an Apple only language.
As a developer of smartphone apps I have to listen to the market demands and make my apps available for both iOS and Android platforms. Porting an app from one platform to another typically requires 50% additional effort and cost. So currently I try to stick, whenever possible, to Cordova/Phonegap which makes it possible to develop cross platform smartphone apps.
And the wrecks split into millions of fragments.
Those Java programmers weren't very good.
Web applications are defiantly the present and future, I think I mentioned this before but when I was healthier and working I was employed by the largest bank in Switzerland. I was the managing director of internal programming, though we utilized compiled applications for specialized solutions such as our our trading platform the bulk of our applications were web driven. It's exactly the same situation in almost every company, in every field. Even the applications that ran specifically on a tablet, such as the iPad were for the most part web driven. Yes, I'm sure company's will utilize all those wonderful new apps that IBM will produce but mark my words any internal custom solutions will most likely be web driven and not compiled using Swift. No company in there right mind is going to send any of their programming staff to school to learn Swift just for the sole purposes of making iPad apps, not when they could easily make a web app in less time, less money, utilize the talent they currently have and especially use those apps across their entire IT infrastructure. There will of course be those exceptions, specialized apps are always needed but for the most part they will be purchased from third party vendors.
Swift is a clearly a very clever thing but it will not be shaking up the Enterprise world anytime soon as most here believe. I've seen many different programming solutions and languages come and go, those that stuck and were utilize the most were the ones that could be used multiple hardware and OS environments, i.e. Java, Python and web applications. it's just the way it is, things like running naively, faster, intuitiveness of the UI, whatever, just isn't a match for portability, speed of releases, budget constraints, especially when the output is identical.
Those who will benefit from Swift the most are company's or individuals specifically selling iPad apps.
Then honestly your Java programming team is sub-par if they can't get their applications working the way they're supposed too. I've heard this many times in forums but when it comes right down to it, writing and supporting multiple versions of one app to run on different platforms is no match for writing it once, supporting just that one build and then using it on the multiple platforms. It's fine to think that Apple's solution is superior and more company's should be using it but what are the real benefits, speed, not really important, reliability, sure but your delusional if you think a company wouldn't expect a programmer to make sure their Java version isn't also reliable, look and feel, not important, it's all about the output in the end. For the most part Enterprise apps are data entry, data retrieval, reports and calculations, things that can be accomplished with a web app and there isn't much that can't be done with HTML5, PHP/Python/Ruby and a Oracle/MySQL/PostgreSQL database.
Thanks for the info, I love reading your posts,always filled with lovely new stuff to research, I'm still going though it all but so far very impressive. I need to ask though, will Apple provide a Swift runtime for Windows and Linux because without it, well, it's kind of like figuring out cold fusion and only keeping it for yourself.
Actually your network traffic would be almost exactly the same if you were using an native application to access a database or web interface. I think your assuming that just because an app is nativity installed on a device it doesn't have the need to access it's networked data as often. Unless programmed specifically to cache it's data, which is rare as data changes constantly there will still be the same amount of queried and retrieved data going threw the network. Yes a web app has to download the UI and other data associated with it but when was the last time you've seen a really detailed, beautified corporate web app, in most cases were talking less then 300kb for an average page. Personally speaking as a manager, if it was any bigger then that I would have the person who wrote it go back and remove that stupid Giff of the bouncing question mark.
Edit: I also realize that web browsers aren't as efficient with memory management as a native app could be and this has presented problems when displaying large amounts of data but small workarounds like doing the actual calculations in SQL and then exporting the data into a PDF is a manageable solution to this problem. There are upsides and downsides to everything but to be honest an iPad with only 1GB of RAM would also fall into a same problem. This needs to be addressed by Apple, immediately.
Cool, then I guess I have some studying to do. I have to apologize about last night. I'm not feeling to well and I kind of glanced over the part about your wife dying. Let me just say how sorry I am that has happened to you. One of my greatest fears is not dying myself but leaving my husband and two children alone in the world. I know it's a selfish thing to believe that they won't be fine without me but I truly believe when you start a family you give a part of yourself to them and when one leaves you never get that part back. So although no words can really help to ease the loss you bear, just know that you are very close in every thought and prayer.
“If ever there is tomorrow when we're not together...there is something you must always remember. You are braver than you believe, stronger than you seem, and smarter than you think, but the most important thing is, even if we're apart...I'll always be with you.” -(Winnie the Pooh)