OT fork(): bloodline and Karlos erm... discuss Objective-C & C++ :)

[Karlos]

@Transition

Best of luck!

@karlos give Objective-C a chance... If this trend continues it will likely be one of the dominant programming languages of the future

I sincerely hope not. It's the nastiest bastardisation of two perfectly reasonable but utterly unrelated syntaxes I've ever seen. It truly deserved to be drowned a birth, but unfortunately we weren't so lucky. The day that particular brand of syntactical lunacy becomes a "dominant programming language" is the day I resurrect my career as a chemist.

But it's not like that, Obj-C sits above the language, it's more a feature of the OS than the language...

It is like that. That mush that disgusted you so much is the language. The fact that you've had to mentally separate the concept from the implementation is a direct consequence of the fact that it has such a failed union of unrelated syntaxes. What you are basically saying is, it's like this "ultra cool OS feature that sits above the language and lets you do cool stuff". Well, sure, it might be like that once you've conditioned yourself into viewing it that way, but it most assuredly isn't that. That would be a custom pre-processor for C provided by the OS. However, Objective-C is not a C preprocessor, it is a language and one that pre-dates apple's interest in it. The fact that you have to view it as a separate entity floating above C "to get it" is precisely what's wrong with it syntactically.

This gives you a lot of very cool runtime features that don't exist in C++... I hope that makes sense

You can pretty much do it all with C++ too if you like. There are perfectly well established extensions and libraries for reflection, AOP etc. And despite not being core language features, they are still nicer to look at than even the cleanest Objective C.

[Karlos]

Actually there is one thing I'm not keen on with C++ (though I also think this is a strength for low level work), is the lack of a base class that all objects inherit from... Shrug...

This is neither a feature nor an oversight, this is C++ as a as-compatible-as-possible superset of C. Remember, C structures and C++ classes are actually entirely the same entity. The only difference between the two is the default access level for members. In classes, they are private unless specified otherwise, in structures, they are public, unless specified otherwise. You wouldn't want your C structures suddenly getting a whole load of unrelated cruft injecting into them, especially when you are likely to be using them directly from OS libraries etc. that were actually written in C and have no idea about this new concept you just shoehorned into the language.

Extending all classes from some abstract "Object" type is a common paradigm in OO languages but don't be fooled into thinking by virtue of the services it provides that it's actually necessary. It isn't. Giving all objects a common interface is handy for languages where gernerics are not a language feature and you want to create general purpose container types and so your base Object class provides useful metadata that the container implementation can use. Smalltalk is an ideal example of this way of doing things and it had been considered a gold standard. However, for languages that support generics, you simply don't need it. I find this much better since a type shouldn't really have to be interfered with (which forcing it to be of some generic base class type does) in order to be put into a generic container. Not doing this leads to absurdities such as having a class Integer which is an object wrapper for the actual elemental type just so you can use it within an existing container scheme. Proper generics don't require this manhandling and invariably give rise to much faster (if sometimes larger) code too. Most operations on std::vector will be entirely inlined. Contrast this with the case when you have an abstract container of (possibly unrelated) abstract types (but all of abstract type Object), everything is going to be as slow as it's possible to be. Even Java realised this at some point and introduced proper generics.

I must admit it wasn't until I discovered that Obj-C was originally a preprocessor for C that I finally got it.

So was "C with Classes", which became the earliest version of C++. However, both became truly compiled languages fairly early on in their development. Whereas C++ reused existing C syntax to implement OO in a comparatively intuitive way (such as allowing structs/classes to have member functions that could be defined inline or in a separate translation unit) that C programmers would "get", the objective C guys just lifted their syntax from Smalltalk without giving any thought to how they might seek implement the features in C and extend C as a language. It doesn't matter that the design aims of each language were different, the Objective-C designers could have implemented it's OO extensions with a sensible C-like syntax too. They chose not to.

Don't hate Obj-C just because it's different

I don't hate it because it's different. I actually liked Smalltalk, it's what got me into OO in the first place. I hate Objective-C because it's just thoroughly awful as a language. I don't deny that it has some desirable features such as dynamically loadable classes etc, but IMHO it takes far more away from you than it gives. And what it does give, you can usually find ways to achieve the same end in other languages.

[Karlos]

I'm sure the old dears coming in for their incontinence pads and Viagra prescriptions will love to chit chat with you about the beauty of hand optimized 68k assembly.

I said chemist, not pharmacist :lol:

Wait, old dears coming in for viagra? :nervous:

You should all stick with 68k Assembler, neater, smaller, faster code...

One of my perverse habits is using inlined assembler in ANSI C++ mode on the amiga. You haven't lived until you've written a set of inline template functions inside a namespace that emit optimal bitwise rotate operations based on whether or not the size of the shift is known to be a compile time constant or not :lol:
Another amusing use of assembler was to (ab)use the CPU exception processing mechanism such that C++ exceptions are thrown for things like divide by zero Much to my surprise, it actually worked rather well.

[Karlos]

Oooh, Hates such a strong word...

Not sure it is strong enough in this context

But glad a mods said it...

Cos now I can say I HATE all forms of   'C'... 68k Forever... :roflmao:

But you're not a mod What's the point in being a mod if we can't say and do stuff proscribed to you unruly rabble :lol: jk...

68K is just about the nicest assembler syntax ever. ARM is pretty nice too.

Anyway, whatever your feelings for it's offshoots, you aren't entitled to hate C itself as there'd be virtually no AmigaOS left for you to write your 68K code on without it ;-)

[Karlos]

Yeah, I still have to explain that one to people... My degree was CHEMISTRY not pharmacy...

For God's sake, Jim, I'm a chemist, not a forklift!

@karlos your diatribe shakes my confidence in Obj-C, but I honestly couldn't really imagine doing another large high level project in anything but Obj-C... Then again I couldn't even begin to imagine how bloated and inefficient doing Microcontroller work would be in anything but C++... As my (disgustingly successful developer friend once said), you just pick the right tool for the right job!

Hmmm, as once last shout for Obj-C... I think in numbing I see is as BOOPSI done right...

Don't let me put you off. Programming language preferences are personal things. There's plenty to dislike in any language if you prefer a different one. I like C++ because it basically gives me the tools to write code from very simple procedural C-style stuff right up to full blown OO/generics with meta-programming and all that jazz. Consequently, it pretty much always feels like the right tool for the job for me. Even the simplest stuff you'd normally do in vanilla C I still tend compile in strict C++ mode.

The problem I have is Karlos's objections are well founded, but I feel he is coming at Obj-C from the wrong angle

If it helps, I disliked it long before apple got their mits on it

[Karlos]

Man, we've gotten so far off-topic. I'm actually considering moving half of this to a developer discussion thread

[Karlos]

Done. Have to say, vbulletin has some nice features for this sort of thing

[Karlos]

Hmmm, as once last shout for Obj-C... I think in numbing I see is as BOOPSI done right...

Actually, BOOPSI is a bug bear of mine too. Love the concept, dislike the implementation.

I don't think the potential for this has been explored but when OS4 introduced it's "Interface" concept for libraries, it occurred to me that the mechanism could be used to produce a GUI engine somewhat more efficient than BOOPSI.

To quickly recap, an Interface is simply a C structure with instance data and a set of function pointers that, through a custom __attribute__ get a pointer to the instance passed as the first parameter (Self, in a small nod to smalltalk perhaps?) and thus behaves as a method that can act on that instance.

So far, AFAIK, it has been used solely for making shared libraries, but fundamentally, the interface is a first class object which can be cloned and modified. I've often wondered whether or not a suitably designed Interface could be used as a runtime extensible GUI element.

If so, an Interface call is rather more efficient than a BOOPSI method dispach and has a syntax (InterfaceInstance->Method())  that's a bit nicer for OO developers too.

[Karlos]

Let's heat it up a little!

@Karlos

Please tell us your thoughts on Objective-C++

Not even Objective-C fans like Objective-C++. I suppose it has advantages of both but there's no actual overlap in the OO services from Objective-C and those provided by C++.

[Karlos]

@ Karlos

Ahh... the perks of being a mod... you get to fork something... :lol:

I wouldn't normally bother, but it was an announcement thread and very off-topic

[Karlos]

C++ is pretty cool.

It's one of those languages I find you learn in layers, each one revealed by some new problem you come up against.

First of all, you start of writing what is ostensibly C and perhaps the only features you use are the streams for input and output (though personally I prefer C-style IO and almost always use it in preference). Then you create your first simple classes, and eventually they get more complex as you start introducing inheritance. You start to discover design patterns and how to implement them. You get better at sorting concepts into concrete and abstract classes and so on.

At some point, you invariably come up with generalized ideas for code that works with objects of different types and you suddenly realise what C++ templates can do for you and then what the STL has already done for you. Your code gets bigger and you realise what namespaces are for.

And, just like the STL, after some time, you start looking at 3rd party libraries like boost and realising that some very clever people have done some excellent work so that you don't have to. Although personally, I quite like doing the implementation work, I find it relaxing

[Karlos]

Drat!

Maybe I should have asked for your thoughts on Java. :lol:

Java was and is a nice idea. It's somewhat failed to live up to it's potential however.

I do remember a fun discussion with some Java purists that really hated C++ due to the misuse some of it's features can be put to and that such things had no place in a "clean" language. At one point, they went on and on about why operator overloading was the work of satan and no language should ever have it. My pointing out that Java's StringBuffer overrides operator+() for concatenation didn't seem to go down well. Special case this, exception the other. Enforce a rule or don't.

Amusingly, one of their other objections (at the time) was that C++ template syntax was so evil that generics might as well not be a language feature since nobody would ever use it (despite the fact that STL is built from it). I had to smile when Java finally introduced generics. The syntax is practically identical. As it was in C# too

Other aspects of Java I don't like are the lack of support for efficient concrete types (all non-static class functions behave like C++ virtual functions), though in some respects this is less of an issue for a language that is JIT compiled from bytecode, since the extra indirection can often be eliminated at JIT time. I'm also not a big fan of garbage collection but it certainly has it's place in larger systems. I also miss features like multiple inheritance, operator overloading and friend relationships between classes, but SringBuffer+ caveat aside, the features they chose have been largely well-implemented. Syntactically I can't say I have any major objection to Java.