future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: DeMarcus on 27 Jun 2010 00:27 On 2010-06-25 02:34, joe wrote: > "DeMarcus"<use_my_alias_here(a)hotmail.com> wrote in message news:4c2206bd$0$281$14726298(a)news.sunsite.dk... >> On 2010-06-22 01:43, Anton Zakitniy wrote: >>> Hello! >>> Forgive me if my question is stupid and english is not native for me., >>> but it worries me! >>> I'm not very experienced >>> programmer. I really like C + + and I want to become a good >>> programmer. >>> But something that bothers me. >>> Will C + + language is enough demand in the near future? >>> Will it continue to use many, many companies and many, many projects, >>> not only for operating systems and games? >>> I not want to C + + is outdated so soon and C# will take up positions >>> at the C + +. >>> I would be happy to know the answer from a programming guru! >>> >>> I wish you all the best! >>> >> >> C++ is one of few internationally _standardized_ programming languages. > > You say that like it is a good thing! > It is a very, very good thing. 1. The whole industry is involved in the decision of making changes to the standard. 2. We get a slow development of the standard to ensure the new features will last, e.g. thread support. In general, what we get is a reliable programming language that will last, not just something pushed by some marketing department with flashy "Version 17.0 out now!" banners. C++ is not part of any language competition that we see between companies. We also know that code we write today will compile also in five years. Quick development of a language may be good in areas where software is developed and thrown out in the same pace, but where you want an application to live some years it's not fun to realize you can't make changes to five year old code just because it won't compile due to some CEO's business strategy decision. >> You should be more afraid of the lifetime of languages owned by a >> company. Look what happened to Visual Basic 6.0. It's now deprecated! >> > > So what you are basically saying, C++ isn't the worst of 2 evils (?). The > PL landscape is much larger than C++ vs. proprietary languages. IMO, C++ > will morph or fork or become increasingly uncompetitive (chosen less and > less by programmers, projects and organizations). > As I said, proprietary languages may be good in areas where language development pace is more important than durability. C++ is one of few languages I trust in the sense of durability. It's also interesting you mention that C++ is likely to fork, when as far as I know (please correct me if I'm wrong), the only entity that has done a fork of C++ is Microsoft. When it comes to for instance Java, we already see a fork in terms of Scala. http://en.wikipedia.org/wiki/Scala_(programming_language) No sane company would fork C++ today, especially when it now feels stronger than ever. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: John G Harris on 27 Jun 2010 21:11 On Sun, 27 Jun 2010 at 09:16:34, in comp.lang.c++.moderated, Le Chaud Lapin wrote: <snip> >For example, during the middle of the 20th century, there was heated >debate about whether the phasor method, using basic trigonometry, or >the Laplace transform method, using complex analysis, was better for >circuit analysis for electrical engineers. <snip> As it happens I was taught both phasors and Laplace transforms (in 1960). It was obvious that they were suited to different problems. Likewise, different programming languages are suited to different problem areas. For instance, Cobol is better than C++ at describing alien data formats. John -- John Harris [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 28 Jun 2010 05:35 On 27.06.2010 17:16, Le Chaud Lapin wrote: > On Jun 24, 7:37 pm, "joe"<jc1...(a)att.net> wrote: >> I disagree. Doing something to learn something else is not an efficient >> use of time. To learn other paradigms, read some books on language >> design. No need to to get deep into other languages unless you are still >> (....) Use your time wisely. > > There is an implicit untruth that is told by every person who compares > without qualification C++ to languages like Java/C#/Python : > > Programmers who rightly call themselves proficient in C++, generally > speaking, are more competent, as engineers, than programmers who call > themselves proficient in languages like Python. > A programmer that really knows C++ well may know more about the details and pitfalls of low-level workings when executing code on a computer. To claim that that makes him a more competent engineer seems a bit over the top though. Engineering is just as much about knowing the right tools for the job and how to use them as it is about knowing the basics. Now regarding computing, I do think a "C++ engineer" will know more about the foundations of what make his work tick, but a good "dynamic language engineer" might know what tools to use to get his job done efficiently. > This discussion we are having regarding languages as tools...it exists > in parallel engineering disciplines. > > For example, (....) > > The point is this: > > It is not enough to compare languages. One must also compare the > engineers, and what exists in the mind of each engineers after s/he > has learned a language. > Except that you do *not* learn a programming language in isolation. You are exposed to different tools and different environments and all this knowledge of how to combine it all to *make* something that other human beings find useful adds up and is what make you a good (or bad) engineer. > A person who masters Python, in general, cannot compare to one who > masters C++. The very notion that someone is a master of C++ implies > that s/he knows more about software engineering than someone who has > mastered some other high-level interpreted language. > > Which engineer do you want on your team...the trig-only guy who was > frightened off by complex analysis, or the Laplace transform guy who > does not know trig-only method? One easily learns what the other > knows, but the converse is not true. > If I'm building a webapplication, I'll want the Python engineer. She's much more likely to be effective in a heterogeneous environment, probably she has done some other scripting languages as well. She might also be a lot better and more disciplined when it comes to practises such as unit testing etc. If I'm building a numerical processing tool, I'll want the C++ engineer. She'll know how to use C++ or D or C to her advantage and she'll be more aware of performance pitfalls. Note that I want an engineer in both cases, not just someone who calls herself programmer and hacks stuff together equivalent to someone using duct tape to build a house. C++ is a good language with too many warts. We as C++ engineers should not be so foolish as to look down on other people just because they are proficient in something else. cheers, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jens Schmidt on 28 Jun 2010 05:46 John G Harris wrote: > Likewise, different programming languages are suited to different > problem areas. Definitely. But some are nearly universally suited, and some are mostly useful as a bad example. C++ is in the first group, pick your own for the second. :-) > For instance, Cobol is better than C++ at describing > alien data formats. Not, if the alien data format is XML. COBOL's great advantage are tabular formats with textual representation in fixed size fields. Not a large niche today. Even for closely related formats like CSV I won't even consider COBOL. -- Viele Grüße, Jens Schmidt [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Le Chaud Lapin on 28 Jun 2010 06:03
On Jun 28, 7:11 am, John G Harris <ne...(a)nospam.demon.co.uk> wrote: > On Sun, 27 Jun 2010 at 09:16:34, in comp.lang.c++.moderated, Le Chaud > > Lapin wrote: > > <snip>>For example, during the middle of the 20th century, there was heated > >debate about whether the phasor method, using basic trigonometry, or > >the Laplace transform method, using complex analysis, was better for > >circuit analysis for electrical engineers. > > <snip> > > As it happens I was taught both phasors and Laplace transforms (in > 1960). It was obvious that they were suited to different problems. Hmmm...if, by "different problems", you mean "different student audiences", I agree. But in both cases, the problem is circuit analysis, and there is nothing that a phasor can tell me that I cannot determine much more quickly using Laplace transforms and pole-zero plots. > Likewise, different programming languages are suited to different > problem areas. For instance, Cobol is better than C++ at describing > alien data formats. Yes, I would have to agree, but this misses my original point. One must ask: "All other things being equal, what is in the mind of a COBOL-only programmer vs. C++-only programmer?" The imagery that manifests in the minds of each might be more or less the same if the problem is the same: "Write a program to send out reminders to all customers whose frequent- flyer miles are to expire within 30 days." To solve this problem, both programmers might think about FOR loops, the C++ programmer thinking FOR/DO/WHILE, the COBOL programmer apparently thinking PERFORM. Both programmers might think about what email-interface API is available. And so on. But watch what happens when we change the problem: "Write a device driver to encrypt all packets exiting a 1Gb/s Ethernet adapter using 256-bit AES." The C++ programmer might find the answer after some fidgeting. The COBOL programmer's mind will go blank. Note that the fundamental issue here is not insufficiency of the language: that COBOL cannot be used to write device drivers. We can easily solve the insufficiency problem by presenting a third, fictitious language, XYZ, that might be used by both programmers: "You have 3 hours to implement a basic skeletal driver using this new XYZ language that is legendary for implementing device drivers." In that case, the C++ programmer would rummage through XYZ, hunting for primitives that s/he is confident transcends all languages suitable for implementing device drivers. The COBOL programmer's mind would still remain blank. This is why, whenever a young person asks, "Which language should I learn to be a good programmer?" We should take into consideration what is really being asked, and respond with another question: "What scope of understanding do you want in the field of software engineering?" If the answer is, "I don't care. I just want to do some number crunching.", then many languages will do. If the answer is "I want to know what's really going on...", then a good answer is "C++", because it is very hard to know C++ well and not know what's really going on. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |