Is C++ the best language?

2

Comments

  • : [b]1. Does the language compile?[/b]
    : Entirely beside the point. Whether a language is implemented as a
    : compiler or an interpreter is not usually part of the language
    : definition. Although BASIC is usually thought of as an interpreted
    : language there are plenty of BASIC compilers out there. And while
    : Pascal is usually compiled the book [italic]Oh! Pascal![/italic]
    : comes with a disk that includes a Pascal interpreter. I'll bet if
    : you looked hard enough you could find a C++ interpreter, or could
    : write one yourself. This factor does not deserve to be considered
    : let alone be worth two points.

    [blue]I suppose the criteria could as well been written as "will the programs made in the language be fast or slow", since that is what the points are all about. Also, interpreted languages can never be used to write stand-alone applications such as operative systems or embedded applications.

    It is worth to note that both C and C++ standards mentions compilers "between the lines", ie they implicitly assume the language will be compiled to binary files.[/blue]

    : [b]3. Does the language support multiple operating systems?[/b]
    : Again beside the point. Popular languages get implemented on
    : popular operating systems. It also seem to be sort of upside down.
    : Languages do not support operating systems. Operating systems
    : support languages. But I'll give you this one simply because most
    : good languages get implemented on most OS.

    [blue]It isn't beside the point. Some languages [italic]can't[/italic] be implemented on multiple operating systems. Some examples are Visual Basic which can only be implemented in Windows, per definition of the language, and Java, which can only be implemented on systems with a virtual machine, ie there must be an OS.

    I don't agree that systems support languages. I can come up with one or two systems designed to only support one specific high-level language. There are however thousands of systems (and I'm not exaggerating) without any language support at all, apart from machine code / assembler.[/blue]

    : [b]5. Does the language support object orientation?[/b]
    : I'll give you this one.

    [blue]OO is a fuzzy term though. As I for example (boldly) wrote in reply to that blog, ANSI C does support object orientation, while it does not support inheritage. C is excellent for writing module-based, highly maintainable programs with encapsulation of private variables.[/blue]

    : [b]6. Is the language commonly used to write device drivers and
    : other low level software?[/b]
    :
    : [b]7. Does the language support pointers and direct memory
    : allocation?[/b]
    : I personally consider both 6 & 7 a negative, but I'll give you both.
    : Nolo contendre.

    [blue]If a language can't write every kind of application, it will have to depend on other languages to do the real work for it. Kind of like people who post on programming sites asking for someone to do their homework for them :), the program will work when executed, but not by its own effort.[/blue]

    : I'd like to add ...
    : [b]11. Does the language have an annual "obfuscated code" contest
    : and/or a best selling (fill in name of language here) puzzle
    : book?[/b]
    : If so, subtract three points. This is not a minor consideration.
    : In any major programming effort, major meaning a minimum 2000 nccl,
    : programming in C, instead of Cobol, Fortran, Pascal, etc, is a
    : continuous bug hunt. I firmly believe that most of the bugs that
    : plague the software buying public, the ones that got by both the
    : programmers and the beta testers, would not exist were the dominant
    : languages not C/C++ and their derivatives.

    [blue]Hehe... well, the only reason there is one for C and C++ is that they are popular. I don't know of any single language where you can't screw up the code so that it is completely unreadable.

    The majority of the bug plauge comes from the fact that a majority, not a minority, of the programmers in the world are incompetent, no matter language. In my opinion, you need a degree and 3 years of full-time programming experience as a minimum, before you can even claim to be a [italic]decent[/italic] programmer. I see so many poor examples all the time from people that are supposed to be professional programmers, it makes me sick knowing that people actually pay money for their programs.

    I think it is because various attitude problems. People who know the syntax of a programming language tend to claim to be programmers just because of it. Then there are people who refuse to use any programming standard and re-invent the wheel. And then there are people who write programs "in theory", who are clueless about what their programs actually do on a machine level. [/blue]

    : Personally, I don't care for the idea of a "best language" since it
    : implies that some general purpose language exists that is a panacea
    : for every programmer's ills. There just isn't any such animal. C
    : was invented to write an operating system and by extension also
    : serves to write drivers. That it was ever used to do anything more
    : than that is an accident of history, a misfortune that computer has
    : suffered from for over two decades with no end in sight. There are
    : plenty of programming problems out there (most in fact) for which C
    : is not the best answer, albiet (#10) it is [italic]an[/italic]
    : answer.

    [blue]Agreed, it doesn't make much sense to nominate a programming language for "best language all categories". C/C++ is for example a rather poor choise for web/desktop programs. Java or C# are better choises there. But at the same time, that assumes that you will only make web/desktop programs and nothing else.

    Though, the flexibility of C [italic]is[/italic] a great advantage over other languages. You can take code you wrote as part of a program for an 8-bit microcontroller and put it inside your huge graphic PC video game.

    And the other main advantage is efficiency. There is yet no other high level language which is as fast and memory efficient. None. Assuming that we are talking about the real implementation and practical usage of the language. On a fuzzy academic level without any connection to reality, then every language is equally fast/slow.[/blue]

    : I'd like to know what other languages you are familiar with. In my
    : experience most C/C++ enthusiasts either started out as assembly
    : language programmers or else were taught C/C++ as a first language
    : (Bad choice for a first language). Those who started, as I did,
    : with Fortran, Cobol and BASIC as first languages tend to not like
    : it. I'll admit that I have not polled enough programmers to form a
    : statistically significant sample.

    [blue]I would count as a C/C++ enthusiast and I started out with Pascal. I liked C a whole lot better than Pascal when I learnt it. Suddenly you could do everything with the language.[/blue]
  • I think the Assembler is the only real language. Why is it not so popular? (1) Because operation systems tend to keep their secrets, so assembly programming has poor documentation support; (2) there are few written and ready procedures and functions to import for an assembly source. Pascal and C would be nothing without the official units and include files; (3) as you mentioned programmers' abilities, assembly takes a decent programmer. And who is the decent programmer? Who can keep certain numbers of steps and values in mind. Who cannot do that, they brand a difficult source "unreadable". It is very funny when programmers insert comments and tabulators (number of spaces) by "good programming practice", and you can see everything but the code they wrote... I think a decent programmer CAN read and does not need comments; (4) there are too many kind of PC and OS. If there was one standard PC to know well, writing applications would be easy even in machine language, because it would not take a decade of research how to call BIOS routines, read ports, handle the filesystem. Basically these jobs are like simple function calls and moving values and parameters like write(this) and read(that). It surprises me how easy could an inline statement be.

    Does object oriented programming make a good language? Was OOP not invented because the language was not good enough for team work? If OOP was just a matter of syntax, it would solve the problems, but it is a matter of making a high level language more structured and farther from the real program code and results poor machine code. OOP provides programming security, but it creates new problems. (Your C++ and Java "few-line" examples demonstrate very well the thing: only ten lines in the source, but a thousand in the code. This is why I dropped OOP at once. You can never tell what the elegant statements do and at what cost...)

    I think OOP can be replaced by the IDE Inking Techniques. (The source is of two files: the usual text and the mirror info-file and the team members write their things "in different ink". In the end the preprocessor sees the mirror info and warns by agreement, the compiler sees only the text).

    The good high level language:
    (1) uses only basic statements and no inclusive functions as write(), "GetEnvironmentStatusThreadErrorProcWhenReady()", because every interaction with the hardware and the OS is hardware and OS dependent. How could Pascal, for one, be a standard language when you cannot use the Write() procedure under Windows without emulation for instance;
    (2) supports only the data types of the machine, which is all about size and not value interpretation;
    (3) utilizes the instructions of the processor by enforcing the programmer to use clear and optimal statements;
    (4) has a simple interface for import sources and binaries as well to fill the space of the lacking built in "standard" routines;
    (5) has a strict ISO standard. I think the ISO standards allow too much, and sometimes they allow very ill protocol to interact with the environment;
    (6) has compiler directives built in the syntax. Lots of statements and calls fail when a directive is not set properly. (Such directives regarding data alignment, calling protocol, optimatization, processor type, filesystem, etc.) As compiler directives were invented to create environment dependent code, the language must be environment dependent. Going round...

    As the available operation systems and personal computers stink due to bad standardization, wrong policies, and commerce as top priority, it is hard to create a good language.
  • Assembler is not so popular because it is extremely unportable. You will have to re-invent the wheel as soon as a new CPU is released or as soon as the program is moved to another system. Programming != PC, after all.

  • Sorry, I have to tell you. You CAN'T compare one with each other. Because each one was developed in different lines of work.

    Try to build a regular expression parser in C++ ? Try to build a driver in Unix scripts ? A Database application in Fortran ? A graphical interface in PHP5 ? A 3D game in Perl ?

    With ASM and C++ you can make everything other languages do, because (some of those) are created in C, C++. But those already has it done.

    Each one has its own place in programming environment, you can't compare them because neither of them was designed to replace any of each others. Just to design different kind of applications.

    [red]Good luck![/red]
    [blue]Hackman[/blue]
  • :
    : Try to build ... A Database application in Fortran ?
    :
    I've done it.

    Actor

  • : I think the Assembler is the only real language. Why is it not so
    : popular? (1) Because operation systems tend to keep their secrets,
    : so assembly programming has poor documentation support; (2) there
    : are few written and ready procedures and functions to import for an
    : assembly source. Pascal and C would be nothing without the official
    : units and include files; (3) as you mentioned programmers'
    : abilities, assembly takes a decent programmer. And who is the decent
    : programmer? Who can keep certain numbers of steps and values in
    : mind. Who cannot do that, they brand a difficult source
    : "unreadable". It is very funny when programmers insert comments and
    : tabulators (number of spaces) by "good programming practice", and
    : you can see everything but the code they wrote... I think a decent
    : programmer CAN read and does not need comments; (4) there are too
    : many kind of PC and OS. If there was one standard PC to know well,
    : writing applications would be easy even in machine language, because
    : it would not take a decade of research how to call BIOS routines,
    : read ports, handle the filesystem. Basically these jobs are like
    : simple function calls and moving values and parameters like
    : write(this) and read(that). It surprises me how easy could an inline
    : statement be.
    :
    : Does object oriented programming make a good language? Was OOP not
    : invented because the language was not good enough for team work? If
    : OOP was just a matter of syntax, it would solve the problems, but it
    : is a matter of making a high level language more structured and
    : farther from the real program code and results poor machine code.
    : OOP provides programming security, but it creates new problems.
    : (Your C++ and Java "few-line" examples demonstrate very well the
    : thing: only ten lines in the source, but a thousand in the code.
    : This is why I dropped OOP at once. You can never tell what the
    : elegant statements do and at what cost...)
    :
    : I think OOP can be replaced by the IDE Inking Techniques. (The
    : source is of two files: the usual text and the mirror info-file and
    : the team members write their things "in different ink". In the end
    : the preprocessor sees the mirror info and warns by agreement, the
    : compiler sees only the text).
    :
    : The good high level language:
    : (1) uses only basic statements and no inclusive functions as
    : write(), "GetEnvironmentStatusThreadErrorProcWhenReady()", because
    : every interaction with the hardware and the OS is hardware and OS
    : dependent. How could Pascal, for one, be a standard language when
    : you cannot use the Write() procedure under Windows without emulation
    : for instance;
    : (2) supports only the data types of the machine, which is all about
    : size and not value interpretation;
    : (3) utilizes the instructions of the processor by enforcing the
    : programmer to use clear and optimal statements;
    : (4) has a simple interface for import sources and binaries as well
    : to fill the space of the lacking built in "standard" routines;
    : (5) has a strict ISO standard. I think the ISO standards allow too
    : much, and sometimes they allow very ill protocol to interact with
    : the environment;
    : (6) has compiler directives built in the syntax. Lots of statements
    : and calls fail when a directive is not set properly. (Such
    : directives regarding data alignment, calling protocol,
    : optimatization, processor type, filesystem, etc.) As compiler
    : directives were invented to create environment dependent code, the
    : language must be environment dependent. Going round...
    :
    : As the available operation systems and personal computers stink due
    : to bad standardization, wrong policies, and commerce as top
    : priority, it is hard to create a good language.

    You're right that assembler is the only real language. The problem is that every different CPU has its own assembly language. That means close to zero portability.

    However, the primary reason it is unpopular is that a tremendous number of programmer hours are required to develop and maintain an application. Rapid Application Development it is not. The very purpose of a high level language is to trade machine time (which is cheap) for man hours (which are expensive).

    In my early days I wrote a lot of quick and dirty programs for engineers. The request could come in at 9:00 a.m. and I'd have the program ready at noon. I did this in Fortran and BASIC. If I'd had to do this in assembler it would have probably taken a week and the engineer would probably have just done it by hand using a lot a paper and an adding machine.



  • [color=Red]I never said and I'm not saying it can't be done.[/color]
    You can do everything you want with every language.

    I'm saying that some languages already
    has better support for some kind of tasks,
    and that's why you shouldn't compare them.

    Of course you can design database applications
    in Fortran, but you need at least 3000% the time
    you need to do the same thing in COBOL.

    So, it's like comparing a Electrician against
    a Salesman, both could be professionals, but each
    one in his territory.

    [red]Good luck![/red]
    [blue]Hackman[/blue]
  • Hmmm...

    : - Be platform-independant. This is as fundamental as it can get, it
    : is the least you can require of a general-purpose language.
    :
    : - Have no need of an interpreter or runtime junk. VB, Java and .NET
    : are typical examples of why. And why make slow and memory consuming
    : programs requiring a load of bulky files, when you can make fast
    : ones without the need of additional files instead?
    These two are somewhat at odds with each other. There are a lot of very different platforms out there, both operating system wise and hardware wise. VMs do the abstraction layer for this once and provide it for many programs to take advantage of. If you decide to do all the work yourself, you may well find you end up with as much stuff sitting around to handle that anyway. Have you ever seen a program that has to run on over 50 different platforms with consistent as possible semantics and see the amount of code that goes into this?

    : - Lack garbage collection. Not sure about anyone else, but garbage
    : collection just makes me laugh. What comes to my mind is "I have
    : such a hard time finding my memory leak bugs, and instead of
    : learning how to program properly, I would rather have my program
    : actively finding them for me in runtime."
    Sorry, but to me this is about as stupid as saying you'll program in assembly rather than using a high level language with a compiler, and that people who use high level languages haven't learned to program properly.

    Garbage collection is a TOOL. Like a compiler, the point is that we get the computer to the hard work for us. Because that's why we're paying for it rather than sitting there doing our calculations by hand, right?

    I know GC isn't suitable for every situation, but for the majority it's just fine. The industry would do a whole lot better if programmers were more interested in delivering what their clients needed than placing themselves above the tools that are there to help them do just that.

    : - Support multi-threading on a language level, or by including POSIX
    : threads as part of the standard.
    Support concurrency of some kind, for sure. The languages of the future will hopefully make a better job of hiding away the gritty details of concurrency though. Then we'll have a bunch of people who say, "I'm not going to use X feature that helps me write concurrent programs that behave correctly! Threads and mutexes all the way!" :-)

    Jonathan
    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");
  • : 1- array out of bound exception... it doesnt check the array bound
    : at compile time which is very bad... not as java.
    Erm, actually Java does the majority of those checks at runtime.

    : 2- there is a violation in the class design. i mean we can access a
    : private member from outside of the class using the friend class
    : modifier.
    In Java we can do this with reflection.

    : 3- Templates in C++ are error prone and soo complicated comparing to
    : Java Object type
    Huh? That's like saying apples from England are so much tastier than oranges from Spain. :-) If you're going to compare templates with anything in Java, it's generics you should be comparing it to.

    : 4- pointer in C++ are not safe as java's pointers
    True in that you can have pointers in C++ that point into areas of memory that are deallocated, never allocated or allocated for something else. The thing that always amused me in Java is that they are called references rather than pointers - until you try and access a null one and then you get a NullPointerException. :-)

    : but as a system language C++ is good .. or if you want to use C++ in
    : building games...
    Sure. It's about choosing the right tool for the job. Sometimes C++ is that. Sometimes it isn't. There's no one true language.

    Jonathan
    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");
  • : : - Lack garbage collection. Not sure about anyone else, but garbage
    : : collection just makes me laugh. What comes to my mind is "I have
    : : such a hard time finding my memory leak bugs, and instead of
    : : learning how to program properly, I would rather have my program
    : : actively finding them for me in runtime."
    : Sorry, but to me this is about as stupid as saying you'll program in
    : assembly rather than using a high level language with a compiler,
    : and that people who use high level languages haven't learned to
    : program properly.
    :
    : Garbage collection is a TOOL. Like a compiler, the point is that we
    : get the computer to the hard work for us. Because that's why we're
    : paying for it rather than sitting there doing our calculations by
    : hand, right?
    :
    : I know GC isn't suitable for every situation, but for the majority
    : it's just fine. The industry would do a whole lot better if
    : programmers were more interested in delivering what their clients
    : needed than placing themselves above the tools that are there to
    : help them do just that.

    The difference is that you can make a high level language program as fast as an assembler program if you wish to sacrifice the readability of the code. You cannot however disable garbage collection in languages like Java/C#, if you would desire to avoid memory leaks by for example using smart pointers instead. GC is not a tool, since you get it whether you wish to use it or not.

    My point is that garbage collection is a poor solution. Smart pointers are better, and they aren't harder to use than any other kind of variable. If you use smart pointers, you don't need garbage collection. I don't think it is too much to ask of a programmer to study smart pointers for a few days in order to increase his program's performance drastically. Smart pointers can be used in time-critical applications, while garbage collection cannot be used there.

    ---

    Also I would ask you to use a more polite tone in your replies. Calling another poster or their arguments for stupid is not ok, nor is flaming of any kind. Had this post been directed to anyone else but myself, I would have removed it.
  • :
    : You're right that assembler is the only real language. The problem
    : is that every different CPU has its own assembly language. That
    : means close to zero portability.
    :
    : However, the primary reason it is unpopular is that a tremendous
    : number of programmer hours are required to develop and maintain an
    : application. Rapid Application Development it is not. The very
    : purpose of a high level language is to trade machine time (which is
    : cheap) for man hours (which are expensive).

    Expensive man hours and portability. Yes, that is true. I just answered the topic which was started rating the abilities of a language. I also prefer high level languages to assembler (I am really not an assembly programmer in any meaning), but I dare add some more:

    Even the machine language has built-in functions and iterations (real iterations, not just the same old loops), and it happens that a machine code statement is even shorter and more readable than the high level language statement for the same result, let alone efficiency.

    You mentioned portability and I mention weak standardization again. The manufacturers go directions they please (they have the right of course), but all in all they just ruin one other's business and, most importantly, the computer world.

    I do not discriminate Pascal, C, and any other language. Each language can be put in practice right and wrong ways. In my opinion, Turbo Pascal was more decently put together than the ISO follower variants of Pascal.

    (Personally the symbolist and case sensitive sytax of C left me with mixed feelings.)

    A good high level language never leaves the assambly sense, its basic statements are almost equivalent to the assembly (the difference is usually that assembler uses registers, the high level language uses variables, because the contents of a register is uncertain and hidden and lost between the lines of the high level language syntax). The ability of time-sparingly writing a program in a language depends on how the supplied functions supports the cause of the programmer/user. But that is not the topic about languages; it would be a topic of how a language is supported by developers and hardware inventors, and if it is so, we have stated, as unified, that assembly language is not supported well, therefore writing in asm is a pain and means wheel inventions.

    Oh, I must add this fine example: once upon a Turbo Pascal tool called Turbo Access. It could do everything (indexed and relative databases) Clipper and the like could do with less hardware expenses. When others wrote database handlers in Clipper I thought: you are crazy. All is about support. As Borland International Inc. (the supporter) died, Turbo Pascal died with it. Who could tell how far TP would have reached by now with support! There would not be Delphi, Kylix, GNU Pascal and such, for sure. (The Borland of today is a different company, it just holds the similar name.)
  • : You mentioned portability and I mention weak standardization again.
    : The manufacturers go directions they please (they have the right of
    : course), but all in all they just ruin one other's business and,
    : most importantly, the computer world.


    It is not that simple. First there are 8-bit, 16-bit, 32-bit and 64-bit cpus. To make assembler portable between them isn't simple, especially not when going from a large address bus to a smaller one: that code [italic]can't[/italic] be portable by definition, or it would be very ineffective. Plus, processors relying on external memory vs microcontrollers with memory and peripherals on-chip have very different needs.

    Standardization is however taking place more and more. The big players in the cpu industry are all making their cpu families compatible from the range of 8 to 32 bit. Most of them also have an ARM version, which has turned into an industry standard. Intel/ADM made 64-bit cpus compatible with 32-bit ones, and so on.

    Then there are architecture problems. Intel and Intel derivates in the whole range from 8 to 32 bit have always been odd in their core design, and have by tradition been rather code-inefficient. And then there is the old feud between little and big endian... or the feud between Intel and Motorola ways of thinking, where both camps believe their solution is the better. Intel side has its sheer size, while Motorola side is usually more code-efficient in most performance tests.
  • :
    : You mentioned portability and I mention weak standardization again.
    : The manufacturers go directions they please (they have the right of
    : course), but all in all they just ruin one other's business and,
    : most importantly, the computer world.
    :
    Unfortunately no standard can anticipate advances in technology. Standards are good for business but in many cases they must be ignored if progress is to be made. This is another reason for high level languages.


  • :
    : [color=Red]I never said and I'm not saying it can't be done.[/color]
    : You can do everything you want with every language.
    :
    : I'm saying that some languages already
    : has better support for some kind of tasks,
    : and that's why you shouldn't compare them.
    :
    : Of course you can design database applications
    : in Fortran, but you need at least 3000% the time
    : you need to do the same thing in COBOL.
    :
    : So, it's like comparing a Electrician against
    : a Salesman, both could be professionals, but each
    : one in his territory.
    :
    : [red]Good luck![/red]
    : [blue]Hackman[/blue]
    Actually I don't think writing it in COBOL would have saved that much time. The actual development time may have been cut in half. However, a COBOL version would probably have run faster in less memory. I know the storage of the actual data was very inefficient. We tried to find a COBOL compiler for our machine but were unsuccessful. I don't think management would have bought us one anyway. I think the Fortran compiler cost thousands (circa 1985).

    Actor


  • For what it's worth here's a quote and the link where I found it. I'm not a Lisp programmer.

    "If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases."

    Common Lisp is truly the Borg of programming languages!

    http://bc.tech.coop/blog/040402.html
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories