Ruby vs Java vs c++

My advice:

Learn C++ but ignore/avoid these parts of the language:

- friend functions
- multiple inheritance
- operator overloading
- function pointers
- nested classes

Learn the fundamental concepts of object-oriented programming.
Understand pointers (critical for 1st time programmers).

Once you have a good feel for C++, I'd recommend moving to Java, C#, or Ruby.

Most everything I do is in C++, but that's because I'm a component developer.
If I were building apps heavy in database and GUI, I would *not* choose C++.

-Matt

···

At 05:40 PM 11/18/2006, you wrote:

hi, newbie so please be tolerant.... :wink:

i need to start to learn a programming language to be able to develop
custom aps to be applied to a variety of purposes but mainly 1) financial
data modeling--including graphics and data handling via database queries,
etc.; and 2) more general business-type aps.

my feeling is that i hate BLOATED sluggish programs (like some Java
program running on older JVM's and perhaps not written in an optimal
way....u get the idea.)

if i need to make a choice between fancy and efficient,
speed, etc., then it's an easy choice 4 me of efficient.
which is why i have just started w/ c++.

however, speaking to one my programmer friends who is a top level Java
programmer (the stuff he writes is very efficient and fancy as
well--great balance), he is telling me that 1) c++ is being phased out
(except 4 real low level stuff like drivers, etc.) in favor of languages
such as Java or Ruby. he recommends i switch from learning c++ to learning
Java or Ruby. i wd hope to be able to choose the best path and not have to
switch tack in the middle as my IT capablity is not a full time activity,
but more of a support 4 my main one--finance.

of course, learning curve is to be taken into consideration as well....

'd love some comments that might help me consider my options and pick a
path (c++, java or ruby) w/ a higher level of confidence..... i know that
people here will be biased towards Ruby, but that is fine: i want to hear
about it....

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.7/537 - Release Date: 11/17/2006

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.7/537 - Release Date: 11/17/2006

Chilkat Software wrote:

- multiple inheritance

C++ mixins anyone? Multiple inheritance with data is evil, but as long
as you only implement pure interfaces or mixins with it, it's
acceptable. It's not like a language should restrict its users with
regards to how horribly they can break the code (and brains) of other
people reusing their creations, eh?

- operator overloading

Except for contexts where the -semantics- of the operator isn't being
overloaded, just implemented for a case the language doesn't natively
supported. Matrix multiplication -is- multiplication and a fine use
case, using, oh, shall we say, << for something that's not a bitshift,
like pushing data into an array or a stream (which some C++ texts
ironically discourage) is indeed bad.

*runs for the hills - FAST*

David Vallner
Meditating upon Pots and Kettles

David Vallner wrote:

Chilkat Software wrote:
  

- multiple inheritance
    
C++ mixins anyone? Multiple inheritance with data is evil, but as long
as you only implement pure interfaces or mixins with it, it's
acceptable. It's not like a language should restrict its users with
regards to how horribly they can break the code (and brains) of other
people reusing their creations, eh?

When multiple inheritance is done properly, it's not terrible at all. I point you to Eiffel circa 1995. They had problems, but it WASN'T multiple inheritance. That was one of their strong points. (Not claiming that C++'s multiple inheritance is good. I don't know it, and nobody seems to have anything good to say about it.) Also consider Python's multiple inheritance. No problems there!!

- operator overloading
    
Except for contexts where the -semantics- of the operator isn't being
overloaded, just implemented for a case the language doesn't natively
supported. Matrix multiplication -is- multiplication and a fine use
case, using, oh, shall we say, << for something that's not a bitshift,
like pushing data into an array or a stream (which some C++ texts
ironically discourage) is indeed bad.

*runs for the hills - FAST*

David Vallner
Meditating upon Pots and Kettles

Operator redefinition can be seriously abused. It's also something that's very powerful when done correctly. I can see an argument for requiring that the *standard* operators not be redefined. This doesn't mean that there shouldn't be user defined operators that CAN be treated just as any other (virtual) function. Perhaps a requirement like "A user operator must begin with a '|' character and contain no whitespace in it's name. It may contain any other non-control character, and must be delimited by whitespace." would suffice.

Charles D Hixson wrote:

Operator redefinition can be seriously abused. It's also something that's very powerful when done correctly. I can see an argument for requiring that the *standard* operators not be redefined. This doesn't mean that there shouldn't be user defined operators that CAN be treated just as any other (virtual) function. Perhaps a requirement like "A user operator must begin with a '|' character and contain no whitespace in it's name. It may contain any other non-control character, and must be delimited by whitespace." would suffice.

Bah! Double Bah! Triple Bah!

1. Every programmer is entitled to define his or her very own personal programming language using whatever syntax and semantics makes the job easy. As long as it's simply a dialogue between one programmer and one machine, who else cares?

2. *However*, the minute a second programmer, a manager, a user, or another machine enters the picture, that programmer needs to communicate with more entities, thus requiring a standardized language *and* a meta-language for communicating about the language.

3. Programming languages evolved from symbolic logic, algebra and English, at least here in the USA and in the United Kingdom, where the initial development was begun during WW II and the early years of the Cold War. (No, I haven't forgotten about Konrad Zuse or the early Russian computers -- they just didn't have much influence on programming languages).

C++ has *way* too many features, both syntactic and semantic, to be of much use to me. Sure, any programmer can work in a readable subset of C++, but most don't. Most have their own team dialect of C++. As far as I'm concerned, there's only one usable dialect of C++ -- ANSI C. :slight_smile:

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

M. Edward (Ed) Borasky wrote:

Charles D Hixson wrote:

Operator redefinition can be seriously abused. It's also something that's very powerful when done correctly. I can see an argument for requiring that the *standard* operators not be redefined. This doesn't mean that there shouldn't be user defined operators that CAN be treated just as any other (virtual) function. Perhaps a requirement like "A user operator must begin with a '|' character and contain no whitespace in it's name. It may contain any other non-control character, and must be delimited by whitespace." would suffice.

Bah! Double Bah! Triple Bah!

1. Every programmer is entitled to define his or her very own personal programming language using whatever syntax and semantics makes the job easy. As long as it's simply a dialogue between one programmer and one machine, who else cares?

2. *However*, the minute a second programmer, a manager, a user, or another machine enters the picture, that programmer needs to communicate with more entities, thus requiring a standardized language *and* a meta-language for communicating about the language.

3. Programming languages evolved from symbolic logic, algebra and English, at least here in the USA and in the United Kingdom, where the initial development was begun during WW II and the early years of the Cold War. (No, I haven't forgotten about Konrad Zuse or the early Russian computers -- they just didn't have much influence on programming languages).

C++ has *way* too many features, both syntactic and semantic, to be of much use to me. Sure, any programmer can work in a readable subset of C++, but most don't. Most have their own team dialect of C++. As far as I'm concerned, there's only one usable dialect of C++ -- ANSI C. :slight_smile:

You are thinking about C++. I am thinking about Eiffel and Ada and Python. C++ got LOTS of things wrong, and only became popular because it was an effortless transition from C. You are taking a warning from C++. I am taking a warning from Algol98. There's lots of ways to design something improperly. Just because one of them is selected doesn't mean the basic idea is wrong. (C++ also gave multiple inheritance a bad name. Eiffel proved that the bad name wasn't justified.)

Mind you, every language has it's warts. More important than allowing liberal operator redefinition I believe would be the optional inclusion of function name on the matching end statement. This would allow many errors to be localized. Think of it as a "compiler hint".

NOTE: an operator *IS* a function. If you are against user defined operators, then for consistency you should be against user defined functions. I really doubt that you are going to pick that choice.

P.S.: I think that the way Python defines operators works well for the "built in" operators, but I'm not sure that it's appropriate for generalized user defined operators. The form I used in Eiffel was to precede and follow the operator name with a pipe character, thus: |*| for matrix multiplication. Eiffel allows(allowed?) this form, but doesn't encourage it.