Linked by Thom Holwerda on Mon 14th Jan 2013 23:15 UTC, submitted by MOS6510
General Development "Programming languages are living phenomena: They're born, the lucky ones that don't die in infancy live sometimes long, fruitful lives, and then inevitably enter a period of decline. Unlike real life, the decline can last many, many years as the presence of large legacy codebases means practiced hands must tend the code for decades. The more popular the language once was, the longer this period of decline will be."
Thread beginning with comment 548861
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: It does NOT mention C#
by hhas on Tue 15th Jan 2013 13:49 UTC in reply to "RE[3]: It does NOT mention C#"
Member since:

Can Cyclone compile ANSI C code? If not, I don't think it will ever gain traction, so would not be worth including in a new Obj-C.

I think that would depend on the particular piece of code. The following might help:

OTOH, Cyclone already has an 'extern "C"' feature for interfacing to C code, so it wouldn't be a big leap to extend that to Obj-C 2.0, which could be kept around for as long as needed. There's also the option of cross-compiling - I suspect with backing from the likes of Apple and LLVM it wouldn't take long for big improvements to appear there. The 'Porting C code to Cyclone' section of the Cyclone user manual has more info:

Really, at age 40-something it's long past time C grew up and stopped behaving like a sloppy, stroppy teenager. The question is, who has the motivation to drag it up by its bootstraps? MS has no need to do so since it's already invested in C# and C++. The Linux world won't push it forward either, since it's even more sloppy and stroppy than C is.

The only real hope (for better or worse) is Apple, since C remains a foundation stone of their whole platform and therefore developer community, so as more (often less skilled) developers take up Cocoa development, the more of a liability C's flaws become. To their credit they have been trying to modernize the Obj-C language a bit, but so far the front-of-house changes are just nibbling at the edges. OTOH, now the move to LLVM is done, they're in a much stronger position to aggressively innovate.

Remember, Apple have pulled this sort of trick off before, in the transition from 'Mac' OS 9 to 'Mac' OS X. It'd be nice to see Apple demonstrate the same sort of boldness in their tool chain that they've shown in their hardware design and supply chain to such great success.

The beauty of Obj-C is that you have standard C (with all of its warts), plus an elegant OO system that includes all the niceties of a modern OO language.

Personally I really wish Dylan had worked out - it had a far more powerful and elegant OO model than ObjC/Smalltalk. Infinitely better macro system than [Obj]C too. <wistful-sigh>

This gives you one toolchain for the entire OS stack, from kernel up to web services.

OTOH, even Unix Philosophy says it's better to have a compliment of dedicated tools that play well together than a single Swiss-army tool that tries to do it all. And OS X is nothing if not opportunist, happy to integrate whatever works.

Reply Parent Score: 3

RE[5]: It does NOT mention C#
by Hypnos on Wed 16th Jan 2013 02:58 in reply to "RE[4]: It does NOT mention C#"
Hypnos Member since:

Your comment has a number of interesting points; I'll try to respond:

1) There's so much C code, and C retains such popularity, that porting is a non-starter IMHO. However, 'extern "C"' could work if perchance Cyclone were to catch on. But, as discussed on OSNews and elsewhere, "good enough" with inertia behind it is far more powerful than "better" without inertia. Even withing Apple, it's such a huge company now, their current toolchain has a lot of momentum, and there's no Steve Jobs anymore to impose big changes of direction.

2) Whether Dylan has a more elegant OO model than Smalltalk is a matter of taste. On a practical level, what can macros do that Obj-C categories cannot?

3) To "play well together" in the Unix philosophy means to have a simple common data format, the text file/stream. When it comes to system programming interfaces in Unix, this means SysV-like APIs in C. Most crusty old Unix types prefer to just code in C rather than have multiple language bindings and a more complex software stack; Obj-C is a viable compromise to many since it retains the "virtues" of C while including a usable OO model.

It seems to me there are two design questions here: (a) whether C is worth continuing to use as a systems programming language and (b) what should the higher levels of the toolchain look like -- many languages (hopefully with a common runtime, e.g. LLVM) or just one tool like Obj-C?

Reply Parent Score: 3