Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Is C the last compiled applications language?

By dto in Op-Ed
Thu Apr 12, 2001 at 07:10:41 PM EST
Tags: Software (all tags)
Software

I would like to post here an article I wrote about taking a small step forward from pure ANSI C, and how circumstances in the Gnome/GTK+ application developer community present an opportunity for this to happen. My suggestion involves the use of Objective-C, the dialect of C used by (among others) Apple's Cocoa and GNU's GNUstep.

Successful languages fall into enormous (but very understandable) inertia. Without some conservatism and resistance to change, languages couldn't develop lasting standards.

But isn't there a point of diminishing returns? When a large community of C developers implements its own object system, and this system continually runs into the limitations of C's design, should we grin and bear the hacks and the bookkeeping? Or is it time to explore existing alternatives for a simple object-oriented extension to C that retains its spirit? (Note that C++ does not qualify as either simple nor even roughly in the spirit of C.)


The new GObject standard implements a dynamic object system and runtime library on top of ANSI C. From what I can gather, this is an extension of and "factoring out" of the original GTK+ object/type system.

I've done a fair amount of GTK+ coding in C, and my current (+1 year) project has involved, like many programs, heavy use of object-like conventions applied to the C language. (I am developing a free music system as part of the GNU Project.) I like this stuff. I make no pretensions to caring whether or not a language is "purely" object-oriented, or even whether it is object-oriented at all.

What I do care about is convenience and clarity in programming. There are several big "costs" associated with using GTK+ and similar styles of implementing objects in C:

  • Constantly having to dereference yourself in your own objects: self->foo, self->bar. This alone can make a 10-15 line member function look extremely dense.
  • Long method names. There is just one big namespace, so the name of the class is prefixed to every single method name, every time it is called. Even worse, you have to explicitly call gtk_superclass_operation(foo) even if foo is more specialized. That is, you have to remember which classes the methods are originally declared in when calling, instead of just invoking them on the object.
  • Constant need for casting macros like GTK_ADJUSTMENT(foo), GTK_CONTAINER(foo) and the like. This is made worse by the fact that typically you only use them inside argument lists of calls (i.e. nesting gets ugly.) Unless you declare extra pointers with the right type and cast them earlier on, you have to do use the macros or get compiler problems and risk type errors. Even that is extra lines of code using cast macros; there's no way for clarity to win on this one. Combine these macros with the overly long identifiers, and you've got code where the space devoted to bookkeeping outstrips the application logic.

GTK+ and its object system are still easy to use and relatively straightforward. I think it is an excellent user-interface library. But if there is one real criticism to be made of GTK use, it is this: at times the sheer verbosity of the C API makes GTK client code compete head-on with some of the densest Java. In my own programs, at times I feel the benefits I get from using abstract data types and interfaces are almost completely canceled out by the amount of time I have to spend typing these macros and class names over and over again and making sure everything matches up. It is all the more annoying to know there is no good reason for it: these problems are a direct result of the rules of the C language, which provide a single global namespace for all non-static functions, and completely static typing.

Languages are a touchy issue. I hope nobody will take this the wrong way. I don't wish to criticize C or GTK---no language feature can be judged without respect to that language's intent and scope. I merely intend to point out an opportunity to try different tools with this job.

Here is my suggestion for improving the situation. Provide a runtime dynamic object library just as is already implemented with GTK+ and planned with GObject, but also provide a minimal set of syntax extensions on top of C, so that all three problems mentioned above just disappear (both in use of GTK/GNOME and in creation of application-specific objects.)

No time to design and build something new, you say? But someone has already built a small syntax extension to C that fits the above requirements almost exactly. What's more, the neccessary tools for using this set of extensions are already included with every copy of the GNU C Compiler. This extension is called Objective-C, and it is the native language of both GNU's GNUstep project and Apple Computer's new Cocoa framework for developing OSX applications. The language is currently moving toward standardization using C99 as a base.

To learn a new dialect of C is not an easy decision to make. But the GNOME project is already switching to a standardized, general-purpose object system for the 2.0 line of development. In this context, might not some developers be interested in trying something new? It won't be such a big step for those who wish to try. The book GTK+/Gnome Application Development already acknowledges that the original GTK object system is designed to be "runtime-oriented, more like Java or Objective C than C++." (p. 426)

There would be no requirement for any piece of code to switch. We need sacrifice nothing that is available in C. This is about conveniences that just aren't available with the stock dialect. All I suggest is that we work to improve the state of GNOME/GTK objective-c bindings so that they stay up-to-date and so that Objective-C applications can work more closely with libraries and applications written in C. (As far as I can tell, the bindings haven't been changed since 1999. I am going to volunteer my help.) Once we have that, we can talk about a developer community and what to do from there.

(Either that, or, and this is a long shot, somehow make GNU Objective-C compatible with GObject (such that it would use GObject transparently as its runtime library.) I have no idea whether or not this is possible, but it would be great because Obj-C would then simply be "extra syntax support for GObject", and we'd have the happy side-effect of not having to make a new dialect ourselves.)

The new features are few and are quickly learned: interface and implementation keywords, as well as a somewhat odd (but very readable) syntax for message passing: [reciever message:arg]. There are other wrinkles, but overall it adds up to a set of extensions that complement C's abilities and provide conveniences, rather than (like C++ does) obsoleting large chunks of the language and providing numerous pitfalls. Actually, I suspect C++ is part of the reason we are "stuck". After C++ began to go wrong and grow too large, it lost the original spirit of "C with Classes" Then there was no agreed-upon next step.

There was a story here on Advogato a while back, about how C++ wasn't popular in the free-software world. It's like there were no options if you wanted language support for abstract data types or objects in free software---if you need a compiled language, the static C/C++ choice may give you either too little or way too much. Alternative compiled languages have been slow in coming due to lack of availability, but nearly all the free software world has access to Objective C in the form of GCC and GDB. I think it could work (Apple certainly does.)

I would ask anyone who's interested to respond to this message and give your opinions and ideas. (Or flames, I have already discussed the idea with some hard-liners. You know who you are. :-) If enough application developers become interested, Objective C could become a more viable alternative to plain C for writing free software in the GTK/GNOME environment.

[link to more info on objective c]
[Apple's recent book on objective c]


[Note about the state of language bindings (from 1999)] Is there anything that can be, or has been, done to truly help fix the situation?

I am probably overoptimistic in the extreme, thinking that a new compiled language could arise to anything approaching popularity. But it seems like such a small step. Assuming that a new compiled language might become popular anyway, to me, Objective-C seems like a good candidate, especially considering its newfound popularity in the Mac world.

Then again, as jwz pointed out to me, "MacOS was written in Pascal long after Pascal was dead."

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Do you think OO in C is too much?
o yes 53%
o no 46%

Votes: 52
Results | Other Polls

Related Links
o GNUstep
o [Note about the state of language bindings (from 1999)]
o jwz
o Also by dto


Display: Sort:
Is C the last compiled applications language? | 98 comments (77 topical, 21 editorial, 0 hidden)
"C with classes" (4.25 / 4) (#1)
by Delirium on Mon Apr 09, 2001 at 01:34:16 AM EST

After C++ began to go wrong and grow too large, it lost the original spirit of "C with Classes" Then there was no agreed-upon next step.

From reading various interviews with Bjarne Stroustrop (sp?), it's pretty clear that he never intended C++ to be "C with Classes." ObjC was an attempt at that; C++ was an attempt at a new language designed from the ground up as object oriented, but with a large degree of C compatibility to ease adoption.

well... (3.66 / 3) (#6)
by dto on Mon Apr 09, 2001 at 02:09:19 AM EST

Wasn't "C with Classes" the language's original name during the prototype phase? In any case that isn't crucial to my point there, I probably could have left it out. Even if Stroustrup never meant it to be such, we still have this situation: C++ has slowly turned into another Ada, and there is still no common C extension that retains the spirit of C.
--- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
[ Parent ]
why do we need C? (4.00 / 1) (#7)
by Delirium on Mon Apr 09, 2001 at 02:14:43 AM EST

Well, that brings up the question of why we need to retain the spirit of C, of course.

Why isn't C++ useable as a compiled applications language?

[ Parent ]

Rewarding simplicity (4.50 / 4) (#10)
by Sunir on Mon Apr 09, 2001 at 02:39:20 AM EST

C++ is as rewarding as Perl. The more you learn about C++, the more you get out of it. It never ends. However, unlike Perl, you can't just read a book and starting whacking in code like an infinite monkey and expect to author a web browser.

Many people who prefer Java over C++ prefer Java's easier initial learning curve. Many people who prefer C++ over Java dislike how sterile Java is (there is only one way to do it). Many experts who like Java over C++ are sick of people doing it more than one way because it's harder to understand large systems if everyone is off on their own tangent.

Personally, I love C++ because I spent the time to get to know it. But my saying is I am a compiler. Many people just don't care.

What irks me, though, is the curly brace obsession. Why not use Smalltalk or Scheme or Self? Why JavaScript, which is more powerful than Smalltalk, but its syntax is attrocious? Because once again, people don't care. The programming language is a speed bump between idea and realization, so anything to make getting over that bump easier sells.

And Java sells. And sells. And sells. Even though it's not technically amazing. C++ templates are cool (but not amazing, I admit), but worse is better, y'know.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Why the curly brace obsession? (2.66 / 3) (#28)
by Mr. Piccolo on Mon Apr 09, 2001 at 09:02:09 AM EST

Why not Smalltalk or Scheme or Self?

Smalltalk: That's easy. Nobody wants to think of blocks of code as objects! With Smalltalk, you can do silly stuff like assigning a block of code to a variable. Fun, but excessive to a lot of people.

Scheme: I hear it's like LISP. That, of course, menas code ending in 500 right parentheses, unless they implemented that square bracket shortcut, which, looing a little through the online version of the book, it looks like they didn't. In any case, it doesn't sound like fun.

Self: What the hell is Self? ;-)

Also, what do you mean JavaScript is more powerful than Smalltalk? They're both Turing-complete, right?

The BBC would like to apologise for the following comment.


[ Parent ]
FYI: "more powerful" (none / 0) (#62)
by Sunir on Mon Apr 09, 2001 at 08:36:00 PM EST

You compare the relative power of two programming languages not by their Turing completeness, but the breadth and depth of first class objects provided. In other words, the more dynamic a language, the more powerful it is.

For instance, lambda expressions add power. Reflection adds power. Operator overloading adds power. Polymorphism adds power. Prototype-based languages (like Self and Javascript) are more powerful than object-oriented languages (like Smalltalk).

Speaking of which, Self is Smalltalk, only more so.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

why (none / 0) (#98)
by hading on Mon Apr 16, 2001 at 12:13:39 PM EST

Smalltalk: That's easy. Nobody wants to think of blocks of code as objects! With Smalltalk, you can do silly stuff like assigning a block of code to a variable. Fun, but excessive to a lot of people.
Some of us do. I think of it more as useful and natural than fun, but that's just my opinion.
Scheme: I hear it's like LISP. That, of course, menas code ending in 500 right parentheses, unless they implemented that square bracket shortcut, which, looing a little through the online version of the book, it looks like they didn't. In any case, it doesn't sound like fun.
Chances are good that anyone whose Scheme or Lisp code has functions that end with an excessive number of parenthesis isn't a very good Lisp coder. In my code (not that I fancy myself a great Lisp coder, but I try :-) more than five or six is pretty uncommon. (Whether or not Scheme should be considered a Lisp depends largely on whom you ask, and asking is a really good way of starting a flamewar in comp.lang.lisp. :-)

We agree on Crimson, although I'm more of a Larks' Tongues in Aspic, Part I man.



[ Parent ]
retain the spirit of C (3.50 / 2) (#11)
by dto on Mon Apr 09, 2001 at 02:40:27 AM EST

If it didn't do this at least somewhat, not many C programmers (myself included) would find it attractive. Objective C represents a small step beyond C, whereas current C++ does not.

As for C++.... I guess almost anything is "usable." My main gripe with C++ is that it has become ludicrously overcomplicated, and that the language taken in full includes too many redundant constructs. People heavily subset the features. Furthermore the gap between C and C++ has become so large that it is not easy to move from one world to the next.

Finally, hardcore C people are usually not against OO, they just hate C++. :-) If there's a viable middle ground I think some people will switch.
--- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
[ Parent ]

C++ is not C (4.00 / 3) (#14)
by Delirium on Mon Apr 09, 2001 at 03:01:45 AM EST

As for C++.... I guess almost anything is "usable." My main gripe with C++ is that it has become ludicrously overcomplicated, and that the language taken in full includes too many redundant constructs. People heavily subset the features. Furthermore the gap between C and C++ has become so large that it is not easy to move from one world to the next.

Well your first complaint may be valid. Many people complain about C++'s complexity, though from reading interviews with Bjarne Stroustrop it appears pretty clear that he's made every effort possible to only include essential features in the language. He's actually resisted quite a bit of pressure to add more things. Much of the problem isn't from C++ itself, but is from people who don't know how to program C++, which is the 2nd part of your complaint. You cannot program C++ as if it's "C with Classes" and expect it to work well. While it does have much of the same syntax, perhaps this is actually a disadvantage, since people will program in it much as they did in C; it's better to treat it as a new language and try to forget your old "portable assembler" style programming. Most of the people who complain about C++ are in fact old C programmers who still are trying to code in C; people who learn C++ first do much better.

Finally, hardcore C people are usually not against OO, they just hate C++. :-) If there's a viable middle ground I think some people will switch.

I'm not so sure; many hardcore C people seem to be against the idea of a language any higher-level than C; that is a portable assembler with functions and macros. Perhaps there are some C++ specific things they hate, but that doesn't seem to be the main thrust of the complaints (you don't see any of them coding in ObjC either).

[ Parent ]

I agree! (none / 0) (#43)
by dto on Mon Apr 09, 2001 at 12:11:58 PM EST

You cannot program C++ as if it's "C with Classes" and expect it to work well. While it does have much of the same syntax, perhaps this is actually a disadvantage, since people will program in it much as they did in C; it's better to treat it as a new language and try to forget your old "portable assembler" style programming.

You are kind of proving my original point for me; I wish I had made this a bit more concise in my article. I am not interested in discussing the particulars of the case against C++ or the textbook case against very large languages in general. (That has an answer to the common "just use the parts you want" argument.)

  1. Take the assertion that C-like compiled languages, relatively low-level, cannot be replaced. My support for this is the continued use of C for things that need either low-level access or a lot of optimization (device drivers, digital signal processing, operating systems) and also the common (and at least sensible) argument that one should use a high-level interpreted language like Python for everything except speed-critical modules (and it is suggested they be written in C.) Either way, C doesn't go away and the category of programs that truly need it, for part or in whole, will not go away.
  2. There is a need for object-oriented features, however minimal when compared with pure OO languages, among applications written (for better or worse) in C. I think syntax arguments alone could justify this. Some evidence: the urge to combine some OO features with C (why do such a bizarre thing otherwise?) that prompted some to look for "C with Classes."
  3. C++ is not C with Classes, as you acknowledged and as I wrote in the article, and thus it is not a candidate for people who want C with Classes. (So arguing about other details of C++ is just a distraction.) Which people want C with Classes? I think that those who make heavy use of OO idioms in C and create OO libraries in C qualify (even if only for client code. I'm not suggesting libraries be rewritten.)
  4. Of any alternative language, Objective-C seems like the closest and easiest to adopt experimentally. So close that it can be seen as a very small set of extensions to C. So it would be simply augmenting an existing tool with something new.

Now, staying away from the eternal C++ arguments :-) and focusing on these points, what do we have?
--- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
[ Parent ]

C++ can be C with classes... (3.66 / 3) (#48)
by ucblockhead on Mon Apr 09, 2001 at 01:14:02 PM EST

Again, it is trivially easy to use C++ as "C with classes".

Just don't use templates, the C++ libraries and operator overloading.

I'm really having a hard time understanding this because on the one hand, you list a lot of desires that C++ solves very well, and on the other, you repeatedly assert that C++ doesn't meet those desires. Yet you don't seem to be able to say why that is, other than that C++ has a whole bunch of other features you don't want.

Yes, I know this has been said repeatedly, but I have yet to see a good counterargument to it.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

A console games developer writes (4.40 / 5) (#52)
by inpHilltr8r on Mon Apr 09, 2001 at 02:39:10 PM EST

1: We replaced all our low-level C with C++, as it compiles to the same code, and eases linkage with our C++ engine and tools. We encountered some opposition from one of the more hardcore assembler guys, but he's completely come around now.

2: So is there a particular feature you'd want out of this mythical language that C++ doesn't provide?

3: I think it'd be more accurate to say the C++ is not JUST C with classes, as it's more of a superset of that particular concept.

4: Again, what precisely does Objective-C offer that C++ doesn't?




[ Parent ]
C++'s complexity (3.00 / 1) (#18)
by delmoi on Mon Apr 09, 2001 at 03:34:09 AM EST

As for C++.... I guess almost anything is "usable." My main gripe with C++ is that it has become ludicrously overcomplicated,

Yes, but you don't *have* to use all of it, or even very much of it if you don't think you need it. Just define your own subset.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
An invitation to herd cats (4.00 / 2) (#71)
by keyeto on Tue Apr 10, 2001 at 11:44:11 AM EST

Software project management has been likened to herding cats. OSS project management is more like herding cats that you can't even see. Mix well with the legendary programming virtues: laziness, impatience and hubris.

p> It's true that you can use a subset of C++ in order to avoid its horrendous complexity. The problem is agreeing on the precise subset. How exactly do you decide which bits to disallow? If you even get that far, what do you do when you find somebody has used something outside of the chosen subset? Somebody is bound to, and there is sometimes a good reason for it. Do you let it pass? Then what if somebody else uses something else that's outside of the subset, also for a good reason?

Whatever happens, you'll end up using all of C++, and suffering the consequences of it being a huge, ugly and incomprehensible language.


--
"This is the Space Age, and we are Here To Go"
William S. Burroughs
[ Parent ]
C++, C, and the Future (2.00 / 2) (#15)
by krmt on Mon Apr 09, 2001 at 03:08:12 AM EST

C++ is useable, but it's fugly. I mean... just look at templates for a good example of that. That's a sign of a hack job. The comparison to Ada seems to be dead on.

C has done well because it provides a nice balance between low and high level that allows it to be perfect for such projects as the linux kernel. That's the spirit of C, and I don't think it needs to be preserved outside of C because C fits the bill very well already. However, for big scale projects that don't require the kind of low level access that a kernel does, C becomes a little unwieldy. C++ works in these situations, but it's far from ideal and the ugly additions to the language only make it worse.

Objective-C is a nice middle ground, but I don't think it's the kind of language that really has a place in the world. C does scale up pretty well in a lot of instances and for anything higher C++ and Java are already there, kicking ass and taking names in programmer mindshare. C# will be the next big one. Objective-C had it's time, and it's gone. C++ is on the way out, slow but sure. C# and Java are the future.

"I may not have morals, but I have standards."

[ Parent ]
fugly, hack job (5.00 / 1) (#30)
by codemonkey_uk on Mon Apr 09, 2001 at 10:20:27 AM EST

Pure opion. Asthetics.

I want to see one solid argument against C++ (and they do exist) rather than these empty ill considered objections to its asthetic appeal, or lack there of.

Common, tell me *why* you think its an "ugly hack job"!
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

templates are fugly? (none / 0) (#90)
by ttfkam on Fri Apr 13, 2001 at 02:20:25 AM EST

Object polymorphism is not fugly and compile-time polymorphism is definitely not fugly.

What is the C equivalent of templates? Assuming that you can do in C what templates do in C++, the usual response is a series of #ifdefs. Now THAT's fugly. Templates are beauty queens next to the preprocessor.


If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Templates usually makes nice interfaces (none / 0) (#91)
by Ole Laursen on Fri Apr 13, 2001 at 08:29:59 AM EST

Also, though an implementation using templates tends to get a little messy (take a look at the standard library for example), the interface is usually quite neat.

With Gtk+ it is the opposite way round. The implementation code actually looks quite good, but using the interface quickly gets messy, unfortunately. That's why most people are so excited about libglade.



[ Parent ]
Well then, (4.00 / 2) (#36)
by trhurler on Mon Apr 09, 2001 at 11:10:30 AM EST

Bjarne is engaging in some "revisionist history," because that's not what he said in the early days. He's good at that; the man is as good a politician as he is a programmer. In any case, C++ is far too huge. There's just no way to justify it.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bollocks (none / 0) (#53)
by inpHilltr8r on Mon Apr 09, 2001 at 02:42:10 PM EST

So which part in particular would you have trouble justifying?

Or are you just waving your hands in the air?



[ Parent ]
Hehe... (3.66 / 3) (#57)
by trhurler on Mon Apr 09, 2001 at 04:33:39 PM EST

Since you specifically requested it, start here for something else I wrote on the topic, then read what follows:
  • C++ does not contain any threading model, and as such, you cannot, without writing your own runtime support and probably modifying the vendor's libraries too(you'll need source,) do things like thread a single object off by itself. This makes it inherently unsuitable for many tasks it would otherwise be targetted at, and in fact, many people do write such code in C++; it isn't impossible, but the results are horrendous.
  • C++ abuses the word "static" in ways that no other language ever could, ensuring forever that programmers will make mistakes with it. Subtle ones, too.
  • C++ tries to be compatible with C, but the results are quite bad, and due to silly linker issues that the C++ people were too lame to resolve automagically(it is trivial to do so,) it still needs a special statement to make it work the way you'd hope. This is lame, because if you're going to have a special statement, then the languages don't even need to resemble one another, much less be backwards compatible - so why cripple C++ in various areas just to maintain compatibility that you don't really need and can fake at the link layer? (In the same way, I might add, that you can use fortran objects with C objects under gcc.)
  • C++ has few of the compelling advantages of OO(only one, really,) and all of the drawbacks - and then some. You get the abstraction benefits, but they're rigid and brittle - nothing like early efforts such as Smalltalk, where programming was actually made easier. You also get complexity, inability to determine what a given chunk of code does without a lot of nonlocal references, and so on.
I'll come back with more after you've answered these, except that I won't bother because we'll never really finish with this list:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Hoho... (4.00 / 1) (#73)
by inpHilltr8r on Tue Apr 10, 2001 at 09:40:39 PM EST

Go there for my response to that.

1: C++ doesn't specify a threading model, that's really up to the operating system, not the language. Once an underlying threading model is established, encapsulating it in a class is trivial. Of course if everyone rolls their own, you end up with a mess, but this would be true of any language.

2: Hyperbole. You may have problems with static, that doesn't mean everyone else does.

3: The ability to overload functions (does FORTRAN let you do this?) makes automagic linking non-trivial (and I'd like to see you refute that with a 'trivial' scheme of your own). Indeed, C++ used to have automagic linkage with C, based around the first instance of a symbol having C linkage, with the rest having C++. This confused too many people, and led to hacky workarounds, hence the move to the extern "C" construct, which, once understood, is a piece of cake.

4: Well it has enough compelling advantages over C for me, and no other language competes in the 'half decent compiler for virtually any platform' stakes.

Still, this is only the fourth major project (including two shipped titles) that I've used C++ in, so what do I know...;p

[ Parent ]

Pascal is dead? (2.75 / 4) (#2)
by aphrael on Mon Apr 09, 2001 at 01:41:39 AM EST

Then why have I spent the last two years programming in it, on both Windows and Linux no less?

Not Dead, but a Zombie (4.00 / 1) (#13)
by krmt on Mon Apr 09, 2001 at 03:00:18 AM EST

Pascal kind of has a Zombie status... there's still a bunch of people writing it and a bunch of code out there for it, but there's almost no developers coming on to learn it, and even fewer new developers (or even old ones) using it as their primary language. It's basically the walking dead.

It's a lot like Objective-C. Granted, it's still being pushed by Apple (and the author here), but I don't think many new mac people or linux people will pick it up, especially with all the new java bindings in to the Cocoa API. It just doesn't offer enough advantages to C or C++ to make it worthwhile.

"I may not have morals, but I have standards."

[ Parent ]
one big difference (none / 0) (#95)
by janpod66 on Fri Apr 13, 2001 at 04:13:02 PM EST

One big difference between C++ and Objective-C is that Objective-C can still be implemented well as a fairly simple translator with an ANSI C backend. That allows you to use it with pretty much any platform that has an ANSI C compiler.

Granted, the probability isn't high, but I think if people looked at it rationally, many ANSI C programmers might be willing to migrate to it. The biggest obstacle is probably cosmetic: the Objective-C syntax is quite unusual to C programmers. If Objective-C used normal C function call notation, people would probably adopt it much more easily.

[ Parent ]

C will never die (4.00 / 2) (#4)
by Pseudonym on Mon Apr 09, 2001 at 01:59:23 AM EST

C will always be with us, because it's now used as a target language by so many other languages. You can find C on any platform, so it makes sense to use it as a (relatively) platform-independent assembly language.



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
who said it would? (none / 0) (#5)
by dto on Mon Apr 09, 2001 at 02:04:53 AM EST

The article isn't about whether "it makes sense to use [c] as a relatively platform-independent assembly language." Nor did I imply that it would die, I was talking about whether it is really worthwhile to stretch pure, standard C to object-orientation with the use of macros, instead of doing applications development in another dialect of C (that uses standard C as a "target language" like you pointed out.)
--- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
[ Parent ]
Nobody said it (none / 0) (#8)
by Pseudonym on Mon Apr 09, 2001 at 02:16:20 AM EST

I'm allowed to be not relevant, aren't I? :-)



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
nilzya (none / 0) (#9)
by cp on Mon Apr 09, 2001 at 02:36:26 AM EST

Step in line. Baa with the herd.

[ Parent ]
Java or C#... battle royale! (2.20 / 5) (#12)
by krmt on Mon Apr 09, 2001 at 02:54:04 AM EST

I love C. It's far and away my preferred language for most projects, especially when I'm just having fun. But I think C++ is an ugly ugly beast of a language, putting in these hideous features that should never have left the progenator's mouth, much less get encoded.

That said, I think that compiled java is where it should be. I love the gcj, and I really want it to succeed, and I think that running a java program should be as simple as running a C program on most platforms (the CLASSPATH variable is the biggest piece of shit ever!) However, since java has long been the language that's meant to be compiled in to bytecode, C# may be the real answer we want in a language. I don't know much about it yet, but it seems like as a pure language it may be the Next Big Thing. It'll really come down to those two as C++ gets relegated in to the background in the same way as C is now and Pascal was five years ago (not the big thing, but still kicking).

I'm personally rooting for java, since I think the language has a nice heft and feel to it, and once it's sufficiently separated from the sun libraries and establishes itself as a competent language for compiled programs (with the essential libraries and such) it'll really be a killer. The question is whether or not it will ever reach that point at all.

"I may not have morals, but I have standards."

huh? (4.50 / 2) (#17)
by delmoi on Mon Apr 09, 2001 at 03:30:25 AM EST

since java has long been the language that's meant to be compiled in to bytecode, C# may be the real answer we want in a language

Um, C# gets compiled into a bytecode as well. Actualy bytecode almost exactly the same as java's.

but it seems like as a pure language it may be the Next Big Thing.

As a 'pure language' it's almost exactly the same as Java, unless you're metering on marketing hype, I don't see how C# could be 'better' then java. I'm sure C# will be good for making windows programming more enjoyable (right now your choices are to be stuck with a nice language (C++) with a Shity API(win32/mfc), or a shitty language (VB) with a nice API (vb runtime API))
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Ignorance Gets Me (2.00 / 2) (#19)
by krmt on Mon Apr 09, 2001 at 03:44:53 AM EST

Like I said, I don't know much about C# yet, but I do think that C++ is still a piece of overgrown trash (kinda like a tumor). And because it's really got MS behind it, it probably will be the Next Big Thing, because marketing hype does matter to the marketroids who hire programmers. And if it makes someone's Windows programming more enjoyable (I wouldn't know, I refuse to code for it) then it will most certainly do well, since the Windows API is a bitch and a half in my experience.

"I may not have morals, but I have standards."

[ Parent ]
you don't have to use bytecode (3.00 / 1) (#23)
by enterfornone on Mon Apr 09, 2001 at 05:15:16 AM EST

However, since java has long been the language that's meant to be compiled in to bytecode, C# may be the real answer we want in a language.
The gcc people have a java compiler in the works, I think it's near beta at the moment, but doesn't yet support all of the standard classes like AWT. The bytecode thing is really a feature of the Sun implementation, not of the language itself.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]
Underlying assumptions in the Java language design (4.00 / 1) (#27)
by rafael on Mon Apr 09, 2001 at 08:12:01 AM EST

The bytecode thing is really a feature of the Sun implementation, not of the language itself.
Yes, but this bytecode thing has some influence on the Java language itself. Think about the reflection API. Reflection gives some power to Java but makes it difficult to be efficiently compiled to machine code.

[ Parent ]
Nah (4.00 / 1) (#66)
by Simon Kinahan on Tue Apr 10, 2001 at 05:15:40 AM EST

The only place you really need bytecode is on-the-fly class loading, where the class file format is vsisible, so you need to compile to native machine code as part of the loading process.

Reflection can be done in statically compiled languages. You just a data structure created by the compiler that represents the class of an object, that can be reached from it, and iterrogated about its type and capabilities.

Simon

If you disagree, post, don't moderate
[ Parent ]
KuroSlash (4.20 / 5) (#47)
by cezarg on Mon Apr 09, 2001 at 01:04:20 PM EST

But I think C++ is an ugly ugly beast of a language, putting in these hideous features that should never have left the progenator's mouth, much less get encoded.

I'm sorry to say this but comments such as yours make K5 a forum that is less and less worth checking in to. Frankly you don't sound like a person that has a good understanding of C++ and I'd prefer you did not comment on things you don't know. If you have constructive critisism to raise plese do it but your derogatory comments just add noise to this forum.

As for the actual issue on hand I can't see why C++ would be a bad choice for someone who wants to do OO and knows C. It's a natural progression and the language was built gradually and most people's transition to C++ is gradual almost by default. Java is nice and good although it's not be-all end-all of OO either. And you know the lack of those "butt ugly" templates makes for even uglier java containers. There ALWAYS is a tradeoff.

[ Parent ]

Exactly (none / 0) (#89)
by ttfkam on Fri Apr 13, 2001 at 02:10:07 AM EST

Let's compare the "pretty" language to the "ugly ugly" language shall we?

Java:
System.out.println( "Hello World" );
C++:
cout << "Hello World" << endl;
C:
printf( "Hello World\n" );

Seems a matter of preference here. Let's look at a slightly more complex example. Let's assume that we've already defined "Dog."

Java:
Dog d = new Dog();
Vector vec = new Vector();
vec.addElement( d );
C++:
Dog d;
std::vector<Dog> vec;
vec.push_back( d );
C:
...nah nevermind. I'd rather not write my own vectors. It's not like I'm going to end up much faster than the above examples.

Question #1: Which one is faster?
Answer #1: Speed differences are negligible; there is a greater speed difference in compilers and JVMs than in the inherent language qualities. In 99.9% of the cases, the speed difference does not matter.

Question #2: Which looks better?
Answer #2: Most likely it will either be the one you learned first or the one you use most now. In 99.9% of the cases, the programmer who takes pride in their code will be the most attractive regardless of language.



If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
bleh, C (2.62 / 8) (#16)
by delmoi on Mon Apr 09, 2001 at 03:25:59 AM EST

Is C the last compiled applications language?

Maybe I missed it, but what does your title have to do with the rest of the paper? And while C++ does have a lot of stuff in it, you don't need to use it if you don't want to. I'm sure you could get C++ to do what you want.

And god, why would you want to use C instaid of C++? Other then a desire not to change, of course. That language is painful.
--
"'argumentation' is not a word, idiot." -- thelizman
Why C++ Sucks, and a Defense of C (1.50 / 2) (#20)
by krmt on Mon Apr 09, 2001 at 03:52:32 AM EST

While you don't have to use all the features of C++, someone else's code that you will have to read will make use of some butt ugly feature like templates that will make you go huddle in a corner and wimper. C++ was never meant to be clean, and that's why another post compared it to perl: full of features but really ugly. However, C++ isn't meant for a quick hack job the way perl is, and since it is the major language used on large scale projects these days, you'd expect it to be both clean and flexible. C++ is certainly flexible, but it's just plain sucky in terms of being neat and trim.

As for why you'd want to use C, here's few:
  • Systems level programming
  • A desire to interface with previously written C code (a certain kernel and window system springs to mind)
  • A large number of libraries for C
  • Familiarity
  • Not wanting to wrestle with a 900 or so page C++ reference when you can deal with a ~200 page reference
  • The desire to not program OO (C++ can do this too, but then it's really just C)


"I may not have morals, but I have standards."

[ Parent ]
Difficulty wrestling with 900 page references? (3.33 / 3) (#22)
by pig bodine on Mon Apr 09, 2001 at 04:58:36 AM EST

You must be one of those weak, skinny type programmers. I am easily able to hold my 900 page C++ reference in one hand, whilst turning pages with the other. If you are having trouble doing this, I would suggest you need more exercise, not a different programming language.

[ Parent ]

C vs. C++ (4.80 / 5) (#24)
by cameldrv on Mon Apr 09, 2001 at 05:27:26 AM EST

Systems level programming

Well, if you mean the Linux kernel, then yes, it's not C++. However there are operating systems that are written in C++. C++ is perfectly suitable for operating system development.
A desire to interface with previously written C code (a certain kernel and window system springs to mind)

You can interface with X and the Linux kernel with no problems with C++. Just use extern "C".
Familiarity

I'll grant you this. If all you know is C, learning all of C++ is a bit of work. However, once you know it, you can write programs which are much more maintainable and modular.
Not wanting to wrestle with a 900 or so page C++ reference when you can deal with a ~200 page reference

If you're a serious programmer, a 900 page manual shouldn't scare you off.

The desire to not program OO (C++ can do this too, but then it's really just C)

At this stage of the game, if you don't want to program OO, it's probably because either you don't understand it, or you're just resistant to change. A serious programmer isn't going to have either of these problems.


[ Parent ]
OO doesn't solve all problems (3.50 / 2) (#33)
by hardburn on Mon Apr 09, 2001 at 10:54:01 AM EST

if you don't want to program OO, it's probably because either you don't understand it, or you're just resistant to change.

Or OO doesn't solve your problem. I find that OO is really good for solving the middle-of-the-road problems. It gets too bloated for little hacks, and has too much overhead for big complex beasts. This is why Linus rejects usage of anything but pure C (or ASM, where needed) in the Linux kernel. Yes, there are kernels written in C++, but the most widely used ones are not.

OO is not a magic bullet. It's a tool to be used where needed. If it doesn't get your job done, dump it.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Wrong! (4.00 / 1) (#41)
by darthaya on Mon Apr 09, 2001 at 12:03:36 PM EST

1: Linux kernel is hardly a big complex beasts. It can fit into one floppy for christ's sake, and there are only that many key developers for it. For beast like Oracle database, I would think they intensely use Object Oriented Programming techniques.
<p>
2: There are many reasons for not using C++ in the kernel code, but again, C++ is not the synonym for Object oriented programming. It is just one implementation of it. Can you find me the reference where Linus specifially says "Object oriented programming sucks! We should all go back to procedural programming"?
<p>
3: And btw, Linus is not god.

[ Parent ]
Kernel C++ Sucks (3.50 / 2) (#61)
by sigwinch on Mon Apr 09, 2001 at 07:24:19 PM EST

Can you find me the reference where Linus specifially says "Object oriented programming sucks! We should all go back to procedural programming"?
The objection is not against OO. In fact, the core of the Linux kernel is *highly* OO (file ops structure, networking ops structure, and many others).

The objection is to C++ specifically as a giant, hairy collossus. Some examples:

  1. Multiple Inheritance: People would be tempted to do things like multiple inherit the Xircom NIC device driver class from the tulip chip class and the generic CardBus class, both of which in turn are derived from the generic device driver class. This makes sense at a high level, but C++ has little-used corners of syntax that make this confusing. E.g., do references to the generic driver class refer to the same data for both the tulip and CardBus parts of the Xircom class? If you have to spend 30 minutes reading the language manual for a minor feature, the language is broken.
  2. Exception Handling: Suppose I take a lock before reading from a block device (which would be implemented as a class), and the read throws an exception. How does the lock get released? One way is to put the locks inside auto objects. But then suppose I acquire a lock and then pass responsibility for releasing it to some other code. Now my locker class has to keep extra bits (or I have to have several locker classes, one for each unlocking policy).
  3. Memory Management: Suppose that, to improve allocation speed, I overload new for a class. The improved new uses several pools of reusable objects, and automatically allocate/expands pools as necessary. Suppose I then innocently instantiate this class in an almost never used path in an inner scope of the kernel memory allocator. The kernel will then occassionally blow up with infinite recursion. Kernel work necessarily requires exacting control over memory allocation, including the precise methods used. C++ hides much of this, and would lead to very subtle and difficult-to-diagnose crashes.
  4. C++ Object Infrastructure Is Poorly Defined And Difficult To Manage. Suppose I define a derived class in a loadable kernel module. The obvious implementation is to store the vtable in the module. If the module hands these custom objects to the rest of the kernel, the kernel will naturally need access to the vtable. Therefore, you must guarantee that the module is not unloaded until all derived objects have been destroyed. If this isn't done, the kernel could blow up just attempting to access the object, even if it doesn't call the overloaded functions. To handle this, you have to bump the module reference count for every object allocated in the module, if the object was derived in the module, if the object could be passed out of the module. You can write some very innocent looking code -- picture perfect readable good C++ code -- that will blow up the kernel.
     
    And now that I've thought a little more, it gets even worse. The reference-count-decrementor has to be in the class destructor and is inherently racy: decrement the reference count, module unloads, destructor continues to run and accesses ex-vtable. Boom -- end of kernel. So you're screwed. The rule has to be: Never derive a class in a loadable module from base classes defined in the core kernel, unless objects of the derived type never leave the module. And even if you could overcome this by putting the reference counting in the C++ compiler, you'll still have to take the big kernel lock for the reference counter (to keep the class from deadlocking itself), and that'd murder performance.
When Linus says C++ will never go into his kernel, he's thinking of things like these. None of them is impossible to overcome, but they require tremendous programmer discipline about extremely subtle issues. Incidentally, these issues affect multi-threaded usermode programs too, and that's one of the reasons I'm not entirely happy with C++.

--
I don't want the world, I just want your half.
[ Parent ]

Good design, not language concerns (5.00 / 3) (#88)
by ttfkam on Fri Apr 13, 2001 at 01:46:41 AM EST

The objection is to C++ specifically as a giant, hairy collossus. Some examples:

All right. I'll bite...

1. Multiple Inheritance: People would be tempted to do things like multiple inherit the Xircom NIC device driver class from the tulip chip class and the generic CardBus class

EVERY book I've read teaching C++ has explicitly warned the reader to be wary of multiple inheritance. It is a very special case item in roughly the same class (no pun intended) as goto; in general they should be avoided, but there are legitamate reasons for its use. Extending a device driver class (very specific implementation) to create another device driver class (which may have a very different, but no less specific implementation) is just plain bad code.

2. Exception Handling: Suppose I take a lock before reading from a block device (which would be implemented as a class), and the read throws an exception. *snip* But then suppose I acquire a lock and then pass responsibility for releasing it to some other code.

Ah yes, this is the other great fallacy of C++ haters. For some obscure reason, many C coders seem to believe that C++ advocates the use of exceptions without any apparent forethought or care. Yes, in your scenario, this would have horrendous results. You should also note that you are violating a basic tenet of OO design. Pass responsibility so that some other section of code can modify what amounts to the internal structure of the object? Give me a break. You're creating a problem which doesn't need to exist. A properly designed object structure doesn't have this problem. Repeat: a properly designed object structure doesn't have this problem. Repeat until that sinks in.

3. Memory Management: Suppose that, to improve allocation speed, I overload new for a class.

Suppose I rewrite malloc() to improve allocation speed... Wups! You mean that once again, languages do not absolve the programmer from actually writing correct code. If you are overloading "new" because you are certain that it is the best way to gain performance, you are either (a) going to get it right because you know what you are doing or (b) going to horrible fubar the code because you don't know what you are doing. Also, speed issues in standard "new" versus a custom "new" are examples of premature optimization 99% of the time.

(continued) The kernel will then occassionally blow up with infinite recursion. Kernel work necessarily requires exacting control over memory allocation, including the precise methods used. C++ hides much of this, and would lead to very subtle and difficult-to-diagnose crashes.

And C never shows occasion for "very subtle and difficult-to-diagnose crashes." In fact, the kernel mailing list are a bunch of govial fellows without a care in the world, all problems are simple to solve, and hard to reach places never cause intermittent problems. Are you high or something? Everything in C++ has a reason and an implementation. Also, the fact that you are the one implementing this unique, handy-dandy "new" should imply that you know what you are doing and can assert control. The C++ behavior model is very well documented. Don't know how much space a vtable takes? Look it up. Don't know how standard "new" reacts? Look it up. C++ may hold innumerable surprises for the newly initiated, but there is no excuse for someone who has actually done their homework. In this case I recommend that people read such books as <u>Efficient C++</u> by Bulka and Mayhew. Want to know what the pitfalls are, how to avoid them, and why they happen? Read this book. 300 pages. As technical books go, no big deal.

4. C++ Object Infrastructure Is Poorly Defined And Difficult To Manage. Suppose I define a derived class in a loadable kernel module.

Someone earlier complained about the 900 page spec for C++. This is poorly defined? Complex? Sure. Voluminous? Definitely. Poorly defined? Not even close! People who say C++ is poorly defined are many times the same people who decide not to read the spec, buy some lame "Learn C++ in 2 Hours" book and wonder why they're hitting roadblocks in C++.

You assume that because you want to pass randomly defined objects around your kernel that you should do so. Maybe I'm misunderstanding your example (we were last examining network drivers). If you have a driver for a network card, why on earth would you want to have multiple objects referring to perhaps one network card? Are you accessing this object as it is defined or through a clearly defined interface that is known to the kernel? Honestly in this case I can't tell for sure if I'm misunderstanding your point or if you are just horribly wrong. Also, just because C++ can have an object model doesn't mean that you can't use C-style techniques in timing/speed sensitive code or places where a vtable will cause more problems than it solves. Individual cases do not invalidate all of the possibilities.

And now that I've thought a little more, it gets even worse. The reference-count-decrementor has to be in the class destructor and is inherently racy: decrement the reference count, module unloads, destructor continues to run and accesses ex-vtable. Boom -- end of kernel.

You're talking about a concurrancy issue, not a C++ issue. You are also talking about caveats in a module design that I would not endorse. You're taking a bad implementation and trying to prove that the language is bad because of your implementation.

Linus may proclaim that C++ won't go into his kernel. More power to him. In fact, that's great advice considering issues of code consistency. However Linus is not god. He is just a great C programmer. His opinion holds great weight, but it is only an opinion. Opinions of others such as Bjarne Stroustrup (also a great programmer) differ in this case.

Studies have shown that programmers code best in the language they are best at. (duh!) A programmer coding in an unfamiliar language will also write slower and less efficiently. C++ can and has been used to write fast and efficient kernels. C++ can and has been used for low-level access to devices. Many C++ coders are not as good in C as experienced C coders. The opposite is also true. Many good C coders assume that because they are good C coders, the fact that C++ is not immediately intuitive to them or as fast when using their usual coding idioms, that the language is somehow defective. This is NOT the case.

In closing I would like to point out that you equate bad C++ programming practices with C++. This is a poor comparison. There is some truly rotten C code out there. I'm sure that anyone who has briefly watched the kernel mailing list has seen Linus deny a patch on the grounds that, while it works as specified, is horrible code etiquette. The best kernel programmers are aesthetes. They care about the overall design and loathe bad solutions to problems. If you are going to fix something do it right. If you're going to design something, don't do it half-assed. If you can't design a proper solution in C++, that's fine. But don't go out blaming the language when it may be your own limitations shining through.


If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Oracle database (none / 0) (#63)
by pete on Mon Apr 09, 2001 at 09:08:10 PM EST

FYI: the Oracle database is written in C, with more and more of the add-ons (Enterprise Manager, etc.) being written in Java. If I had to pick the top two reasons why it's in C:
  • It's been around for quite a while and hasn't been through a fundamental rewrite in a long time (before C++ was really popular)
  • Compiler quality on the platforms the DB is available on (quite a few!) is much more consistent in C

    --pete


    [ Parent ]
  • OO in kernel vs C++ in kernel (4.00 / 2) (#84)
    by bored on Thu Apr 12, 2001 at 04:28:58 PM EST

    2: There are many reasons for not using C++ in the kernel code, but again, C++ is not the synonym for Object oriented programming. It is just one implementation of it. Can you find me the reference where Linus specifically says "Object oriented programming sucks! We should all go back to procedural programming"?

    I agree! this is exactly the point! The linux kernel is full of OO methodologies (as is any OS kernel). The difference is that they are all implemented by hand. Structures with function pointers, are everywhere in the kernel. The whole point of having an OO language is so that you don't have to reinvent the wheel every time you need an OO concept. This is why I am an advocate of completely throwing away C. C++ sucks for OO development but C is even worse. I summarily dismiss people who won't use C++, for some long list of bugus reasons, as either stupid, uneducated or old and set in their ways. C++ is an extension of C, if some particular feature isn't useful then don't use it. The same argument applies to C if some features are problematic don't use them. Sure C++ adds new pitfalls but most of the common programming errors are actually due to the stupidity of the original C design rather than anything C++ added to the language. If anything, C++ makes the language more robust though things like stronger type checking which forces the programmer to think about what they are doing before they arbitrarily assign unlike types. As a benefit of having these new problems you gain the ability to have a standard way to represent certain constructs like virtual methods, which should be used when needed rather than as a 'gee this is cool' application. C IS DEAD in the same way fortran is! people who claim otherwise are just fooling themselves. New development overwhelmingly occurs in C++, java or one of the scripting languages.



    [ Parent ]
    Odd... (none / 0) (#49)
    by slaytanic killer on Mon Apr 09, 2001 at 01:31:34 PM EST

    I find that OO is really good for solving the middle-of-the-road problems.
    Y'know, it seems like there is something very profound in that, but I don't quite know what it is.

    [ Parent ]
    asthetics (3.75 / 4) (#26)
    by codemonkey_uk on Mon Apr 09, 2001 at 07:30:12 AM EST

    Your comments on why C++ sucks summerised:
    "butt ugly", "really ugly", "just plain sucky in terms of being neat and trim"
    Yeah. Okay. Nice argument. Now try actually considering its technical merits. Your argument is based purly on personal asthetics.

    You give the impression that you dislike C++ because you don't understand C++.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]

    KDE and C++ (4.25 / 4) (#29)
    by dennis on Mon Apr 09, 2001 at 09:16:59 AM EST

    C++ wasn't popular in the free-software world

    I've heard this said, but what about KDE? Not only written in C++, but if my books on KDE programming can be trusted, most KDE apps are written in C++ too. Your viewpoint from the Gnome side of the fence might be a little biased.

    Of course there certainly are a lot of developers who do hate C++, so it seems to me your objective-c idea has some merit (though I don't know the language). Some people have brought up java and c#, but I'm skeptical that bytecode-interpreted languages can fill the same niche.

    No bytecode here (4.00 / 1) (#32)
    by hardburn on Mon Apr 09, 2001 at 10:46:49 AM EST

    Some people have brought up java and c#, but I'm skeptical that bytecode-interpreted languages can fill the same niche.

    Then don't use a bytecode compiler. I don't know about C# (and I refuse to touch it with a nine foot stick), but there are Java compilers like GCJ that can translate source code directly into machine language. GCJ is a little buggy right now, but it's being cleaned up so it can be in GCC 3.0 by default.

    Side note: Does anyone know how difficult it would be to take an existing JIT compiler (i.e., Kaffe) and make it into a straight machine code compiler? Seems to me that this would be a lot simpler then making an entirely new compiler, but maybe there are issues I don't know about.


    ----
    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


    [ Parent ]
    Porting Kaffe (none / 0) (#58)
    by LukeyBoy on Mon Apr 09, 2001 at 04:47:37 PM EST

    It would be damned hard to port an existing Java compiler (either Sun's, or a freeware one) to a native code compiler. GCJ is part of the GCC toolchain, and has all the information about generating code for a ton of platforms and architecures already built-in.

    A Java compiler only knows how to spit out byte-code, and absolutely nothing else. It is a lot simpler to implement something like GCJ than to port any existing JVM/Java compiler.



    [ Parent ]
    Language features. (4.00 / 7) (#31)
    by ucblockhead on Mon Apr 09, 2001 at 10:40:29 AM EST

    Why not just use C++ and ignore all those features that you find confusing and overcomplicated?

    Sounds to me like this would give you exactly what you want. C, but with some additions to make OO life easier.

    For example, you say here:

    Constantly having to dereference yourself in your own objects: self->foo, self->bar. This alone can make a 10-15 line member function look extremely dense.
    Seems to me the solution is to simply go to C++ and ignore every single language feature except for the "class" keyword. Change your object structs from:

    struct Foobar
    {
    };

    class Foobar
    { public:
    };

    That gives you exactly what you want. "self" is gone. And this is not "overcomplicated", because you aren't using any other C++ language feature.

    I could walk down the line of your requirements and do the exact same thing. What you want exists in C++. Just ignore the STL. Ignore the iostreams library. Ignore templates. Ignore multiple inheritance. Ignore "private" and "protected". Ignore all the language features you find confusing. You then have almost exactly what you want.

    What you want can be achieved just by using three C++ keywords, ("class", "virtual", "new/delete") and if you ignore all other C++ language features, it should be no more complicated than what you are doing already.

    The strength of C++ is that it is a set of incremental changes to C. Because of this, you don't need to take it all. You can just take what suits you. Unfortunately, no one seems to understand this strength.
    -----------------------
    This is k5. We're all tools - duxup

    Why not? (3.20 / 5) (#35)
    by trhurler on Mon Apr 09, 2001 at 10:57:01 AM EST

    Simple. Because then you have to have a coding standard, and new people have to learn which features are and aren't approved for use, and someone has to check all code that goes in to make sure it conforms. Otherwise, you end up using all of C++ eventually, and then your code is an unreadable mess to anyone on the planet except Bjarne and his three little friends. Most "professional" C++ programmers can't even name all the kinds of typecasts in that bloated pig of a language, much less the useful features.

    --
    'God dammit, your posts make me hard.' --LilDebbie

    [ Parent ]
    Coding standards (4.33 / 3) (#39)
    by ucblockhead on Mon Apr 09, 2001 at 11:47:33 AM EST

    If you don't have a coding standard, then bad programmers will screw you up no matter what language you are coding in.

    If you don't think that C can be made into an unreadable mess by idiot programmers, than I've got a few real-world code samples to send you.


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    I worded that poorly. (none / 0) (#44)
    by trhurler on Mon Apr 09, 2001 at 12:14:45 PM EST

    What I should have said was, "then you'll have to have a coding standard that specifies what language you program in, because it isn't REALLY C++, but rather a small subset thereof."

    Those sorts of standards are devilishly hard to enforce, and it gets worse at a quickly increasing pace as you add programmers.

    --
    'God dammit, your posts make me hard.' --LilDebbie

    [ Parent ]
    solution (4.00 / 1) (#65)
    by codemonkey_uk on Tue Apr 10, 2001 at 04:59:35 AM EST

    The solution if of course to use properly trained, talented programmers, rather than the certified monkeys that most shops hire. (Or the egomaniacal teenagers that curn out a good percentage of free software).

    The biggest problem C++ faces is one of education. Something clearly demonstrated by the discussions in this article.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]

    Let me put it this way (none / 0) (#70)
    by trhurler on Tue Apr 10, 2001 at 10:52:52 AM EST

    I am a "properly trained, talented programmer." So are my coworkers - but we're a tiny company. Good for us. Now, what will we gain from C++ that is outweighed by the fact that we'll be stuck at a hiring pace of one person a year or so(that's all the really well qualified people we can find; lots more "can do the job" but aren't great?) Keep in mind that we're trying to grow at a rather high rate in order to tie up a large share of a rather new market, so we can't just hire one person a year and take it on the chin.

    The reason I give this example is this: for any business where the business is more important than the code, which is to say every business, needing to have the highest quality people just to look at your stuff is a losing proposition. I'm not saying hire losers, but there's a continuum of skill that includes a lot of middle ground people who simply cannot write reasonable C++. (By the way, do understand that the business IS more important than the code, at least from the business perspective. After all, Microsoft can sell shoddy shit to morons and make billions, but BSDI just sold their high quality software division because it wasn't likely to be as profitable as their server hardware business.)

    --
    'God dammit, your posts make me hard.' --LilDebbie

    [ Parent ]
    apples and oranges (4.25 / 4) (#42)
    by dto on Mon Apr 09, 2001 at 12:07:43 PM EST

    This would not work. The object systems in C++ and Objective-C are very dissimilar. One is more like Simula and the other is more like Smalltalk. Because of this, C++ needs a TON of extra stuff to implement some features that are standard objc. (For instance, RTTI and templates would be complete redundancies in objc.) Someone posted a comment about it in a recent C++ story here.

    The "you can just use the parts you need" argument did not save Ada, PL/1, or Common Lisp, because it is just not workable. Consider the obvious point that hardly any two teams of programmers would then know the same feature set. To communicate broadly you need to learn the whole language, thus the assertion is disproved---you really can't effectively learn just the parts you need. One cannot program in a vaccuum.

    The strength of C++ is that it is a set of incremental changes to C. Because of this, you don't need to take it all. You can just take what suits you. Unfortunately, no one seems to understand this strength.
    How Zen! Only the people who know all the language tend to appreciate how you don't need to know all the language.

    Oh, and this is a side point, but I am so tired of the standard condescending response that comes with language criticism or comparison. Especially with anything object-oriented, the "don't use the parts you need" too easily becomes "ignore all the language features you find confusing." (Your words.) I think we could do with a bit less Bertrand-Meyerism.
    --- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
    [ Parent ]

    Uh, no... (3.66 / 3) (#46)
    by ucblockhead on Mon Apr 09, 2001 at 12:44:21 PM EST

    There's nothing Zen about it, and you don't need to know all of the language to use parts of it.

    Hell, what I'm describing to you is basically how my first couple C++ porjects went. One in particular did extremely well with four C programmers and one guy (me) who new the language a bit, but had never used it a large project. We simply used a small subset that we all could understand and in consequence, we finished the project on time.

    If I appear condescending, than I apologize. Hell, there's quite a bit of C++ I find confusing, and therefore avoid. But I think the reason you are getting a lot of condescension is because, quite frankly, you are levelling a lot of criticisms at something that you clearly do not understand.

    But in any case, it is not only possible to do what I suggest, but I've done it on successful projects.


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    i'm not convinced (3.75 / 4) (#54)
    by dto on Mon Apr 09, 2001 at 02:46:42 PM EST

    If I appear condescending, than I apologize. Hell, there's quite a bit of C++ I find confusing, and therefore avoid. But I think the reason you are getting a lot of condescension is because, quite frankly, you are levelling a lot of criticisms at something that you clearly do not understand.

    No. Anyone who criticizes C++, either competently or incompetently, is automatically assumed to not understand it.

    Prove me wrong. Can you at least offer support (other than anecdotes about past work experience) for why you don't think I understand C++? Can you articulate a correct version of what I have stated or implied that is incorrect? Can you offer anything more specific?

    At least respond to the other points (for instance, why Objc's object system might support things that C++'s does not or makes difficult.) .
    --- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
    [ Parent ]

    mistakes (4.50 / 4) (#55)
    by ucblockhead on Mon Apr 09, 2001 at 03:22:19 PM EST

    Look, I have criticized elements of C++ myself, so don't paint me as some sort of zealot.

    The reason I don't think you undestand C++ is implicit in my first post. You say, basically, "I wish C could be extended to do 'X' without the huge complexity of C++". The thing is, as I showed, it is pretty trivial to use C++ to get just exactly those extensions without using any of the rest of C++.

    Look, there is a reason printf() and the rest of the C standard library exist in C++. There is a reason that C++ objects don't all inherit from some base object in a huge heirarchy. There is a reason that you don't have to define an object with a "main" method.

    That reason is to do exactly what you seem to be looking for: so that users can, if they wish, use C++ as a very light C++ with classes and ignore all the complex language features.

    One incorrect statement is at the crux of the matter:

    C/C++ choice may give you either too little or way too much.
    This is completely incorrect in that C/C++ allows you to work at the level of C, the level of full-blown C++ with templates, exceptions and everything, and any level in between.

    Here's another error:

    ...rather than (like C++ does) obsoleting large chunks of the language...
    Completely incorrect. C++ was intentionally designed not to obsolete any C features. The whole damn C library is there. The C typecasting system is there. What C feature is missing from C++?

    I'm not saying that C++ is perfect, and if you search enough around this site, you'll find posts from me bemoaning its failings. And I'm not even saying that Objective-C is a bad thing. But your article quite frankly displays a gross misunderstanding of the way C++ can be, and is, used in the real world. In essence, you seem to think that a language that was explicitly designed to be a set of incremental enhancements has to be adopted either in its entirety, or not at all.


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    that's it? (3.00 / 3) (#60)
    by dto on Mon Apr 09, 2001 at 05:57:14 PM EST

    No, no, no. That C++ can be used "at any level" and was designed on purpose as a set of incremental enhancements is common knowledge. But I think this core concept ran out of steam years ago. Now it's like trying to merge Perl and Python and say that you can pick any setting on the dial between them and still get something coherent.

    I worked with C++ for several years. So many projects use different ad-hoc subsets of the language that they are essentially little personal dialects, no two alike. The only way to avoid this is to agree on a common dialect (is there one besides C?) or just use the whole thing (in which case it is too big.)

    I know everything from C is supported in C++. Everyone knows it. But many C++ people (quite understandably) have not worked extensively with plain C artifacts or the base libraries because they learned all the C++ equivalents instead. They're not teaching it that way anymore, even when they offer C++ (instead of the new Java courses.) I work as a tutor for C.S. undergraduates, and most of the new people learning C++ had not seen printf, malloc, free and all that. If they work in the C++ and Java worlds they might never have to.

    That is fine. Of course C++ should grow and improve itself when its developers see fit. But it also means that using C++ as "C with Classes" in an ad-hoc way is not that attractive a concept, as it will look as foreign to most new developers as would Objc or even plain C.

    Using C++ to its fullest may be very productive for its users, but pretending that it is "C with Classes" is not a winning strategy. The question wasn't whether C++ contains features that can be pieced together to do the task.

    In any case I'm sorry this generated a discussion almost entirely about C++ problems and not much about Objective-C. (When I brought up the point about the Simula-versus-Smalltalk thing in object systems, and why someone might prefer the one C++ doesn't have, it was ignored.) I will think long and hard before trying to justify the existence of any languages besides C++ again.

    Maybe it will work backwards, and if I post an article about how great C++ is, people will talk about Objective C? :-)
    --- @@@ dto@gnu.org @@@ GNU OCTAL @@@ http://www.gnu.org/software/octal
    [ Parent ]

    That makes no sense... (3.75 / 4) (#64)
    by ucblockhead on Mon Apr 09, 2001 at 10:38:45 PM EST

    You are saying that because most people don't use C++ as "C with classes" and wouldn't be familiar with it, you want to make an entirely new language that does the same thing? That makes no sense.

    The only concrete criticism I've been apply to find is that you don't like the way people use C++. That's not the same thing as C++ not doing what you want!

    But I'm just baffled by this whole conversation because you keep implying that doing what I have done for over a decade is somehow impossible or unworkable.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    ObjC Question (none / 0) (#67)
    by codemonkey_uk on Tue Apr 10, 2001 at 05:19:08 AM EST

    You wrote:
    ... templates would be complete redundancies in objc
    My question is: How does ObjectiveC handle compile time polymorphism?

    If you say it doesn't need to, my next question is: Why do you consider compile time polymorphism unnessesery? And: Do you think its appropriate to repeatedly resolve at runtime what could have been resolved once, at compile time?
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]

    Categories and late binding (none / 0) (#97)
    by bluesharp on Sat Apr 14, 2001 at 09:18:28 PM EST

    You wrote:
      Do you think its appropriate to repeatedly resolve at runtime what could have been resolved once, at compile time?
    This assumes that it is ever possible to resolve something at compile time. In Objective-C, compile-time polymorphism is impossible: since you are allowed to dynamically load, at runtime, new methods or new implementations of methods for your classes (or someone else's), the compiler can make no assumptions whatsoever.

    You can argue, of course, as to whether this ability is worth the cost of runtime lookups; I would say it is. The runtime is pretty fast, and it's entirely possible to explicitly cache the function pointer of an implementation yourself if you know that it's not going to change and are worried about performance.

    [ Parent ]

    ignore class (3.50 / 2) (#56)
    by mikpos on Mon Apr 09, 2001 at 04:02:08 PM EST

    First off, you can ignore the 'class' keyword and stick with 'struct': it's exactly the same as 'class' except members are public by default (instead of private).

    Secondly, C++ provides a very poor tool for objects due to its static binding. In this respect it's basically C with name-mangling, which is not always helpful (though it is in the example tho OP gave).

    Finally, C++ is not a better C. Superficially, it looks like C, but it's an entirely different language. Conforming C++ compilers are obliged to barf on some of the simplest of C programs; this problem has increased since C99 was released. If you are a C programmer and try to stick to your old coding techniques (e.g. allocating memory) with C++, you will find it is not a better C than C (in fact it is a much worse C than C): it is simply a better C++ than C.

    I'm not trying to deride C++; it's a great language. But it is not C and it is not Objective C. It is not just a set of incremental changes to C; it is a different language. It should not be viewed as a replacement for anything.

    [ Parent ]

    class (4.00 / 2) (#59)
    by ucblockhead on Mon Apr 09, 2001 at 05:12:57 PM EST

    You are right about the class thing. I realized that about a half hour ago and have been kicking myself since.

    In terms of the "entirely different language" thing, well, I'd dispute that. Yeah, it is trivial to write a C program that won't compile under C++, however, when you try converting a real world program from a C to a C++ compiler, you'll find that the differences are trivial. It's language-lawyer stuff.

    The idea that a C-like program compiled with C++ is "much worse than C" is flat out wrong. I'd love to see an example of that. In theory, unless the compiler is broken, the executable output should be the same. "malloc" under C++ should be no different from "malloc" under C.

    And I'm sorry, but you are just wrong about C++ not being made up of incremental changes. The whole point of the language is as a piecemeal addition to C. Otherwise, we'd all be using Simula.


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    C++ has a very different object model (4.50 / 2) (#93)
    by janpod66 on Fri Apr 13, 2001 at 04:00:09 PM EST

    In Objective-C, you can replace objects for one another that are not related by inheritance, as long as they implement the same methods. The signature extension for C++ gets at that (GNU C++ supports it), but standard C++ doesn't. Furthermore, Objective-C is dynamically typed with much more RTTI information available than C++.

    For a language as small and simple as Objective-C, that translates into a lot of bang-for-the-buck; it does a lot more with a lot less.

    [ Parent ]

    C# vs Objective C (3.00 / 5) (#34)
    by caine on Mon Apr 09, 2001 at 10:55:02 AM EST

    I've programmed both C# and Objective C looking for exactly what you're talking about: C but OO and preferably in a nice way :). And to me it's a clearcut case, nothing to discuss. C# wins big time; It's easier to code, easier to read and has a ton more things in it's standard library. Objective C still feels like something of a hack, but that could be just my opinion. The only thing wrong with C# is of course that at the moment it's very platform specific.

    --

    What's In A Language? (4.80 / 5) (#68)
    by jd on Tue Apr 10, 2001 at 09:50:09 AM EST

    Ignoring the obviously-misleading title (no doubt a cunning ploy to get people to read the article before posting :), let's stop for a moment to examine the nature of computer languages:

    • First Generation - binary programming. Nuff said.
    • Second Generation - low-level human-readable code. Includes assembly. Early notions of structure and defined types.
    • Third Generation - medium-level (functional) code, where statements were not 1:1 with the machine opcodes. Requires moderately-sophisticated compiler or interpreter. Examples include BCPL, C, Cobol, Fortran.
    • Fourth Generation - high-level code, where statements principly specify the nature of the solution, rather than the implementation of it. Requires a very sophisticated compiler or interpreter, to be effective. Examples include Prolog.
    • Fifth Generation - extremely high-level code, where the code is entirely specification. As yet, there are no compilers capable of processing fifth generation code effectively. Very primitive interpreters for the Z specification language do exist, but this doesn't seem to be an area of active development.

    • Serial Programming - Programs that are designed to be executed one statement at a time, in sequence. Slow, inefficient, but easy to write.
    • Parallel Programming - Programs that are designed to be executed along multiple paths at the same time. May handle single or multiple blocks of data, and single or multiple instructions.

    • Serial Compilers - Compilers which take serial code and generate serial code. The usual, in other words.
    • Parallel Compilers - Compilers which take parallel code and generate serial code for each processor. Occam compilers are of this kind. PARLOG (Parallel Prolog) is another example.
    • Parallelizing Compilers - Compilers which take serial code and generate parallel code, usually for an indeterminate number of processors. An intriguing area of research, which pretty much died off in the 80's. The idea was that compilers would be better-equipt to determine how to balance the tasks, and would allow programmers to write once for many architectures.

    • Functional Logic - Logic in which a function takes in data and produces a result. Data and code are seperate entities, which does permit some degree of generic coding. C is a good example.
    • Object-Oriented Logic - Logic in which the data and operations are tightly-coupled. Generic coding is replaced with polymorphic code and function overloading. An example would be Smalltalk.
    • Object-Based Logic - A hybrid of Functional Logic and Object-Oriented Logic. Probably the only area of Obect Logic under any kind of serious development. C++ and Java fall into this category.

    Ok, pens down. Now, can anyone tell me why C is still used?

    (A hand is raised) "Because C is the most advanced language that has any serious work being done on it?"

    Correct! Fourth and Fifth Generation Languages =should= be on-par with C, in terms of speed, by now. Sixth, maybe even Seventh Generation Languages, providing ever-more powerful tools to the coder, should be starting to enter the marketplace.

    They aren't. What's happening is that most of the work is going into providing libraries such as PVM and MPI, or into providing OS-level solutions to high-level problems (eg: MOSIX). Third Generation languages are subverting the benefits of higher-level languages, making more complex compilers and sophisticated languages unnecessary.

    To make things worse for the cutting-edge folk, serial processors (such as the 80x86/7) have virtually wiped out parallel processors (such as the transputer). Serial logic runs best on Serial Processors, making any other kind of logic pointless.

    Further, Functional Logic will always run best on Functional Processors. Object-Oriented code needs to be compiled across paradigms, which inevitably reduces its efficiency. Hybrid Object-Based code can be made to run almost as fast as pure functional code, but there will always be a penalty whenever objects are utilized.

    Lastly, slow busses, slow memory and slow networking severely penalize any code that can't be handled one instruction & one unit of data at a time. Caches don't help, with high-level logic, although they do boost the speed of lower-level code. This further deters any real development outside of the 3rd generation.

    Now, is this a bad thing? Not necessarily. C is proving to be a powerful tool, and C compilers are becoming extremely good at generating machine-level code from C source. With no need of higher-level code, a mix of third generation languages may well be all anyone needs.

    This topic is (1.00 / 1) (#78)
    by Ian A on Wed Apr 11, 2001 at 08:59:11 PM EST

    just a big ol' troll. Didn't anyone else realize that, especially considering the title of it does not match what is presented in any way,shape, or form?

    [ Parent ]
    Don't get me wrong (4.00 / 5) (#69)
    by Bob Abooey on Tue Apr 10, 2001 at 10:48:51 AM EST

    I love watching a good Internet flamefest as much as the next guy... but I have to wonder what it is about techies that makes them so eager to jump into a battle of opinions. Do you think carpenters spend time debating about wether a flathead screwdriver is better than a phillips ? (Obviously the flathead) Or is it because of the nature of the beast of technology?


    -------
    Comments on politics from a man whose life seems to revolve around his lunch menu just do not hold weight. - Casioitan
    It's no contest... (none / 0) (#87)
    by Woodblock on Thu Apr 12, 2001 at 10:17:46 PM EST

    Robertson wins hands down.
    -- Real computer scientists don't use computers.
    [ Parent ]
    You bet they do. (none / 0) (#92)
    by janpod66 on Fri Apr 13, 2001 at 03:58:23 PM EST

    Skilled craftsmen frequently discuss what may seem to outsiders like arcane minutiae. And you know what, in my experience, it is actually valuable and useful to do so.

    [ Parent ]
    very much preferable to GObject (4.00 / 1) (#94)
    by janpod66 on Fri Apr 13, 2001 at 04:07:50 PM EST

    I think Objective-C is a great alternative to homegrown systems like GObject: Objective-C is both simpler and more powerful, and it is mature. It is also as widely available as plain ANSI C because there are simple pre-processor implementations of it (including objc). Objective-C also avoids the complexities and limitations of C++ (C++ is great for other applications, I just don't think it's good for GUI libraries).

    Building all sorts of bizarre "user level" dynamic object systems on top of ANSI C or C++ is penny wise and pound foolish: the end product ends up being much more complex and more difficult to learn than a simple language extension like Objective-C. And it's much more difficult to build tools that work on the user level object systems.

    In the long run, I think plain C-based systems are doomed for anything as complex as a GUI toolkit. And, for slightly different reasons, so are C++ systems. Languages like Objective-C and Java will likely dominate applications development.

    ObjC Bindings (none / 0) (#96)
    by bluesharp on Sat Apr 14, 2001 at 08:58:35 PM EST

    FYI - the GToolkit Objc/GTK binding is still under active development, it just hasn't been updated in the gtk.org archives. The most notable update in the last year or so has been libglade support, which is quite nicely done:

    http://www.informatik.uni-osnabrueck.de/elmar/projects/gtoolkit/

    [Objc retain];

    Is C the last compiled applications language? | 98 comments (77 topical, 21 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!