Ask Slashdot: Which Classic OOP Compiled Language: Objective-C Or C++?

Qbertino writes: I've been trying to pick up a classic, object-oriented, compiled language since the early 90s, but have never gotten around to it. C++ was always on my radar, but I'm a little torn to-and-fro with Objective-C. Objective-C is the obvious choice if you also want to make money developing for Mac OS X, but for the stuff I want to do, both languages would suffice on all platforms. I do want to start out on x86 Linux, though, and also use it as my main development platform. Yes, I know quite a few other languages, but I want to get into a widespread compiled language that has good ties into FOSS. Both Objective-C and C++ fit that bill. What do you recommend? How do these two programming languages compare with each other, and how easy is cross-platform development in either? (Primarily GUI-free, "headless" applications.)

Comments

Objective C

[xx_chris]

I hate C++. It's the triumph of syntax over clarity. The only thing it brought to the game was a better commenting method. I can't read a page of C++ without referring to something. I've never seen clear clean C++. I'd never willfully write in C++. Objective C is a measured improvement over C and I vacillate between obj C and GCC. Would that Swift were more like obj C and less like C++.

Re:C++ is the only logically option

[antifoidulus]

Which is actually kind of sad, as an object oriented superset of C Objective-C is much much better than C++(for starters it's an actual superset of C, unlike C++). However it never gained any traction outside of the Apple ecosystem.

Re:Java

[bobbied]

I don't expect any contrary opinions here on /.

(Oh you ARE sarcastic....)

Java is not the Swiss Army knife of programming languages... There are things it just isn't well suited for... But generally, not a bad choice for most run of the mill projects where performance and foot print don't really matter. However, if you are on limited hardware or have tight response time constraints, Java is not for you (but you hardware and embedded guys know this already.)

Who cares

[Anonymous Coward]

I don't get the whole debate. Programming is independent of language any good programmer should be able to learn a new language in a few days. In my career I've developed applications in four different assembly languages, java, Pascal, C++, basic, etc. It's just a matter of reviewing the syntax and doing the same things in slightly different ways.

Re: Classic?

[Em Adespoton]

Indeed -- learn LISP. Lambda variables, recursion, all atoms being true objects. Then you can redefine the language to pretend to be any of the other HLLs out there.

Problem is, all the lessons that were learned with LISP have since been forgotten and are doomed to be made again and again.

Re:C++ is probably a little bit better

[Required Snark]

C++11 seems to be somewhat useable. However, before that it was a complete disaster. Every time I looked at it, I saw code bases that endlessly re-implemented data structures and storage management solutions.

Even with the standard libraries, there were rarely systems without a lot of custom storage code. By it's own claimed abilities for code reuse, C++ was a failure before C++11.

Every time I brought this up, the C++ fanboys had a fit. I'm rather sure that I was forced out of some jobs because I said this. I know I didn't get hired when I expressed this opinion. I think I was better off not going to those places.

So now I'm going to make the same mistake again. If we take Stroustrup's publication of The C++ Programming Language in 1985 as the start of the ongoing C++ era, then it took over 25 years for the language to become somewhat OK. I can only come to the conclusion that C++ itself was a badly designed language, and this is proven by the time that it has taken to reach it's current state.

In my estimation, C++ was never a good idea. Even though it has improved significantly, it will always be crippled by it's basic design flaws. It is overly complex. It has a vast number of interacting corner conditions that interact in strange ways and can produce bizarre side effects. These have increased over time.

The object model creates problems and you always end up programming around it. Refactoring is invariably difficult; that's where the phrase "brittle objects" comes from. Object encapsulation works poorly. Changing the internal workings of an object is very likely to propagate outside the object. No matter how much precoding design occurs, you will always be modifying objects in ways that required a large amount of code changes in a great number of files. All of this requires a lot of testing.

Debugging has always been a problem. One of the other posts here suggested using CLANG because of it's better error reporting. Thats right now, after 25 years. Let's face it, C++ is legendary for the obscurity of it's compile and link time error reporting. Beyond that, it's not like the run time debugging environment is any better. All that it supports is the kind of break point debugging that was in C. No value added beyond K&R.

So flame away, fanboys. I'm used to it. The truth hurts, and the more squealing I get, the more I know that I am saying the truth.