Thread: Is C++ getting too complex for today's technology?

  1. #31
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    My guess is you havn't dealt with many C++ programmers. Trust me, not many are competent.
    I've dealt with some very competent people, and seen many incompetent ones. I'll readily concede the point.

    You make a good argument, and I don't completely disagree with it, I just think it is too strong of a statement. My assumption is not that you have hired a set of code monkeys, but rather a fairly competent set of computer science types. Part of the time will be making sure that the developers are proficient enough in the language to work with it and the available tools (if available) to deal with the language; part of the time will be spent finding the neccessary libraries and learning them, assuming they exist. For a large and complex enough application, there may be enough separate modules that could each be done in an optimal language that hiring or training enough developers in the specific languages may be too expensive, too time consuming, or those folks may be too rare.

    There is an additional factor as well. Say there are many competent developers in C/C++/Java/LISP/Ada/etc available, but few in the 'optimal' language. You're company may not be in a position to hire enough people who know that language at the time, and may have to settle (perhaps only temporarily) for a slightly less than optimal solution.

    So, I'm not saying that C++ and its kin are the cure-all. They certainly are not; and there is certainly a lot of code written in those languages for the reasons you mentioned (primarily ignorance). In your example of Erlang, if your company is going to be doing primarily telecomm work, then it'd be foolish to use C++. However, if all you'll ever need is a small telecomm module, and competent C++ programmer may be able to design and develop such a module in C++ that is extensible, maintainable, etc in less time than he'd take to learn the new language.

    As for the matter of the open source team, I completely agree. If you're just doing it because you want to show it to the world and you have (essentially) unlimited time, then yes, do it right.

    There are a few situations in which usign the less optimal language is acceptable. The most immediate one that comes to mind is client specifications. This comes out of the ignorance statment of my previous post. Some clients want their product in a certain language and won't be told no by anyone.
    In summary, I find this too strong of a statement, but not completely unjustified. There are more factors to consider.

    I hope those arguments seem fair and justified.
    By and large, yes, they do seem that way.

    Cheers
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

  2. #32
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    I finally know what language to use... both! It came obvious to what I need to do. If I need to do systems level programming, devices, or performance-critical games, I'll let C++ be the choice. If I need to do GUI/Web/Mobile/Simple 2d to The Sims 2 games, I'll let C# be the choice. It makes sense to me... why limit yourself to one language? Learn them all. See where they are useful, then use it accordingly.

  3. #33
    Registered User
    Join Date
    Sep 2001
    Posts
    4,912
    Either you're serious, or I took this the wrong way. Either way, I felt like sharing this thought. Side wars keep coming up when someone mentions .NET in a Java forum, etc. This is getting rediculous.

    If you're referring to me, I'm a general programmer - I don't take sides. Many people do on forums, and it's really depressing. For instance, your boss wants you to use .NET for a certain project. Are you going to be prepared, or are you going to say, "Ew! .NET. Yucky." What if one of your programmers starts talking about a philosophy on why MS is the devil when you're trying to get a .NET project done? He'd be fired, and he'd end up at a common forum.

    It's true that any programmer prefers a certain language for their personal projects, but it doesn't work like that in the real world, sorry. I enjoy programming, not C++, not .NET., not Java. Just programming If you take sides, you're a fool. Programming is not politics.
    -- dxfoo

    You are a sad, strange little man. You have my pity. Farewell!
    -- Buzz Lightyear

  4. #34
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    dxfoo:
    Why not learn some languages which are actually 'different'. You have C++ and C Suck Suck. Processors are becoming more concurrent, so why not be one step ahead of the gang and learn a concurrent orientated language?
    It's upto you obviously but IMO, expanding a bit past the C-like world would be good and enjoyable. You don't have to becom the best at these other languages, but you should know the basics and some common idioms in them. That way you can decide what language really suits you. For instance, i am quite knowledgable in C, C++, Python and Erlang but i had to dabble in Common Lisp, Assembly x86, Ruby, Perl, Mozart, Scheme, PHP and now SML before I came to these. Although to be fair most of my C and C++ knowledge comes from just not knowing that there was anything out there so had I played with those other languages first I don't think I would have been very interested in learning C and C++.

    But whatever your language choice is, just remember that the language you are using sucks according to someone for some reason regardless of how good the reason is.

  5. #35
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Again orbitz is too extreme for my opinion (especially since C++ does not suck), but he's essentially right. Your CS study years are the ideal time to get to know as many languages possible. I've played with C, C++, JavaScript, Java, C#, Basic, PHP, Perl, Python, Haskell, Assembly (x86 and Alpha) and various others before deciding that C++, Java, PHP and Haskell are my favourites.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #36
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    Orbitz, thanks for the tips. I could write a book on what I plan to do, but I'm just going to stick with what I'm most comfortable with. There's many tools that can be applied to one language, so a focus is always necessary for a while. Thanks.

    dxfoo
    Last edited by dxfoo; 09-10-2005 at 10:58 AM.

  7. #37
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    Well as I said, your language of choice sucks a lot according to someone. In my opinion, C++ is a fairly bad language. It is incredibly large, requires knowing a fair amount of it to complete a relativly small problem, and if you subscribe to the Succinctness Is Power argument by Paul Graham (http://www.paulgraham.com/power.html), C++ fails pretty terribly at this. Solutions are generally not succinct at all.

    Take a simple thing like parametric polymoprhism.

    C++ I get soemthign like:
    Code:
    template <typename A>                                                                                                                                                                                            
    A doubleIt(A a) {                                                                                                                                                                                                
      return a + a;                                                                                                                                                                                                  
    }
    In Erlang I get
    Code:
    doubleIt(x) -> x + x.

    However I suppose this is a losing argument.

    EDIT: Why is this post so darn wide???
    Last edited by orbitz; 09-10-2005 at 06:40 PM.

  8. #38
    C(++)(#)
    Join Date
    Jul 2004
    Posts
    309
    Your argument makes no sense. The language is bad because you have to have knowledge of it in order to use it? How is that bad? It makes perfect sense to me. How can you program without knowing the language you are using to some degree? It isn't like you need to know how to use templates in order to make a Hello World program.
    To code is divine

  9. #39
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Haskell:
    Code:
    doubleIt x = x + x
    I'm aware of the power of functional programming languages and the genericity they often come with. As I said, I've learnt Haskell, and it can do the same. Still, I feel that the functional model is not very well suited to model an application as a whole. But that's a completely different point.

    That C++ is verbose compared to functional programming languages is not a particularly strong argument, either. Paul Graham may argue all he want, but this simplistic view of his essay is a) probably not what he intended and b) wrong. The power of a language is defined by the ease with which you can express your ideas. It's a matter of concepts, not syntax.
    If a language directly supports the way you want to express your ideas, then succinctness is a result. I believe that Paul Graham is confusing cause and effect in his argument. You do not make a language short in order to make it powerful; you make it powerful in order to make it short. Haskell has, as a feature, the automatic deduction of type. This makes it powerful. This also makes your example possible. The terseness is the effect of the feature, an indicator of its power, not the source.

    Does that mean a verbose language is necessarily bad? Graham starts his essay with a statement about Python and infers that Python is a bad language. Now, leaving aside that I strongly dislike Python for its reliance on whitespace (just being on a board like this should show some of the perils of this), does this make Python a bad language compared to similar languages? (That is, object-oriented, weakly typed scripting languages.) No, because Python has the same power - it is equally capable of expressing ideas. Perhaps it takes a little more space to express them, but this rather irrelevant, or even positive if it increases the readability of the language; in other words, the syntax of a language should aim to maximize the speed at which the language can be read by a human, not minimize the number of lines it takes. These goals go hand in hand to a point, because pages and pages of code are hard to take in, but there's a limit.

    It is incredibly large, requires knowing a fair amount of it to complete a relativly small problem
    I'm not quite sure what you mean here. If you say that you need to know a lot of C++ to solve even small problems, then you are somewhat right - but that's irrelevant, because C++ wasn't made to solve only small problems forever. Sooner or later, you'll come across a large problem, and your knowledge will serve you the same.
    The same applies to every other language. The amount of knowledge of a language you have doesn't affect the size of the problem you can solve, merely the efficiency with which you solve it.

    I would also argue that the mere concepts of functional languages, and how they can be applied, are harder to learn than most of C++ as a language, including the object-oriented concepts, simply because the object-oriented model is closer to the way humans think.
    I don't know how Erlang solves the classical sequential execution problem that every functional language faces, but if you actually want to understand the Monad model of Haskell, you do need a Ph.D. The Pointer model is even harder.

    I could probably continue, arguing for example that C++ makes it easier for you to profit from the knowledge of others without having that knowledge yourself, but I think I've said enough for now.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #40
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    You are confused. I said you have to have to know a fair amount of the language to solve relativly simple problems. For instance, you can solve quite complex problems with only knowing a small amount of Common Lisp. The second program in Paradigms in AI Programming is a General Problem Solver and the book is teaching Common Lisp from scratch.

    Take streams in C++ for instance. In order to do much with them one needs to understand references (because they lack a copy constructor). Namespaces, templates (because streams in C++ are templated). operator overloading (How does operator<< work? I thought it was left shift). function overloading (how do you print out a char and an int and get different output even if they rerpesent teh same value). buffering (why does cerr soemtimes print it's output before my cout can). not to mention you have to learn what cout and cin really are. Also the difference between formatted and unformatted input (why does std::getline not work after i use operator>>).
    Here is a nice Hello World: http://jcatki.no-ip.org/fncpp/Hello_World
    That certinaly is quite a bit just to do some streams.

    Does that clear things up?

    Also, I would like to note my Erlang vs C++ example is not quite fair. For starters, it is not quite typesafe, for instance if i pass a type which has no + operator defined for it I won't know until runtime where as a C++ compiler must tell me this at compile time. This would be easily caught by a ML compiler though, and still have the succinct syntax.

  11. #41
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    I understood perfectly well what you said. I just don't think your argument has a real-world application.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #42
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    My previous post was in response to 7smurfs.

    I think this discussion has about reached it's climax. I think we have both presented our arguments reasonably well and soon this will probably just turn into baiting for flames. Feel free to respond to this post however I may or may not respond unless it's something important.

    That C++ is verbose compared to functional programming languages is not a particularly strong argument
    I'm hardly arguing functional languages are the answer, my response simply used one, python is more succinct than C++ too.

    The power of a language is defined by the ease with which you can express your ideas. It's a matter of concepts, not syntax.
    A language is it's syntax, so it's syntax directly affects the ease of which you can express your dies. If this wasn't the case wouldn't we all easily be able to express ourselves in C or Assembly just as easily as another language? But this is obviously not the case.

    does this make Python a bad language compared to similar languages? (That is, object-oriented, weakly typed scripting languages.) No, because Python has the same power - it is equally capable of expressing
    For the record, Python is a dynamically strongly typed language. Automatic type conversions dont' take place, Perl would be weakly typed.
    This is the exact point the essay is arguing. Languages are equal in what they are capable of expressing (Turing Equivalent ones atleast). The issue is how well it lets you express it. I think it's fairly obvious some languages let you express some ideas more succinctly than others and the point of the paper is to ask the question "does that make one language more powerful than another".

    If you say that you need to know a lot of C++ to solve even small problems, then you are somewhat right - but that's irrelevant, because C++ wasn't made to solve only small problems forever.
    I'm unsure of how that is irrelevant. The more complex the problem the more knowledge of C++ one needs, and considering C++ is a rather large language that is hard for most people to keep in their head. If a small problem requires knowing quite a bit then the larger the problem, the more you need to know. I'm sure this plateaus off somewhere, but where?

    I would also argue that the mere concepts of functional languages, and how they can be applied, are harder to learn than most of C++ as a language, including the object-oriented concepts, simply because the object-oriented model is closer to the way humans think.
    From what you have listed, Haskell seems to be the only functional language you have had experience with. Haskell is a fine language and all, but oen cannot take things from Haskell and generalize them over all functional languages. Haskell tries to be very pure in how it does things functionally. Haskell makes strong attempts to avoid side effects. This is why we have monads. Many other functional languages are not like this and understand we can have side effects. in Erlang we have io:fwrite, in Common Lisp, format and print functions. These languages are quite easy to understand. Erlang in particular was developed with ease of learning in mind.
    I am also a bit hesitant to beleive that OOP truly models how we think. Do you have any research papers that show this or is it your intuition? As far as I know, few people are really aware of how we think and are not in a position to provide comparisons to a programmatic concept. If we really do think in an OO style, then I would argue that a language such as C++ or Java model this fairly poorly. Thoughts seem more dynamic and fluid than these languages allow. I do not have a Ph.D. in neuroscience though so I cannot say for sure. In my experience I have found functional programming to be qutie powerful and have been fairly successful with it. Perhaps toying with other functional languages than haskell will alter your opinion of the style.

  13. #43
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    A paper on functional programming and the real world (I have not read it yet but stumbled over it):
    http://www.md.chalmers.se/~rjmh/Papers/whyfp.html

  14. #44
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    I don't mean this as an attack on you at all orbitz, please don't take offense.

    Honestly, if I have a programmer on a team that isn't willing to use language A because it is too difficult for them to use/understand, I would have to question why they are on the team. Programmers solve problems, both mathematical and abstract and documentation is everwhere, a small hill in a language or library should not stop or slow a project. Off course if a language offers a go.now approach you can finish your product faster, but there are some very well wrapped libraries for most languages so you still get quite a bit of abstraction.

  15. #45
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    You are right, orbitz, the discussion is unlikely to lead far from here, so I'll respond just to a single point:

    A language is it's syntax,
    I disagree. The syntax is part of a language, but by far not the most important part. The syntax merely dictates how we express the concepts of the language, which are the really important part. For example, C has the concept of structured programming (functions, ifs, fors, ...) as an advantage over Assembly. While you can do these things in Assembly, it's not a language concept. This ties back into syntax, because if a language has a concept, then that means that there's special syntax available to support it. However, this is again a matter of cause and effect.
    The effect of pure syntax is stronger between Assembly and C than between, say, C and C#, which are syntactically very similar. Obviously, b = a + c is easier than
    mov eax, [a]
    mov ebx, [c]
    add eax, ebx
    mov [b], eax

    But that, too, is in my opinion an effect of concepts. In this case, it's the concept of abstraction from the machine, away from registers and towards variables as abstract containers of values.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Complex Number Class
    By Sephiroth1109 in forum C++ Programming
    Replies: 15
    Last Post: 12-12-2007, 04:46 PM
  2. Why am I getting 'undelcared identifier' ???
    By Bill83 in forum C++ Programming
    Replies: 2
    Last Post: 02-15-2006, 01:00 PM
  3. arithmetic operator friend functions
    By linucksrox in forum C++ Programming
    Replies: 7
    Last Post: 02-06-2006, 11:39 PM
  4. 2 am complex double conversion woes
    By Roule in forum C++ Programming
    Replies: 1
    Last Post: 10-14-2004, 02:53 PM
  5. Problem from texbook
    By Unregistered in forum C++ Programming
    Replies: 5
    Last Post: 07-26-2002, 04:55 AM