Comment 23C Re: Tragic NIH Syndrome

Story

Apple shifts from Objective C to Swift

Preview

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.

Junk Status

Not marked as junk