Apple shifts from Objective C to Swift

in apple on 2014-06-03 08:52 (#3NC)

Apple announced a new programming language yesterday at its yearly developer conference. With improvements in speed and ease of development, the new language aims to replace Objective C, Apple's previous language of choice.

As usual, software development in the new language is limited to the company's XCode programming IDE available for no cost in OS X.

Thank god. (Score: 0)

by spacebar@pipedot.org on 2014-06-03 16:01 (#20H)

I for one found Objective C to be an enormous headache--not that it matters anymore since I'm no longer using anything Apple, but, well, good for someone?

R.I.P. Macintosh.

Re: Thank god. (Score: 0)

by billshooterofbul@pipedot.org on 2014-06-03 16:22 (#20J)

Objective C was cool with its late binding and everything, but it was not fast. I had an app that took advantage of the cooler parts of Objective C, only to have apple silently disable that feature without warning.

Tragic NIH Syndrome (Score: 1, Insightful)

by Anonymous Coward on 2014-06-03 17:20 (#20K)

Why is every successful company so enamored of the smell of its farts that it has to invent its own programming language? Google did it, Apple's doing it; back in olden times there were flavors and branding but Fortran was more or less Fortran, COBOL (blargh) was COBOL, PL/1, etc., etc.

If code is code, and interoperability speeds progress for everyone, what's with pervasive Not Invented Here syndrome?

It ends up leaving us all relying on lowest common denominator CRAPOLA like JavaScript.

Re: Tragic NIH Syndrome (Score: 2, Interesting)

by Anonymous Coward on 2014-06-03 17:31 (#20M)

I'm not sure I understand why we need to keep inventing new things. What's wrong with existing tools?

For speed and control over everything, including bare metal, I'll use C. For everything else, I'll be lazy and use Python. Others may choose different tools, but I suspect the end result is the same, finding an adequate tool for the job, and using it. Not reinventing the wheel just because.

Re: Tragic NIH Syndrome (Score: 2, Interesting)

by genkernel@pipedot.org on 2014-06-05 15:57 (#20V)

While perhaps this is just NIH syndrome, I think we *need* new programming languages to replace the ones we already have. And especially new languages that can replace C.

I largely agree with the C/Python language stack. But C isn't by any means perfect and I feel that some things could really benefit from some re-thinking. C is good, but if thousands and millions of hours are being spent coding in it, even small improvements are worth a lot. Objective-C seemed to me like a good thing, except for being limited to apple-products, because adding classes to C is both simple and powerful. For this reason I've been telling myself I need to check out D for some time. C has a great theme, and I doubt I'll give it up for some time, but I admantly believe people can do better.

And lets not forget ADA, a language that as far as I can tell has never seen its equal. It may not always be what you want, but the sheer power of compile-time checking in that language is amazingly useful. Honestly I think a language like this really needs to come back for coding mission-critical software. Oh how many failures could have been prevented if only people used a tool like ADA! Unfortunately, ADA just isn't as useful as other languages atm, for sheer lack of library and community support.

In short, when programming languages are being used so widely and when so much time is being spent using them, it is completely unreasonable to *not* look for improvements. Improvements in performance (though at the moment that isn't as much of an issue), improvements in error checking and robustness, and improvements in ease of use for faster development time. Even small improvements in any of these can be so valuable. With that in mind, does it really seem so strange that companies on the cutting edge would look to take advantage of their position to try to improve their own abillity to develop programs?

Re: Tragic NIH Syndrome (Score: 2, Interesting)

by Anonymous Coward on 2014-06-06 21:15 (#212)

Interesting argument but I think you miss the most important subtext of my position -- that the NIH approach robs us of the power of collaboration and the power of standards. Whether or not the companies making the new language go through the motions of positioning them as standards, people typically react as if they're proprietary islands -- 'cause they are.

If Apple were really interested in improving the state of the art, they'd contribute great ideas and code to improve an existing language or create a new one in collaboration with many others. But "hey here's our new language" is the same as "you must buy your software from our App Store TM". It's part of locking things down and limiting progress.

Re: Tragic NIH Syndrome (Score: 1)

by genkernel@pipedot.org on 2014-06-13 06:29 (#23C)

Hrm. I think "locking things down" can only be a serious problem in languages that compile to bytecode (a hard case of The Java Trap ), or languages that undergo regular breaks in compatibillity (I don't think I've ever been aware of a case of this, because that can cause languages to disappear rather fast, if only due to ruining the language's library ecosystem). It can be a problem under other circumstances as well, if the only compiler costs money to buy or it only has a working compiler for certain operating systems. That said, these are lesser problems. The former I believe has generally been recognized as incredibly unwise for anyone seeking to promote a language, and the latter is a problem that will solve itself if the language actually gets used outside of niche domains (in addition to being a significant hurdle to language adoption in its own right).

This doesn't apply to google's languages. This *can* definitely apply to Swift, if they are ultra aggressive about keeping their compiler running on apple-operating systems only. If the API is fully published, and not subject to copyright (Oracle just needs to die), then only (deliberate) implementation quirks, breaks in compatibillity and feature creep can keep someone (especially google) from creating a perfectly fine, working compiler for android, linux, and windows. But if apple doens't delibrately sabotage their language, then that language can really only be good for us.

Finally, to address a side-issue here; ultimately I'm not sure community (especially if run like a standard's committee) development for languages is necessarily the best way to make a language. Sure it has advantages, but I have no problem with someone unilaterally deciding the features of a language as long as I don't have to use it.

Re: Tragic NIH Syndrome (Score: 1, Insightful)

by rocks@pipedot.org on 2014-06-03 20:33 (#20N)

I quite agree with your suggestion that this is, potentially, more about NIH syndrome rather than a necessary change... which does not preclude that it is going to turn out to be a useful evolution in coding...

My hypothesis for why every big company might make such moves at some stage -- if they can -- is the temptation of control. If you support standards, common tools, etc., then people might build things that you haven't anticipated in ways that you might not be able to mediate and so on. I think the business case for control and lock-in seems obvious to many, but I also think people try to create "the foundation" for all other activities based on their personal outlook. I have seen spouses, bosses, children, etc. try and exert "their way of doing things" on everyone around them simply because "their way makes the most sense". To move in the other direction, i.e., to facilitate many different people's outlook or activities pseudo-equally, a given person or business must be able to value the cognitive dissonance that can arise when other people want to arrange or do things on their own terms... just a thought (and probably not well formed).

Re: Tragic NIH Syndrome (Score: 0)

by maxim@pipedot.org on 2014-06-06 22:07 (#213)

Its two words: vendor lock-in.
Having your own language that is only available on your platform and has tons of legacy software written in it is the wet dream of all these corporations.
Thats why we are still stuck in the world of C/C++, as its the only compiled language that is guaranteed to be cross platform, and doesn't suck completely, (but still sure sucks).

Re: Tragic NIH Syndrome (Score: 3, Interesting)

by marqueeblink@pipedot.org on 2014-06-07 17:13 (#215)

The big vendors lock app developers into their platform via APIs and services. The role of the programming language is really secondary. Really, I think Apple and Google are innovating here, not in a large sense (as Java was back in the '90s, or C++ in the '80s) but incrementally improving on current practice, which is what they should be doing.

Re: Tragic NIH Syndrome (Score: 2, Interesting)

by maxim@pipedot.org on 2014-06-07 21:21 (#216)

The problem with APIs is that for each API one can make cross platform wrapper, and its works damn well
Even DirectX which was microsoft flagship api to lock the users like you say can be wrapped, and some games do this.

On the other hand, an language, locks you very hard to vendor's platform. For instance if your code is in C# your only hope is Mono and with that your
code probably be always of 2nd citizen quality on non MS platforms which is what MS wants.

About Go, I think you are right, chances are that is was really created as a research project at least without initial goal of vendor lock-in, something also evident from the fact that they did LInux, Mac, Windows, and even FreeBSD releases of their compiler.

But swift... I could only imagine how badly its entangled with Apple libraries...

Re: Tragic NIH Syndrome (Score: 0)

by Anonymous Coward on 2014-08-08 11:00 (#2S7)

Well, actually Apple and Google interests are different. Google usually releases more open-source
and did Android with more vendors, to get market share. If they were in the position of Apple,
they would probably do the same, who knows.