A Modest Proposal

Posted 9 Apr 2001 at 04:24 UTC by dto Share This

How Gnomers might save some time (and carpal tunnels) by seeing that

C language + GObject == GNU Objective-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."


Why C?, posted 9 Apr 2001 at 06:57 UTC by moshez » (Master)

GTK+/GNOME object system is written in a type-system declared on top of C, which was especially designed to be wrappable. What this means is that unless you are adding new widgets (and most applications are not just adding new widgets) you can code the high-level logic in a higher level language like Python, Perl, Ruby or Guile and have a lot of clarity. This is one of the basic design goals of GTK+, and it achieves it admirably. If you are doing so much coding in C that the clunky calling convention is bothering you, then I think you are using the wrong language for the job.

Note that even if you are adding a new widget with a lot of logic, you can still use Python or Perl by embedding the libraries into your widget, and only using C for the GTK+ interface.

Gnomers don't want to save time, posted 9 Apr 2001 at 08:44 UTC by aaronl » (Master)

If they did, they wouldn't be cloning Microsoft Windows.

Time for a new language, posted 9 Apr 2001 at 12:48 UTC by etoffi » (Apprentice)

Sure it'll never happen . But maybe it might be time for a new language...

Or maybe I should say "Sure it'll never happen, until Microsoft does it." C-Sharp would seem to be a merger of Java and C++. Certainly the GNU project has members with enough expertise to modify a C compiler to provide some of this functionality!

Someone above (I'm not pressing back =P) mentioned C with classes. How hard is that to integrate? It can even be aded with a preprocessor, so that the compiler doesnt have to be modified...

My basic point is that the free software community should think about moving away from C (and not even consier C++), and into something simpler, without all the stupid quirks we have been putting up with for years. How about even working on a Python compiler?

BTW: I use Eiffel. It's not perfect, but it's nice, and far more importantly, clean.

not just me :-(, posted 9 Apr 2001 at 15:50 UTC by dto » (Journeyer)

moshez:
This is one of the basic design goals of GTK+, and it achieves it admirably. If you are doing so much coding in C that the clunky calling convention is bothering you, then I think you are using the wrong language for the job.

This is exactly what I'm saying! Most GTK+ application development is done in C. It is not just me that could be using a better language, I think many of us are putting up with "the wrong language" simply because it's the one everyone else uses to do GTK applications. I understand and believe in the language-independence goals of GTK+, but until significant groups using other languages come up and organize themselves, then there will still be awkward choices between competing bindings for your given language and there will still be the danger that bindings could fall out of maintenance and break applications.

etoffi:

Certainly the GNU project has members with enough expertise to modify a C compiler to provide some of this functionality!

Someone above (I'm not pressing back =P) mentioned C with classes. How hard is that to integrate? It can even be aded with a preprocessor, so that the compiler doesnt have to be modified...

Now assuming this is what we want to do, it is already done. You can even pretend objective-C is a C preprocessor plus runtime library (which probably isn't far from the truth.) My point is that it exists now, already has support across the GNU development toolset (GCC, Gnustep stuff), is not linux specific (re: Apple and other communities), has been used on real projects. And on a GNU system, your chance of having the GNU objc stuff and GCC installed actually seems a bit better than writing it in Ruby or maybe even Python. I think the use of Objc would restrict the audience less than those, even for compilation.

The idea of creating a new C variant and writing all the code for it and changing compilers does not seem better than using what exists, especially if what we ended up getting was a very static object system influenced by C++. As long as we're building from GTK+, we could use a dynamic system more like the one it does.

Time for a new language, posted 9 Apr 2001 at 17:06 UTC by uweo » (Journeyer)

No, it's not the time for a new language.

And it will not be the time for a new language for some years.

It's time to think about things.
There has been a new hype language every year or two. There's been a new GUI toolkit every year or two. All kinds of shiny new stuff ... every year or two. But nothing really changed or is likely to change - most applications still are garbage and will be garbage for a long, long time.

I don't underestimate the value of good tools and the right languages. They are crucial for getting excellent results.
But so is a good design, good coding and good quality assurance, not to mention good internal documentation. They are crucial and rare, and that isn't likely to change soon.

Of the last 25 problems in ftpcopy:

  • 16 could have been detected by a testsuite (more than 50% of these bugs broken formerly working code).
  • 15 involved haste and hurry or lack of thinking.
  • 7 were design problems, could have been avoided during the design phase.
  • 2 wouldn't have happened if the language hadn't been C.
  • 2 were unexpected surprises in the user interface.
  • 1 (each) was a
    • typo .
    • misunderstanding of a library function.
    • workaround for a ftp server bug.
    • portability problem.

That's although a larger number of problem was found during testing ...
And this statistic is for a relatively simple command line utility. I'm not too proud of it, of course.
The ChangeLog files of other free software projects show about the same picture, and and my experience with closed source software development isn't any better.

Software quality isn't rarely a question of tools or languages but more of a good design, good coding and good testing and even more testing.

btw: I've got that lesson before, more than once. It's too easy to forget and fall back into bad habits.

Objective-C support for Gnome, posted 9 Apr 2001 at 17:08 UTC by Ankh » (Master)

If typing out long variables is a problem, get an editor with word completion. Code is written once, then read and edited many times.

Objective C is (or was) interesting. Maybe you should consider joining the gnome language bindings effort to help add Objective C support. (James H. tells me there are already Obj-C bindings, but they are not up to date.)

the speed limit of dynamic method binding, posted 9 Apr 2001 at 19:44 UTC by sej » (Master)

Don't forget that any approach to dynamic method binding at run-time will always be slower by a factor of 2 to 3 over a binding strategy that resolves the proper method at compile/link time. There is no way to alleviate this difference between C/C++ and languages like CLOS, Smalltalk, Java, Objective-C, etc.. There is nothing faster than an indirect function call from a static table of function pointers.

If speed matters, it seems you have three choices: C with home-built, non-standard management of function pointers (something I like), C++ with voluntary restrictions on using the more byzantine features (something I like as well, no offense intended to those with Byzantium ancestry), or the bleeding edge of ANSI C++ in its many incarnations.

Or I guess C# is an option. But I don't need Microsoft telling me how to behave as a programmer. Do you?

GOB, posted 9 Apr 2001 at 19:58 UTC by yakk » (Master)

I've been using GOB for a bunch of the hacking I've been doing (on a download manager for GNOME). Its a really really nice way of writing GObjects. Its especially nice if you have CORBA GObject bindings...

Byzantium , posted 9 Apr 2001 at 21:29 UTC by atai » (Journeyer)

Just to clarify things, the name "Byzantium" is an incorrect name used by the Western Europeans. The real "Byzantium" called themselves Romans, not Byzantines...

dynamic method binding, posted 9 Apr 2001 at 22:33 UTC by dto » (Journeyer)

There is no way to alleviate this difference between C/C++ and languages like CLOS, Smalltalk, Java, Objective-C, etc.. There is nothing faster than an indirect function call from a static table of function pointers.</b>

For what it's worth, you can code parts of the application as ordinary C functions (direct call, no table even!). Like C++, Objective C allows all the old stuff to work. So if you have a method that is supposed to do some heavy computation, you could write its subroutines in plain C for speed of calling convention. For parts that are less demanding, I doubt the method calls would hurt too badly.

Any GNUstep folks with experience on this?

C++..., posted 10 Apr 2001 at 00:49 UTC by tja » (Journeyer)

No-one else seems to want to say this, but someone has to :-). Why not C++? It has all the advantages, the lack of which is bemoaned in the article. It is well-established, standardized, has a large number of skillful practitioners...

I should learn more about the GObject notion before passing judgement, but I'll do so anyway, and probably regret it - what's the point of twisting C to provide the benefits of C++, when C++ already exists? Is it really so difficult to use productively?

Re: dynamic method binding, posted 10 Apr 2001 at 01:07 UTC by sej » (Master)

For what it's worth, you can code parts of the application as ordinary C functions (direct call, no table even!).

Yes, and this is equally true for Python or Tcl as demonstrated by drawing editors like Sketch and Impress.

C++..., posted 10 Apr 2001 at 01:08 UTC by tja » (Journeyer)

No-one else seems to want to say this, but someone has to :-). Why not C++? It has all the advantages, the lack of which is bemoaned in the article. It is well-established, standardized, has a large number of skillful practitioners...

I should learn more about the GObject notion before passing judgement, but I'll do so anyway, and probably regret it - what's the point of twisting C to provide the benefits of C++, when C++ already exists? Is it really so difficult to use productively?

Re: Why C?, posted 10 Apr 2001 at 02:49 UTC by jgg » (Master)

Bah, there is nothing magical about C that makes it easy to wrap, and the GTK scheme isn't particularly so in the grand scheme of things anyhow. The value is really in the ABI (application binary interface).

IBM probably had the right idea with their SOM setup. Their object model originated in C, but was a defined *ABI* rather than just a bunch of macros. The resulting binary actually had properties that allowed a client (such as REXX) to open the dll and just start creating objects and calling methods willy nilly. No special bindings. They did their CORBA implementation (DSOM) the same way too.

What IBM did when C++ came along was to just make the compiler emit code that was compatible with the SOM ABI, if you wanted. It is slower than normal C++ code of course, but the fact that your C++ program was interacting with, and originating fully functional SOM objects was hidden. They also had a set of macros not terribly unlike the GTK ones for C programmers.

This was such a good idea beacause it freed people from working with the ugly C macros and let them write significantly nicer C++ code. I suspect that Objective-C would have been just as good a candidate, since I think it's object model is closer to SOM anyhow.

The SOM model let any language capable of producing runnable machine code (I forget, but I think you could make ObjectREXX SOM objects, but you couldn't put those in a DLL that easially) create and consume objects constructed by any other language. Thats a tad better than 'Write in C and have limited utility from any other language'

Anyhow, if you want to improve things with the GObject stuff, I'd say get them to write down, and stick to, a binary ABI that was at least as featureful as what IBM had with SOM, then just make your objective C compiler target that ABI.

C versus C++ debate, short version, posted 10 Apr 2001 at 04:55 UTC by dto » (Journeyer)

  • Why not?
  • It's too big and too complicated.
  • You can just use the parts you need.
  • But no two projects use the same "just the parts they need".
  • But it was designed to let you use just the parts you need on purpose.
  • So? Everyone choosing their own dialect still does not work.
  • But it has everything you want in the language.
  • I did not tell you what I want from the language yet.
  • It still has it. Go on, throw something at me.
  • I want a particular kind of FOOBAR.
  • We have FOOBAR.
  • Yes but it doesn't do QUUX. Moreover, 130 pages in the Standard are devoted to the questionable parts of the language that would be completely unneccessary if your FOOBAR actually did QUUX.
  • You're only supposed to pay for it if you use it.
  • Believe me, in fifteen years, somebody is going to pay for when you used it.
  • I am starting to think you don't understand C++ and object-orientation.
  • No, I used C++ for several ye---
  • To understand the collective is to love the collective. And you obviously do not love our beautiful cortex-hive. If you'll just let me cut out this part of your brain...
    ...
    ...
  • We are borg. I will immediately buy 38 copies each of "Design Patterns" and "Dianetics".
  • That's better. See how much easier it is to only use the parts that you need?

[this is, btw, a joke]

An auxiliary object model, posted 10 Apr 2001 at 17:27 UTC by exa » (Master)

makes sense only for languages that *doesn't* have it. Like C. So if you're developing in C++, you must *not* use an auxiliary object system if possible. If you're using a class-based language, then use _its_ classes.

This means that if you are using a language like Objective-C, but having to invoke an auxiliary object system, or use wrappers that are inefficient... something's wrong. In fact, I kind of liked the gtk C-- wrapper when I first used it. But then I saw that it was half-done, and I had to abandon it.

One of the great things about GUI coding is that OOP fits _extremeley_ well in the picture. You have models, views, controllers, messages being passed around, inheritance, components... Everything seems very good. But then if you are having to write a lot of redundant and repetitive code to get a single window on the screen, then it's not your mistake. If I'm using C++ bindings, it should feel like C++, and the code must be short. I should be able to use genericity, multiple inheritance, exceptions, and see that they help me do my work easier.

Well, I don't want to say it, but when I last booted into KDE from my GDM I saw a really neat file and web browser, which was _fast_ and robust. Maybe the gnome guys are not going the right route... As someone said, they are only interested in more bloat that they imitate from MS products.

Why not C++? I'll tell you why not..., posted 11 Apr 2001 at 11:09 UTC by glyph » (Master)

For starters --

  • unpredictable name-mangling (no ABI)
  • fragile base classes (no interface specifications without implementation details)
  • no reflection (object orientation is a language feature, but high-level programming is not)

The upshot of this stuff is that writing code to load plugins for a program is nigh impossible (and writing libraries is highly fragile). I can hear the wailing already from the C++ fans -- "But don't COM and KParts let us do that?". Yes, they do; but they do it by lots of wacky tricks, most of which involve 'extern "C" {'.

In Objective C/Smalltalk/Java/Lisp/Python/Scheme/caml/[insert your favorite actually sane language here] such hackery is not necessary. Even C makes it relatively easy (dlopen). The fact that C++ does not support this should not be worked around: it's an indication of a grievous design flaw in the language at a very basic level. Objective C is far simpler and gives developers what they need.

If my word isn't good enough for you, take a look at an OS based on C++ -- BeOS, Microsoft Windows -- and compare it ton one based on Objective C -- NeXTSTEP^WMac OS X. If you're familiar with the APIs for both (or all three), you already know why Objective C is the right idea :-).

Objective-C _is_ underestimated, posted 11 Apr 2001 at 13:29 UTC by ber » (Master)

Overall I agree with the author of the original article: Objective-C is a very attractive alternative to C with object-orientated extensions. Objective-C is underestimated by the majority.

For more background onObjective-C check Andreas Beyer's page about StatistX which has a lot of interesting links. This includes the link to GToolKit which actually is a more current Objective-C GTK 1.2 wrapper.

Programming has to do with clarity. Objective-C always gave me more clarity then C++. Today I do most development in python. I often hear the argument that Objective-C with the dynamic method lookup and python as "interpreted" language are hit by a performance loss by nature. I regard the additional productivity gain through clarity as being far superior to the performance gains when using something like C. (And for all other situations there are C extension as somebody already pointed out.)

On the technical site there sometimes were some problems with gcc's Objective-C runtime support. There are not as many standard extension library as for python or java. Objective-C is proven for big projects (NeXTStep) though.

re: speed limit of dynamic method binding, posted 11 Apr 2001 at 15:24 UTC by thoran » (Journeyer)

Don't forget that any approach to dynamic method binding at run-time will always be slower by a factor of 2 to 3 over a binding strategy that resolves the proper method at compile/link time.

If you only consider the cost of the dispatch of a message, that's true. On the other hand, programs usually do not limit themselves to dispatch messages to objects. They are believed to do something else.


Thus in everydays programs, the performance lost is less than 10% which is not so important. Don't forget that NeXT computers were 68030 at 25MHz, programmed in pure Objective C. They were running a graphical interface that was quite complex for the epoch.

i'm a bit more pessimistic now, posted 11 Apr 2001 at 15:55 UTC by dto » (Journeyer)

The question isn't really whether it would be convenient to use Objective-C in conjunction with C to automate/tidy up certain tasks. I think it would. But in practical terms there are enormous obstacles to it becoming a viable applications development language. By 'viable' I mean consistent and up-to- date tool support, public and visible community/educational support, and platform support.

Good things:

  • The additional constructs are few, so it's unlikely to break into sub-dialects.
  • GCC and GDB and editors have good support.

Bad things that would be extremely difficult to overcome:

  • Language wars, as always. When I reposted the above story to Kuro5hin, it instantly devolved into a "C++ sucks/rules" argument, even though the article's main point was not about C++. There was virtually no discussion of Objective-C itself (probably because not that many people know about it.)

    In essence we'd be asked to justify to the universe why we do not just use C++/Java/Python/whatever. There's no way to win: you have to either point out a disadvantage of [foo] or point out something you need that [foo] can't give you. Either way it's a language war, and you can't even win that if you stick to C.

  • Worse is Better. A common alternative suggestion to applications programming is to "write most of it in [Foo] and just write optimized C modules for the parts that need it." This argument is enough for most people. Never mind that (1) You have to learn and know [foo] for this to work, (2) you have to manage a multilanguage project and that carries its own productivity drag, (3) studies have shown that programmers are extremely bad at anticipating just what parts of a program will need optimization. It just doesn't matter.

  • Nonportability. It doesn't matter if the minor compatibility problems get fixed. The idea will stay around as if not porting your OpenNap client to some old version of AIX was a pressing problem.

  • The "Amiga Forever" reputation. We've heard for years and years that the Amiga is coming back, and we all know it isn't. It is a self- perpetuating argument, of course, but how are we to convince anyone else that Objective-C even could come back when the maintainer of the "standard" GTK/GNOME bindings says it's dead?

  • NeXTSTEP. The largest coherent community for Objc is focused on platforms that are not growing. Apple is contributing their work on GNU Objective C compiler, but their use of Objc has nothing to do with Gnome or GTK and the stuff is all NeXTSTEP-derived. It may be nice stuff, but it might as well be another planet in developer terms. What's worse, the GNUstep folks do not seem to like Gnome, and think that NeXTSTEP has better chances for long-term success. The fact is that most "universal application frameworks" are rather short-lived unless they are dictated by the operating system (Apple) or by the vendor who makes both the OS and the dev tools (Microsoft.) That is why Taligent is buried right next to NeXT.

It is the classic story of unused languages---technical qualities are nothing in the face of unpopularity and workable alternatives. Without an organized community it may as well be Modula-2. The only way it could succeed would be a lot like the way Perl and friends succeed: a significant and organized group begins publically using the language, educating others, creating community support, and agreeing upon one standardized language binding for each platform (upon which documentation and tutorials could be based.)

I'm all for it, but that doesn't count. I got only one email from someone interested in using Objc. If people want anything to happen there'll have to be organization.

I was an Objective-C junky., posted 11 Apr 2001 at 20:09 UTC by echuck » (Master)

sej:

Don't forget that any approach to dynamic method binding at run-time will always be slower by a factor of 2 to 3 over a binding strategy that resolves the proper method at compile/link time. There is no way to alleviate this difference between C/C++ and languages like CLOS, Smalltalk, Java, Objective-C, etc.. There is nothing faster than an indirect function call from a static table of function pointers.

When talking performance, lumping Smalltalk and Objective-C in the same category is not the way to go. I used Obj-C for 6 years and Smalltalk (ST) for about 1. I found ST to be 1000% slower than optimized C and Obj-C about 10-20%. These numbers are for average programs I encountered.

Objective-C is closer to C++ than any thing else in terms of speed.

Also, someone mentioned that GObjects already had a higher level of dynamic binding than C++. Using C++ to access GObjects isn't going to make that go away.

dto:

For what it's worth, you can code parts of the application as ordinary C functions (direct call, no table even!). Like C++, Objective C allows all the old stuff to work. So if you have a method that is supposed to do some heavy computation, you could write its subroutines in plain C for speed of calling convention. For parts that are less demanding, I doubt the method calls would hurt too badly.

Any GNUstep folks with experience on this?

Well I was a NeXTstep person, but "same difference"... Most of your Objective-C is already ordinary C. All your for(), if(), while(), float, int, arithmetic, pointers, arrays, etc. are vanilla C which gets translated to fast machine code. That's why Objective-C performs so well at run time.

But at the same time, the method binding is fully dynamic which is why it was so easy to learn, use objects, do dynamic things with them, etc.

Note that this flavor of "C integration" is substantially different than other languages like Python. In Obj-C, using C constructs is part of the deal. You never have to "step out of the box" to get it. (Which is good and bad. Good for speed, but occasionally Obj-C apps have the same seg fault/bus error problems that C++ apps do.)

tja:

[in reference to C++] Is it really so difficult to use productively?

In comparison to alternatives such as Objective-C and Python: Yes.

dto:

... We are borg. I will immediately buy 38 copies each of "Design Patterns" and "Dianetics" ...

:-)

==================================================

Glyph had all the right comments about C++, so now I don't have to write them.

Now onto Obj-C. I used it for six years. Loved it. Shoved it at everyone I met. But now it's dead. I even said so in a sidebar for article I wrote for the Linux Journal:

sidebar: Objective-C: I Knew Him Well

article: Using Mix-ins with Python

But they axed my last paragraph in the sidebar:

Having used Objective-C for six years, I can testify that it's still a good language in many ways, but I also know that Python offers more technical advantages and on-going improvements combined with a lively, growing community.

(Is that really too controversial?)

One frustration I did have with Obj-C was that there were never any language improvements. Six years and not a drop.

After I accepted the truth, I tried to move to Java because popularity does have some advantages, but that didn't cut it. I discovered Python and have never looked back.

Python, like all languages, has warts. But the team is active and I get new improvments every year. And it's already better than Obj-C or Java.

So I'm sorry if your thread turned into a language discussion, but in reality Objective-C is dead and Python is at least a good place to start (and possibly your best option).

Friends who know me, believe. They know what an Obj-C nut I was!

:-)

Python not a totally perfect replacement, posted 12 Apr 2001 at 02:22 UTC by jack » (Master)

I love python. I think it's awesome.

But Obj-C code is nearly the same speed as C code, as you pointed out.

Java and Python are still not anywhere close, last I checked. I would love for this not to be true though, so someone please tell me python is super fast :)

A lot of times this isn't an issue, but certain classes of problems are speed concious. For instance, these days you can make Web applciation servers in python, in java, or in C. And it turns out they work pretty damn well in any of the languages speed-of-execution-wise.

But what can I use besides C, to write Icecast in that would have some notion of objects and such? What can I do to avoid the ugly pitfalls that dto mentioned with GTK.

For a lot of things now, I use python. But I still haven't found a way to move from C to anything else.

Valid point, posted 12 Apr 2001 at 12:54 UTC by echuck » (Master)

jack:

... But what can I use besides C, to write Icecast in that would have some notion of objects and such? What can I do to avoid the ugly pitfalls that dto mentioned with GTK. ...

Overall, your point is valid. It is mitigated more often than you might think by the fact that many Python libraries such as file I/O, sockets, GUI, etc. are implemented in C.

But there are certainly examples where that doesn't cut it. For example, I wouldn't write a stock market strategy simulator in Python-- that's too CPU intensive.

And while some might say that I can always fall back to C, that's not only a pain, but I'm not sure how well it works for a "granular class hierarchy". The classic fall-back-to-C-extensions example for Python is the Numerical library where the object of interest is a matrix of densely packed floating point numbers. Obviously that worked out pretty well, but I usually don't have such large chunky objects comprised mostly of atomic data.

Well that settles it: We'll just have to write our own language!

:-)

(Actually, I would if I had the time...)

Gtk+/GNOME Bindings, posted 12 Apr 2001 at 15:38 UTC by sopwith » (Master)

Just for the record, please don't confuse cause & effect here :)

I said the bindings were dead because there is not a huge interest in them, not the other way around.

objective c, eiffel, c-sharp, posted 13 Apr 2001 at 09:11 UTC by etoffi » (Apprentice)

maybe i should just let this die, but ...

i dont see too much of a problem with objective-c. speed is not really an issue, as was mentioned above multiple times. people, we have gigahertz machines! get over it! (i am *not* advocating bloat, but just as an example, how fast does microsoft word load?). nowadays, we are moving towards everything being dynamic anyway (eg: dot-net, mozilla)

only one comment on the new language? i brought it up because then we could start over -- no warts, and GObject could be built in. while we're at it, we could make a c-sharp frontend. just a thought.

anyone looking for a nice language should take a peek at eiffel (http://elj.com)

Re: Why not C++, posted 13 Apr 2001 at 16:57 UTC by sej » (Master)

fragile base classes (no interface specifications without implementation details)

The problem of "fragile base classes" (as defined by Ted Lewis in his book on OO Application Frameworks) disappears if you have access to all the source. The C++ compiler does a marvelous job of "re-manufacturing" your code when the slightest change (new member methods or variables) is made to the most fundamental of your base classes. Unless your missing some source you need to recompile.

Sorry to equate Smalltalk with Objective-C, performance wise, if there is such a huge gap in performance. I was assuming some modern Smalltalk development environment would have a compiler comparable to those you can get for Common LISP or Java.

sorry about ambiguity, posted 14 Apr 2001 at 17:13 UTC by dto » (Journeyer)

sopwith:

Ack, I agree that sounded all wrong. I did not mean to imply that you are the cause of the language being unpopular---what I meant is that it does not sound like it's going anywhere if the official toolkit bindings aren't getting enough user interest. I'll remember to preview once more next time :-)

I still think it could change, but only if a group of people works in unison to improve the situation. It's a big obstacle.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page