Slashdot Mirror

← Back to Stories (view on slashdot.org)

Most Popular Programming Languages: C++ Knocks Python Out of Top Three in New Study (techrepublic.com)

Posted by msmash on from the how-about-that dept.

C++ has knocked machine-learning favorite Python out of the top 3 in the TIOBE Index of popular programming languages. From a report: It marks a reversal of fortune for C++, which, after years of occupying third place in the index, was pushed down to fourth place by Python in September last year. First and second place in the list remain unchanged, with Java in pole position and C at number two. The TIOBE Index attempts to estimate the popularity of languages worldwide based on results from major search engines. The index is sometimes criticized for being a rather blunt measure, likely to be influenced by a range of factors beyond a language's popularity, but its rankings are broadly in line with others, with a similar mix of languages albeit arranged in a different order.

In an analysis alongside the latest figures, TIOBE attributes the comeback of C++ to a surge in its popularity, rather than a fall in the use of Python. "This is certainly not because Python is in decline: Python is scoring all time highs almost every month. It is just that C++ is also getting more and more popular," it writes. The report credits this growing interest in C++ to C++11, the version of the language released in 2011 that TIOBE said made C++ "much simpler, safer and more expressive."

161 comments

  1. Safer, simpler, more expressive by Latent+Heat · · Score: 3, Insightful

    Pick any two.

    1. Re:Safer, simpler, more expressive by mschaffer · · Score: 1

      The "good/cheap/fast---pick any two" paradigm doesn't apply here. It's not a fixed project or product. Rather it's an evolving standard benefiting from the efforts of many, the expenditure of many resources, over long time periods. After all, they are working on c++20!. So, this is not apt.

    2. Re:Safer, simpler, more expressive by DickBreath · · Score: 2

      I don't care how simpler C++ thinks it is.

      I can write a bigger, slower program in Java, in less time, any day of the week.

      --

      I'll see your senator, and I'll raise you two judges.
    3. Re:Safer, simpler, more expressive by K.+S.+Kyosuke · · Score: 1

      Safer, simpler, more expressive

      ...something like Scheme, then?

      --
      Ezekiel 23:20
    4. Re:Safer, simpler, more expressive by ceoyoyo · · Score: 2

      In my experience, the expressiveness of C++ has always made it non-simple. So maybe pick one?

    5. Re:Safer, simpler, more expressive by Tough+Love · · Score: 2

      #4: slower. Python wins by a mile.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    6. Re:Safer, simpler, more expressive by AHuxley · · Score: 1

      Learn to code Ada.

      --
      Domestic spying is now "Benign Information Gathering"
    7. Re:Safer, simpler, more expressive by Anonymous Coward · · Score: 1

      That's because C++ only has two left to pick from. Stroustrup discarded "simpler" way back in 1997 with the introduction of template metaprogramming.

    8. Re:Safer, simpler, more expressive by Anonymous Coward · · Score: 1

      Which is funny from the guy who said macros/#defines were bad...

    9. Re: Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      Actually, template metaprogramming was a surprise to the C++ standards committee. I have met them personally and have heard them say so. Templates were intentional however. Metaprogramming was something that users came up with. That it worked and worked "well" was simply proof that they made the right fundamental choices. Bjarneâ(TM)s concepts are meant to finally clean up the horrific template errors resulting from that design, but they havenâ(TM)t reached consensus on them yet.

    10. Re:Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      LOL, very funny, but unfortunately, not true for me. Java is fucking slow to develop in.

      Why? The Java compiler just LOVES to whine and complain about minor syntax deficiencies. Java constantly wants me to explicitly cast one data type to another, even if it's blatantly obvious what I intended. C++ lets me do implicit casts that simply work without any fuss (although, you CAN set your compiler's options to get just as irritating as Java, if you're a sadist).

      In C++, I can whip out a chunk of code and have it compile just fine and dandy on the first try. With Java, I've gotta wade through all of the compiler's complaining and type out so much more explicit extraneous goo gaah before I can finally get the compiler to just let me run my program.

    11. Re: Safer, simpler, more expressive by astrofurter · · Score: 1

      Ada certainly looks like a nice language. Unfortunately very few civilian companies seem to use it. A quick search on Indeed.com suggests there are 20x more Python developer jobs than Ada developer jobs listed today. That without controlling for namespace collision with ADA regulations.

      Any thoughts on why Ada is so uncommon in private industry?

    12. Re:Safer, simpler, more expressive by ath1901 · · Score: 1

      Safer, simpler and more expressive are all relative measures and depends on what the language was like before the changes. C++11 made it easier to write safer, simpler and more expressive code. You don't have to, but it is easier to do it now. Just the addition of shared_ptr is enough to claim all three improvements.

    13. Re: Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      I doubt C is above C++. Incorrect counting algorithm probably

    14. Re:Safer, simpler, more expressive by vyvepe · · Score: 1

      Just the addition of shared_ptr is enough to claim all three improvements.

      shared_ptr was in boost long before C++11. There are more important additions like type inference, lambda functions, strongly typed enums, rvalue reference, variadict templates .... just to name a few more relevant.

    15. Re:Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      Templates made alot of work simpler

    16. Re:Safer, simpler, more expressive by jma05 · · Score: 3, Insightful

      You must not have used Java very much. Java IDEs mostly write all the tedious code for you, much more so than C++ IDEs can for C++ (Java is a much simpler language). No one writes casts, exception handlers etc by hand. Verbose, yes, but it is much easier to write Java than C++ for all but the simplest programs. That is one of its selling points.

      > Java constantly wants me to explicitly cast one data type to another, even if it's blatantly obvious what I intended.

      Give me an example.

      And if you think the compiler whining is a bad think, you will hate Rust, ML or Haskell, because Java is hardly the standard for a whiny compiler.
      Compiler warnings are a good thing. They save later debugging time, which is much more painful. Addressing the compiler while writing code for the first time is much simpler. It is just higher upfront cost, not higher total cost in programmer time.

    17. Re:Safer, simpler, more expressive by JoeDuncan · · Score: 1

      That's because C++ only has two left to pick from. Stroustrup discarded "simpler" way back in 1997 with the introduction of template metaprogramming.

      THIS^

      Lord I wish I had mod points for you... :(

    18. Re:Safer, simpler, more expressive by fibonacci8 · · Score: 1

      In which case you get to pick one.

      --
      Inheritance is the sincerest form of nepotism.
    19. Re:Safer, simpler, more expressive by serviscope_minor · · Score: 1

      but it is much easier to write Java than C++ for all but the simplest programs.

      I strongly disagree with that.

      I'm not a fan of java, but I'm not a hater of it either, from my point of view, it's solidly OK. But there's no way java is better for all programs than C++. C++ allows for much more expressive libraries than Java and if someone's put in the work that makes code much much easier to write.

      Take Eigen for example. Not a library you want to delve into, but as a user, you can write code that looks like maths. Or even moreso, take Ceres. You write maths just like normal and it automatically differentiates the expressions.

      For certain applications there are nice fixed point libraries.

      Image processing is miserable in java. There are many reasons but the lack of unsigned bytes is really super annoying

      That's all on the computation end, but that's my field at the moment. Java's just not a good fit, and it's simply easier in C++.

      --
      SJW n. One who posts facts.
    20. Re:Safer, simpler, more expressive by jma05 · · Score: 1

      > But there's no way java is better for all programs than C++.

      I don't think any one would suggest that.

      C++ is obviously much more flexible such that you can shoe-horn any niche paradigm into it. To get such language flexibility in the Java world, you pick from the dozens of alternative languages for the JVM.

      And of course, JVM won't give you everything when you need to work at a lower level.

      > Take Eigen for example.

      Sure. I tried Armadillo myself.

    21. Re:Safer, simpler, more expressive by DickBreath · · Score: 1

      As an actual Java developer, I can't even remember what a compile time error is. A modern IDE flags compile time errors before you build anything. And the IDE keeps compiled classes up to date at all moments. I could make a change in the current file, which now causes some other files to no longer compile, and they instantly start turning red in the file tree right before your eyes.

      A modern IDE even uses a variation of the compiler which compiles code with compile time errors -- so that when run it will produce run time errors explaining the compile time error. This is not the compiler you necessarily build your project with -- although you can -- because when you build you have no compile errors.

      Syntax deficiencies, any any language, are not minor. I could say that C++, or any language, loves to whine and complain about minor syntax deficiencies.

      Syntax errors simply mean the programmer doesn't know the language well enough. Yet.

      --

      I'll see your senator, and I'll raise you two judges.
    22. Re: Safer, simpler, more expressive by Carewolf · · Score: 1

      No concepts that clean up template metaprogramming are is already in C++20. It is agreed on just not ready in compilers other than gcc yet

    23. Re: Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      Lot's of C coding is done to fix all its security issues.

    24. Re:Safer, simpler, more expressive by serviscope_minor · · Score: 1

      I don't think any one would suggest that.

      You got awfully close. You said:

      but it is much easier to write Java than C++ for all but the simplest programs.

      So I don't really get your point.

      There's plenty of stuff written in C++. If it's much easier to write programs in Java, then why are major bitsof infrastructure (like Web browsers and compilers) generally written in C++? Not to mention games, numerical computation, embedded stuff, and so on.

      So I'm not sure what your point is. There are plenty of nontrivial programs for which C++ is the correct choice.

      --
      SJW n. One who posts facts.
    25. Re:Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      > There are many reasons but the lack of unsigned bytes is really super annoying

      Just make an array of 8 booleans. Voilà! :)

    26. Re: Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      They use C++ over Java for SPEED, doofus, not ease of writing.

    27. Re: Safer, simpler, more expressive by Anonymous Coward · · Score: 0

      when Ada was created, it was almost impossible, and extremely costly, to get a certified compiler, which made development that much more costly.

      That's just one of the reasons. There are others.

      If it wasn't for a decade or two requirement to use it for defense contracts, it probably would have as much penetration as PL/I with objects. (yup, it DID exist)

    28. Re:Safer, simpler, more expressive by jma05 · · Score: 1

      Performance ("Web browsers and compilers"), not expressiveness.

      It would generally be more elegant and easier to express the Eigen, Ceres, Armadillo code in MATLAB, Mathematica or a similar language. Neither Java nor C++ are optimal for this in terms of expressivity, but C++ would win over plain Java at this.

      Java is generally much easier than C++, unless you need memory control. Beyond that, I still understand you; some features of C++, like operator overloading, do make it more flexible than Java, even if you set aside memory control. When you need that flexibility in Java, you pull out Scala - quite easy to add to your Java project and interops with full IDE support.

    29. Re:Safer, simpler, more expressive by serviscope_minor · · Score: 1

      Performance ("Web browsers and compilers"), not expressiveness.

      I think you're stretching the point somewhat. It's not easier to write a web browser in Java is the resulting web browser is not useable. What's the point in doing three quarters of a task?

      It would generally be more elegant and easier to express the Eigen, Ceres, Armadillo code in MATLAB, Mathematica or a similar language.

      I know MATLAB and no it wouldn't. MATLAB for example doesn't give you static typing on, well, anything. Eigen and similar libraries give you static typing on matrix sizes, eliminating a whole slew of things at comile time.

      And with matlab,to get anything other than truly glacial performance, you haveto use MATLAB idioms which involves cramming eveything into an array expession which is generally harder to read, write and debug than for loops.

      MATLAB has it's place and I like it a great deal, however, for many tasks I reach for C++ first.

      Java is generally much easier than C++, unless you need memory control.

      Depends on the task. I've worked on image procesing code in both C++ and Java. It's a lot easier in C++.

      When you need that flexibility in Java, you pull out Scala

      That's not Java. That's a language running on the JVM but it certainly isn't Java.

      --
      SJW n. One who posts facts.
    30. Re:Safer, simpler, more expressive by jma05 · · Score: 1

      > Depends on the task. I've worked on image procesing code in both C++ and Java. It's a lot easier in C++.

      I am not disagreeing that Java is not the right language for you or for many tasks where you really need a language that runs natively end efficiently, without a VM/GC.

      Obviously, no language is optimal for everything and of course it "Depends on the task".

      But for a majority of tasks that programmers used C++ for earlier, Java has proven to be an effective and easier replacement.

      Rust is a more faithful C++ replacement, not Java. Obviously, no one actually wants to use something like Hot Java, but Firefox Quantum is great. No one wants a Photoshop in Java.

      Some of my colleagues work with image processing (research). They all work in MATLAB, most of the time. Obviously, it is glacial as one would expect a dynamically typed language to be. But that isn't the point when you are exploring transformations. This is the expensive part (human time). Once the algorithms stabilize, they are handed over to C++ engineers for final implementations. We do want core algorithms written in something native like C++. But most code in organizations is not like that.

      Java is, broadly speaking, easier to teach, easier to manage and easier to maintain than C++. There will always be exceptions. A managed runtime is always going to compromise performance and control over unmanaged native code. The compromises that Java makes towards simplification are quite acceptable for most people. It is just that you don't fit that profile.

    31. Re:Safer, simpler, more expressive by serviscope_minor · · Score: 1

      Well this is a substantially different claim from the original one, and I agree more with it.

      But for a majority of tasks that programmers used C++ for earlier, Java has proven to be an effective and easier replacement.

      Yesbut...

      I mean yes, for plenty of stuff Java is a more appropriate choice than C++. On the other hand if anything C++ is growing now, and a lot of migration was a long time ago. The world of C++ now is nothing like the world of C++ in 1996 when Java first stormed onto the scene.

      Obviously, no one actually wants to use something like Hot Java

      Wow that brings back memories. I've not heard that name in a VERY long time!

      Some of my colleagues work with image processing (research). They all work in MATLAB, most of the time. Obviously, it is glacial as one would expect a dynamically typed language to be. But that isn't the point when you are exploring transformations. This is the expensive part (human time). Once the algorithms stabilize, they are handed over to C++ engineers for final implementations.

      I use both. I've made prototypes in both MATLAB and C++, and continue to do so. The thing that sets C++ aside is it's a much more flexible language than MATLAB, it's sometimes referred to a a libary writer's language.

      Writing good libraries is hard, very hard, and few people can do it. But those libraries can be truly excellent nd act almost like an EDSL. MATLAB doesn't have that. It's basically an array processing language with an emphasis on linear algebra, and it always lookslike that.

      For example despite it's mathematical pedigree, MATLAB still doesnt have autodiff. If your image processing step involves any optimization it's much quicker and easier if you don't have to compute gradients.

      Likewise the lack of strong typing is a bit of a pain. It means I have tofind bugs at runtime.

      --
      SJW n. One who posts facts.
    32. Re:Safer, simpler, more expressive by jma05 · · Score: 1

      I learnt C++ in the Turbo C++ era and productively used it in C++ builder times.

      I disliked Java when it first came about; took away too many things. But later it got better and so did C++. Plugging in better languages into JVM is a much nicer experience (the tooling is more mature) than embedding an interpreter in C++.

      When I think of JVM, I really think of what I can do with Java + any other JVM language with good IDE support. That way I can express parts of my applications in the most suitable semantics, all in one VM. I like where GraalVM is going. But mostly I use Python backed by C/C++ libraries (they are after all THE library writer's languages today).

      I really wanted to like C++ since C++11. I see all these very promising expressive libraries that promise to be numerical, functional etc and keep trying them out. But each time, I go back to using a language with built in support for such things, not just through a library. C++ may have improved a lot since C++ 98, but so did the pleasantness in working with all other languages.

      C++ does everything, but everything in the end feels somehow just not fluid enough. That is not surprising for any jack-of-all-trades tool naturally, programming language or not.

      I gave up on C++. I don't NEED to write native code any more, but I like to. I moved to Rust for that niche and I hope it becomes more of a library writer's language (not betting on that though). I use Nim to generate C or C++ now. It may not work for your needs (it has a GC, but it may be moving away from that), but it seems to suit me.

    33. Re:Safer, simpler, more expressive by K.+S.+Kyosuke · · Score: 1

      You get all three. Unless the implementation is bugged, of course.

      --
      Ezekiel 23:20
  2. Make C++ simpler ?!? by dargaud · · Score: 5, Interesting
    You would have to remove things from it, not just keep adding every paradigm from every other language. That thing has everything and the kitchen thing: you can do pure C with it. Or (almost) pure Java. Or only macros and templates. Anyway one programmer's C++ program might as well be an alien language to another C++ programmer.

    Besides that, their whole methodology is crap, as has been noted many times over: if there are plenty of messages asking for help on stackoverflow, maybe it's because users are struggling with a language, not because it's 'popular'. A language that is very easy to learn on your own wouldn't have any messages now would it ?

    --
    Non-Linux Penguins ?
    1. Re:Make C++ simpler ?!? by fahrbot-bot · · Score: 1

      That thing (C++) has everything and the kitchen thing: ...

      C++ is probably implemented using Emacs LISP ... :-)

      [ Emacs' original/old logo was, literally, an overflowing kitchen sink. ]

      --
      It must have been something you assimilated. . . .
    2. Re:Make C++ simpler ?!? by Pseudonym · · Score: 2, Interesting

      You would have to remove things from it, not just keep adding every paradigm from every other language.

      Things are being removed from C++, but that's not the point here. You don't have to remove large slabs of the language, you just have to choose not to use them. The craziness that is C++ locales, for example, need not concern you because you won't use it.

      Modern C++ is mostly about not using implementation inheritance, which is the one thing that bitter experience has shown makes C++ software brittle. But you can't remove it from the language because all of that 1990s era hierarchical tarpit code wouldn't work then.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    3. Re:Make C++ simpler ?!? by ranton · · Score: 5, Insightful

      You don't have to remove large slabs of the language, you just have to choose not to use them. The craziness that is C++ locales, for example, need not concern you because you won't use it.

      This is only true if you are either working alone or have control over the development practices of your product team. And hopefully you never move companies or acquire a company that develops differently than you do.

      Otherwise every feature in your language of choice is something you may need to use if you are supporting work done by other developers who use that feature.

      --
      -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
    4. Re:Make C++ simpler ?!? by jargonburn · · Score: 1
      The truth about C++

      Interview with Bjarne Stroustrup

    5. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 1

      Bingo! As you add coders to a project -- now or in the past who have added to the legacy code base -- you dramatically increase the probability of running into crap features and crap coding practices.

      When I did a lot of consulting and custom coding, I ran into this constantly, especially when any of the C family languages were involved.

    6. Re:Make C++ simpler ?!? by OzPeter · · Score: 4, Informative

      You would have to remove things from it, not just keep adding every paradigm from every other language. That thing has everything and the kitchen thing: you can do pure C with it. Or (almost) pure Java. Or only macros and templates. Anyway one programmer's C++ program might as well be an alien language to another C++ programmer.

      I can't remember who said it, but they said that C++ is actually 4 distinct languages under one banner (from memory): Procedural, OOP, C-style Macros, and Templates.

      Each of them have different attributes and gotcha's.

      I used to know C++ fairly well in the late 90's, but when I look at the current state of it I tend to shake any head in wonder as to what it has become. Not only have there been so many new additions to it, there have also been completely new paradigms in how to approach it.

      --
      I am Slashdot. Are you Slashdot as well?
    7. Re:Make C++ simpler ?!? by tlhIngan · · Score: 1

      Things are being removed from C++, but that's not the point here. You don't have to remove large slabs of the language, you just have to choose not to use them. The craziness that is C++ locales, for example, need not concern you because you won't use it.

      Modern C++ is mostly about not using implementation inheritance, which is the one thing that bitter experience has shown makes C++ software brittle. But you can't remove it from the language because all of that 1990s era hierarchical tarpit code wouldn't work then.

      The problem is without compiler enforcement, someone might slip some of these features into the codebase.

      The compiler needs to have a bunch of feature switches you can disable (which is easy to do in a modern IDE or a makefile CFLAGS variable) so if someone even dares use a verboten feature for your project, the build will fail

      Otherwise the lack of some discipline can lead to problems down the road.

      And you can have sensible compiler defaults - it may be part of the language, but marked as "this is not recommended for use", which the compiler will error out on (but can be manually enabled using those feature switches) so old codebases can still use them, new code bases aren't using them, and it's effectively no longer part of the language as it's highly discouraged from use.

    8. Re:Make C++ simpler ?!? by ceoyoyo · · Score: 4, Insightful

      It's also only true if you ever only look at your own code. One of the most irritating things about C++ is that in order to understand someone else's code you have to first essentially learn a new language by going through the project's style guide. If they have one. And it's any good.

      Hey, I found this great open source project, I just need to add/tweak this little feature... OMG, KILL IT WITH FIRE.

    9. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      People use C++ because it has the strongest type system of any programming language you can use for work.

      Kotlin, Scala, and Haskell are laughing at this assertion.

    10. Re:Make C++ simpler ?!? by The+Evil+Atheist · · Score: 1

      And of course, the cure to having to learn new stuff in a language is to learn a completely different language every time. That'll teach 'em.

      --
      Those who do not learn from commit history are doomed to regress it.
    11. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      I was about to write something like this but suggest that the compiler warns on the undesired usage instead.

      But I guess that there are a lot of people out there who just accepts warnings without thinking.

    12. Re:Make C++ simpler ?!? by TheRaven64 · · Score: 2

      The craziness that is C++ locales, for example, need not concern you because you won't use it.

      Are you sure? I have a version of libc++ that works in the FreeBSD kernel, but I needed to do some quite drastic surgery to remove all of the locale stuff (which I really don't want in the kernel - anything that needs localisation should be done in userspace). A lot of the standard library depends on it indirectly and so I needed a lot of stubs to even let the standard library build.

      The C++ standard library could really benefit from some better modularity and layering. The core ADTs, the threading library, simple string handling, localised Unicode string handling, and so on should all be separated out and the dependencies between them made explicit. Unfortunately, the C++ standards committee is philosophically opposed to subsetting, which means that instead of a handful of standard subsets we have hundreds of per-project subsets.

      --
      I am TheRaven on Soylent News
    13. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      People seem to forget that C++ (originally, dunno about the current gcc suite)
      was written in The C Programming Language.

      CAP === 'coequal'

    14. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      As someone who worked with CFront I remember. C++ was pre-processed/transpiled into C then compiled with a C compiler when it first came out. At that time you had to add the pre-processor directive "Overload" to any overloaded methods so that it would name-mangle the function to keep it unique. I often think that going back to that starting point of C, adding support for method overloading, RTTI style automated initialize and cleanup, pass by reference and maybe smart_ptr capability (which might require operator overloading) would provide pretty much all of the capability I ever use out of C++. I'd even be ok with Java style single inheritance/multiple interface OOP if that was even needed.

    15. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      If code style confuses you, you should quit your day job

    16. Re:Make C++ simpler ?!? by AmiMoJo · · Score: 1

      C++ is the ultimate career armour. Pick an exotic C++, use it extensively in your business critical app, and you have a job for life because no-one else will touch it with a barge pole.

      Works particularly well for contractors.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    17. Re:Make C++ simpler ?!? by AmiMoJo · · Score: 1

      C++ is a Swiss army knife where half the tools are various calibre foot guns.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    18. Re:Make C++ simpler ?!? by DontBeAMoran · · Score: 1

      Besides that, their whole methodology is crap, as has been noted many times over: if there are plenty of messages asking for help on stackoverflow, maybe it's because users are struggling with a language, not because it's 'popular'. A language that is very easy to learn on your own wouldn't have any messages now would it ?

      No mod points today, so here's a "virtual +1 Insightful" for you.

      I also wish people would stop making such false correlations, it's almost as stupid as these ones.

      --
      #DeleteFacebook
    19. Re:Make C++ simpler ?!? by luis_a_espinal · · Score: 1

      I used to know C++ fairly well in the late 90's, but when I look at the current state of it I tend to shake any head in wonder as to what it has become. Not only have there been so many new additions to it, there have also been completely new paradigms in how to approach it.

      Same here. I used to program C++ with my eyes closed and get things done rather well and safely. But the language has moved beyond the realm of what I feel inclined to catch up. I do like some of the improvements in C++11, but wow, so many ways to blow your own foot now (as it if wasn't bad enough 20 years ago.)

    20. Re: Make C++ simpler ?!? by Carewolf · · Score: 1

      Well GCC uses some LISP internally. So in a way

    21. Re: Make C++ simpler ?!? by fahrbot-bot · · Score: 1

      Well GCC uses some LISP internally. So in a way

      I actually didn't know that, thanks!

      --
      It must have been something you assimilated. . . .
    22. Re:Make C++ simpler ?!? by Anonymous Coward · · Score: 0

      > I'd even be ok with Java style single inheritance/multiple interface OOP if that was even needed.

      Sounds like Objective-C to me.

    23. Re:Make C++ simpler ?!? by serviscope_minor · · Score: 1

      Unfortunately, the C++ standards committee is philosophically opposed to subsetting,

      Not when it comes to the library they're not. There's currently non hosted (no library) and hosted (with the library). There are proposals making their way through to make the non hosted one have some useful libraries.

      --
      SJW n. One who posts facts.
    24. Re:Make C++ simpler ?!? by Pseudonym · · Score: 1

      It's also only true if you ever only look at your own code.

      Clearly you haven't seen my pre-ANSI-era C++ code. It's... probably for the best.

      Having said that, I strongly disagree that C++ is especially prone to this. Yes, Qt is essentially a different language from C++ (say). By the same measure, Spring is essentially a different language from Java and every JavaScript framework is its own thing.

      The main difference is that C++ is both old and powerful. Like any piece of aging infrastructure, it needs a lot of maintenance (hence the busy C++ standards committee), but it also needs a compelling reason to replace it.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    25. Re:Make C++ simpler ?!? by Pseudonym · · Score: 1

      I am unclear on what problem is best solved by using libc++ in the FreeBSD kernel. Or most of libc, for that matter.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  3. Out of curiosity ... by fahrbot-bot · · Score: 2

    Anyone know what programming language (or other tool) is used to process the data and generate the TIOBE Index?

    --
    It must have been something you assimilated. . . .
    1. Re:Out of curiosity ... by Anonymous Coward · · Score: 0

      FORTH-79

    2. Re:Out of curiosity ... by Anonymous Coward · · Score: 0

      Pascal

    3. Re:Out of curiosity ... by Anonymous Coward · · Score: 2, Funny

      Most likely Node.js with 300 dependencies - one for each function call.

    4. Re:Out of curiosity ... by Anonymous Coward · · Score: 1

      LOL right in the vas deferens

  4. Viva C++! by Anonymous Coward · · Score: 0

    Lots of great improvements since C++11. Keeps on getting better!

    I just wish the syntax would look a little better for some of these improvements.

    1. Re: Viva C++! by Anonymous Coward · · Score: 0

      much simpler, safer and more expressive

      Hear hear. I couldn't agree more

    2. Re:Viva C++! by mschaffer · · Score: 1

      The syntax isn't that bad. I just wish they would do away with the header files, or at least make using them optional.

    3. Re:Viva C++! by DaphneDiane · · Score: 1

      Modules are coming.

    4. Re:Viva C++! by mschaffer · · Score: 1

      That's very interesting! Cannot wait to see it implemented.

    5. Re:Viva C++! by serviscope_minor · · Score: 1

      clang and VS have imlemented it, albeit at the moment two different versions of the draft standards. GCC has a WIP implementation that's woking but not complete.

      --
      SJW n. One who posts facts.
  5. SQL? Really? by Anonymous Coward · · Score: 0

    SQL is not a "programming language"

    1. Re: SQL? Really? by Anonymous Coward · · Score: 0

      no, not really, but it makes a lot of software better in the grand scheme of things and as complex as many "real" languages.

    2. Re: SQL? Really? by Anonymous Coward · · Score: 0

      Also, for the right job, it's much easier to read, modify, and verify than procedural languages. Yes, it can get very complex, but it decomposes nicely and captures a lot of application complexity in a very compact form.

  6. Much more bloated compilers too? by Anonymous Coward · · Score: 0

    While you can get code sizes in line with older C++ apps, at least in my experience compile times are taking a nose dive with each new revision of the language. C++98 between gcc 2.95 and 4.2 is noticable. 4.7 is slow, and everything since 4.8 is even worse. Lots of nice new eye candy and better error messages for sure, but if you're someone who has to compile a lot, particular in the process of trying to port older code with too many minor errors due to changes in headers, kernel APIs, function prototypes, etc between versions of the code, it take up dramatically more time waiting on it to compile or error out. Sometimes all that extra code is worth it, but many times it is not. Furthermore it now limits you to compiling on ever increasingly bigger systems because compiling a C++ program often requires a half to full gig of ram to compile an individual source file, and in some cases multiple gigabytes of RAM to link, excluding link time optimization!

    Seriously, I'm all for improvements in software, but maintainability, compile speed, memory footprint, etc apply as well, and modern software development is falling flat on all these fronts. Maybe it is time for some of these developers to be forced to build on something like a Raspberry Pi to remind them that not everything is an 8-20 core processor with 16+ gigabytes of RAM, and that the segmentation of your code and the optimizations you make on those smaller platforms will also translate into faster compiles and better performance on the big systems, which will translate into less time compiling and faster application operation when you get it feature complete or in publishable format.

    1. Re:Much more bloated compilers too? by Anonymous Coward · · Score: 0

      I agree with you, but at the same time, I just don't see there being much motivation to fix it. With 16GB of RAM (swap to disk disabled), a decent SSD, and "make -j 8" on a hyperthreaded quad core processor, even a largish project compiles in pretty much the blink of an eye for me. So much better than back in the day when I could go for a walk between compilation runs.

      With newer processors coming out with TONS more cores, it's just not going to be a big enough issue to shake a stick at. Even the ARM tablets/phones are having octocore processors these days, so if they ever get around to improving the disk storage speeds and RAM limitations, maybe they'll be just fine too.

      One area to keep an eye on is excessively nested #include's. In a small project, having lots of #include's in each .h file doesn't seem like any big deal. But after a while, all those .h files automatically #include a bunch of other .h files and you end up in a never ending tree of .h's getting included into every .cpp file your project has. You can eliminate a lot of nested #include's in .h files if you do a little local "class foo;" empty definitions instead of #include "foo.h" This will save a LOT a compilation time and also reduce the number of .cpp files that have to get recompiled whenever a small change is made to some distantly related .h file.

  7. Assembly by Ramley · · Score: 4, Interesting

    I was surprised to see Assembly in the top 10. Perhaps I shouldn't be, as I'm not in the world which uses Assembly, and I haven't even played with it since college back in the day.

    Forgive my ignorance here, but why the popularity of Assembly? It's impressive to say the least, but I'm unfamiliar with the world that lives in that language.

    Happy Monday!

    1. Re:Assembly by Anonymous Coward · · Score: 0

      Assembly is probably making a comeback with the popularity of microcontrollers

    2. Re:Assembly by Anonymous Coward · · Score: 0

      Happy Monday!

      No...
      Shit, NO, man!
      I do believe you should get your ass kicked for saying something like that.

    3. Re:Assembly by sconeu · · Score: 1

      My guess is embedded and things like 8-bit microcontrollers.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    4. Re:Assembly by chester_br · · Score: 2

      Maybe it's a side effect on how TIOBE measures "popularity" by looking at frequency in search engines - surely, that correlates with popularity, but also (IMHO) with complexity, which may have brought our friendly neighbourhood (Assembly) into the spotlight :-D

    5. Re:Assembly by chrism238 · · Score: 1

      I was surprised to see Assembly in the top 10.

      I'm wondering if it's growth in WebAssembly?

    6. Re:Assembly by Anonymous Coward · · Score: 0

      For speed and low overhead assembly wins every time.

    7. Re:Assembly by Anonymous Coward · · Score: 0

      Yes, in skilled hands. However, I've seen assembly code written by average programmers that is slower than careful C code. The C optimizer does a better job than humans in many cases. The C optimizer of course has an advantage -- no one has to maintain the code it generates so it can be very obtuse w/o causing problems whereas a human writing assembly code using the same approaches would usually be rightfully castigated for writing unmaintainable code.

    8. Re:Assembly by Prien715 · · Score: 1

      All code has to be written in assembly at some point. If you're making your compiler implement C++14 move semantics, for example, you may need to write portions of that code in assembly. If you create a new microcontroller, you'll also have to implement a compiler to assembly somewhere. Assembly is also hard thus lots of people are trying to find an answer and probably don't find the right answer the first time.

      --
      -- Political fascism requires a Fuhrer.
    9. Re:Assembly by Heir+Of+The+Mess · · Score: 3, Informative

      I wouldn't put too much faith in the TIOBE index, for example it shows VB.NET at number 5, above C# at number 6 which can't be right.

      I think you'll find PYPL to be a better indicator of language popularity which has VBA and VB in its proper place at #13 and #17 respectively.

      --
      Australian running a company that does C# / C++ / Java / SQL / Python / Mathematica
    10. Re:Assembly by Bite+The+Pillow · · Score: 1

      I use it at least once a week. To fix things that should have been fixed, by date or by contract. Either way, the code going to my CPU is my call to make.

      SoftIce anyone?

    11. Re:Assembly by antdude · · Score: 1

      I am surprised to see old languages listed like C++, ASM, etc. that I used back in college during the mid 90s.

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    12. Re:Assembly by Anonymous Coward · · Score: 0

      You should know assembly when you reverse engineer stuff (hack programs without source code). Perhaps that's where a good bit of the popularity comes from?

      But also: Popular by help forum posts? At best it is a combination of difficulty and popularity.

    13. Re:Assembly by Anonymous Coward · · Score: 0

      Saying "assembly" is popular is akin to saying talking is popular.
      There are inherent similarities between varieties of assembler, but also significant differences. I am reasonably familiar with x86 assembler (Win32 on MASM), but that doesn't mean I could read ARM assembler or Z80.
      There are also choices as to how far your assembler goes - at minimum it needs to convert opcodes to byte codes (e.g. mov , = OP_A, mov , = OP_B + etc.), tokenisation and basic setup. After that there are design choices - do you support macros, functions, type checking etc.

      There are very good reasons to learn assembler - if you've past the novice point there is much to be learned from digging a little deeper. I would never recommend people do serious projects in assembler, if you chose to you're either ready (and dedicated enough) or you very quickly learn why you probably shouldn't have chosen it!
      There is something very satisfying getting a task manager down to 3.5k on disk - doing every trick in the book to squeeze bytes out of your code. It teaches you a lot about how the compiler can make choices, and how you can think about code differently. It also teaches you that trying to maintain that sort of code is nearly impossible (I had to do things like push all the arguments to functions in one batch to keep them in registers (because push is shorter than push ) then make sequential calls).

  8. I was wondering about that also... by SuperKendall · · Score: 1

    I was curious if it was just x86 assembly, or all assembly across all processors (like ARM)?

    Some curious changes on that list...

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:I was wondering about that also... by Anonymous Coward · · Score: 1

      It only makes sense if it's all assembly across all processors. I'd guess ARM has a lot to do with it precisely because optimizing code for phones is actually a thing. Really there's no reasonable basis to avoid assembly language, and I doubt there ever will be. The closest you'll ever get is specific C code that tries desperately hard to qualify as C code and not butchered assembly. There's also the space of dynamic recompilers which can be written in C but often parts are still written in assembly at some point. Then there's of course the embedded space, although I've no idea how widespread that is vs more of a niche space.

    2. Re:I was wondering about that also... by Anonymous Coward · · Score: 0

      I'd guess ARM has a lot to do with it precisely because optimizing code for phones is actually a thing.

      It could be, but the entire embedded field is out there too.

      You have a fire alarm? Well, a microcontroller is probably reading a smoke sensor and also measures the battery to be able to generate different sound sequences randomly at night.
      Your car keys probably also uses a microcontroller.

      The thing with the entire embedded market is that software isn't sold separately.
      That means that the cost of CPU speed and memory isn't something that the customer is happy to pay for. (This isn't the case for phones and computers, in those cases the customers sees the upgrade as an investment that they are going to use for other software too.)
      In the embedded world every byte and cycle you can save actually has a value. Smaller controllers are cheaper.
      If you have a production run of a million units it actually makes sense to spend time optimizing everything if that means you can save $0.1 on the controller.

    3. Re:I was wondering about that also... by Anonymous Coward · · Score: 0

      Of course these days, all these things are probably running on a Cortex-M on new projects...

    4. Re:I was wondering about that also... by Anonymous Coward · · Score: 0

      I get what you're saying, but how many times do you rewrite the code for the fire alarm? How many companies are out there making new fire alarms with new code? The embedded space exists and it's relatively large and varied, but you only save that $0.1 on the controller if you don't have a large team of programmers constantly writing code for it. That's why I'm dubious of the embedded space explaining a substantial amount of the popularity numbers. To get into popular space, you'd probably have to either be used everywhere to some degree or have segment space which massive uses it. I don't think embedded alone is massive enough to qualify.

  9. Use whitespace syntactically... by John+Guilt · · Score: 2, Informative

    ...and you oughtn't be anywhere near the top. Just my absolutely accurate and precise opinion.

    1. Re:Use whitespace syntactically... by hazem · · Score: 4, Insightful

      You're getting marked as flame-bait, but I agree. Try reading (and typing in) code from a book with C (or practically any other language), and you'll have no problems. Try the same with a book with Python code that spans a page-break, and you'll have to break out a ruler to figure out the correct number of syntactic spaces.

      It's a fine scripting language, but it's hard to take seriously with limitations like that.

    2. Re:Use whitespace syntactically... by John+Guilt · · Score: 1

      Did the second sentence make the difference? If so, that were inept on my part as I was trying for self-mockery.

    3. Re:Use whitespace syntactically... by ebvwfbw · · Score: 1

      Sounds like you don't know python. I'm an old time C guy. Over 35 years. It's great for certain things. I still code in it. However for a lot of things I can whip out a program in python that is right in an afternoon and I don't have to ever touch it. C - it'll take me far longer to do the same thing. I'm fairly good at getting it right the first time, however I still end up having to change things later. Method is the same for me. All the steps are in my mind, then I type it right in.

      Python is a very serious language. If you don't know it, you don't know what you're missing.

      Next thing I know you'll be telling me you don't even know Emacs.

    4. Re:Use whitespace syntactically... by Bigjeff5 · · Score: 1

      I'm sorry but that sounds exactly like what you would use a scripting language for - quick hack-together solutions to immediate problems.

      I know Python can be used for far more than just scripting, but it definitely feels like you supported his point more than argued against it, as seems to be your intention.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    5. Re:Use whitespace syntactically... by Anonymous Coward · · Score: 0

      Next thing I know you'll be telling me you don't even know Emacs.

      It's not a question of not knowing Emacs, it's more a matter of running the other way, very quickly.

      Given the prevalence of Carpal Tunnel problems of this day and age, I can't see anybody with any sense choosing to use Emacs ... If the choice is between vim and Emacs, one should choose vim.

    6. Re:Use whitespace syntactically... by ebvwfbw · · Score: 1

      I could see how you would think that. Sometimes I write quick stuff to solve something, though it could be in perl, or even awk. In fact if it is something quick I wouldn't use python because it really has to line up properly, so we're talking about a file. I don't want to bother with a stinkin' file.

      By whipping out something in an afternoon I had more in mind something like taking stock market data and running it through tensorflow. Recently I ran wifi data from a kismet session through to find something specific. I'm perfectly capable of doing both of these programs in c++. Question is - why would I? Only if there is a specific need. Like whatever it is has to run on something slow and cycles matter. System on whatever it's running on is small. Sometimes both. The other reason is system things, like a device driver.

      I remember over 20 years ago I had all kinds of C programs. A lot of them ran every day. This is back in the days when 16 meg of memory was a lot. I re-wrote them all in Perl. I found about a 5-1 reduction in lines and the code was clearly a lot easier to understand and maintain. Python I'm seeing about a 12-1 reduction from the old C code. Just have to think in the pythonic way.

  10. 1998 by Anonymous Coward · · Score: 0

    Stroustrup should have stopped in 1998 adding crap - maybe even back in 1992; I don't use any of the features that were added after that. Unfortunately, many many C++ coders do and it looks like a completely different language.

    C++ has become this horribly over complicated language that produces bloated runtimes.

  11. a better name for this index would be... by Anonymous Coward · · Score: 0

    Languages people need the most help with because it's based on search engine queries. This could just as easily mean rather than most popular, it's a list of the language most cursed by those forced to deal with them.

  12. VB.NET is higher than C#. Oh, really? by Anonymous Coward · · Score: 0

    That point alone makes me very much doubt the reliability of the data I know a lot of .NET developers, with only 1%2% still using VB.NET. Also - Javascript, something that is used by pretty much every single website, is # 7?

    1. Re: VB.NET is higher than C#. Oh, really? by Anonymous Coward · · Score: 0

      There must be a whole lot of world outside your bubble.

  13. Namespaces in C by darthsilun · · Score: 4, Interesting

    Could we just have namespaces in C? Maybe reference types?
    Or pushing the envelope, how about a simple single-inheritance class model? It seems like every project I've ever worked on has jumped through hoops creating a simplistic "object" model.
    I've already been down this road once (or twice). We used C++ with no boost and limited to a very small set of features (well documented). But then along came someone who just wanted to use one little thing in boost. Or some other thing no on the list.
    And then the long slide down the slippery slope began.

    1. Re:Namespaces in C by Anonymous Coward · · Score: 0

      Maybe something like EC, or fork/continue to develop Objective-C? Maybe D, Nim, or Rust?
      https://en.wikipedia.org/wiki/...

    2. Re:Namespaces in C by goose-incarnated · · Score: 2
      I hear you!

      Or pushing the envelope, how about a simple single-inheritance class model?

      I have this. I wrote a parser that reads in class definitions and spits out structs. Fields that are inherited from parents and marked as public are placed into the struct directly, and getters/setters are generated automatically for each field.

      It turned out less useful than I thought - for a feature to be useful it has to be part of the standard, not an add-on, else other programmers won't want to use it.

      --
      I'm a minority race. Save your vitriol for white people.
    3. Re:Namespaces in C by Drethon · · Score: 1

      Could we just have namespaces in C? Maybe reference types?

      Or pushing the envelope, how about a simple single-inheritance class model? It seems like every project I've ever worked on has jumped through hoops creating a simplistic "object" model.

      I've already been down this road once (or twice). We used C++ with no boost and limited to a very small set of features (well documented). But then along came someone who just wanted to use one little thing in boost. Or some other thing no on the list.

        And then the long slide down the slippery slope began.

      Libraries like boost all seem to be a balancing act between reinventing the wheel and having to deal with a library that does mostly what you want, but not quite the way you want.

  14. CLICKBAIT VIDEO SPAM by michaelcole · · Score: 3, Informative

    This article is a video rehash of a 6-month-old yearly survey.

    What you're looking for is here: https://www.tiobe.com/tiobe-in...

  15. VB.NET? by NerdENerd · · Score: 4, Informative

    As a 15 year .NET veteran I call bullshit on VB.NET being so popular. Nobody uses VB.NET and .NET developers laugh at you if you do.

    1. Re:VB.NET? by Anonymous Coward · · Score: 0

      If you code in .NET you aren't a "real developer."

    2. Re:VB.NET? by phantomfive · · Score: 1

      I happen to know that the US military uses VB.NET, though frankly, the whole .NET community can burn for all I care. The Javascript community is crazy, but at least they don't glorify ignorance the way the .NET community does.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:VB.NET? by Anonymous Coward · · Score: 0

      Citations, or shut the fuck up

    4. Re:VB.NET? by JoeDuncan · · Score: 1

      I happen to know that the US military uses VB.NET

      Well, that certainly explains how they spend more money on military than the entire world put together, but are still effectively useless.

    5. Re:VB.NET? by Anonymous Coward · · Score: 0

      Alot of finance folks use VB.net with Excel...

    6. Re:VB.NET? by Anonymous Coward · · Score: 1

      I wrote in VB.NET between 2006 and 2012 or so... it's fine. I did eventually move to C# as I got more into javascript, since the syntaxes were similar.

      The real evil of .NET is the default components/controls - with the exception of linkbutton and placeholder they're all terrible and worthless.

  16. Most Puzzling Computer Languages by Tough+Love · · Score: 3, Insightful

    What TIOBE measures: how puzzling a language is to how many Stackoverflow members. So C++ can win, even if it used by fewer Stackoverflow members, because it is more puzzling.

    Of course, in order to have any users at all, a language must make itself useful, which C++ does by a variety of metrics, but most notably efficiency. If you care about getting the most bang for your buck out of your expensive, power hungry data center, then you hire more expensive developers and do the job in C++. If you care about lowest possible latency in a financial trading platform, again you do the job in C++. Go ahead, try it in Python. You can do it, it has been done, but you will get eaten alive in the trading jungle.

    --
    When all you have is a hammer, every problem starts to look like a thumb.
  17. C++ isn't a language by Anonymous Coward · · Score: 0

    C++ is like dogshit. It's got bits of this, bits of that, and is mostly indigestible. There's more similarity between C and "classic" C++ than there is between "Modern C++" and the classic.Using C++ without the outdated and buggy Standard Type Library - or some equivalent - is useless. It is a fucking awful language. Given an input 1E7FUBAR what do you suppose int X; cin >> X; gets you? Wouldn't you expect it to throw an error? Nope. And God help you if you typed cin X;
    C++ is like one of those 20 pound (10 kg) Swiss Army knives. You can do almost anything with it, except use it.

    1. Re:C++ isn't a language by Anonymous Coward · · Score: 0

      And this is why I switched to Ruby

    2. Re:C++ isn't a language by Anonymous Coward · · Score: 0

      Wow, with your example of how "terrible" C++ is, you show us that your coding skill is well below average. Car analogy - you're bitching because it's a manual transmission and what a godawful noise it makes if you forget to use the clutch.

  18. Drivel of cute languages by Anonymous Coward · · Score: 3, Insightful

    Career advice: Ignore the drip drip of new rising star languages and the drivel of proponent's blog entries.

    There are jobs out there for general purpose languages only occupying a niche of the total number of programming jobs. Becoming an expert in one of those narrowly used in paid jobs languages is a hobby and not a career move.

    Case in point: Search for jobs where Ruby is the main programming language versus Cobol jobs. Cobol's been on the skids since the middle 1980s and has more jobs than many of the once over hyped programming languages of the 90s and 2000s.

    Blogs, magazines, podcasts, etc. have space to fill and it's much easier to cover the new language, library or tool of the month versus giving in depth information on a well established technology. It's why many sites gravitate to a list of links to what essentially are press releases or blog entries promoting the author's own project.

     

  19. Python was previously in the top 3? by Anonymous Coward · · Score: 0

    The Slashdot title with "C++ Knocks Python Out of Top Three in New Study" seems to suggest there was a year when Python was in the top 3 in the TIOBE. But I have am having trouble finding the year that it was in the top three to be knocked down from. In 2018 it was in 4th place so it wasn't knocked down in position between 2018 and 2019. The TIOBE very long term history shows Python being in 7th position back in 2014 but never shows a year that was higher than 4th.

    Really, the Slashdot title does not seem to be a good reflection of Python status on the TIOBE at all. I find it more interesting that while C++ held it's 3rd position on the index, it only gained 1.62% from 2018 to 2019. Python on the other hand gained 2.36%. If that trend was to continue between now and 2020, Python could possibly reach 10.5% rating on the TIOBE in 2020 while C++ would only potentially reach 10.4% which would mean it is C++ that is in line to be knocked down from the top three by 2020.

    How Slashdot can see Python gaining +2.36% and refer to that as being knocked out in a new study just does not seem logical to me. No other language on the TOIBE top 50 for April 2019 had gained as great as Python had on the index rating.

    Can anyone explain the title of this post to me??

  20. LOL, C++ 2011: much simpler, safer and more by halfdan+the+black · · Score: 2

    LOL, C++11 has made said made C++ "much simpler, safer and more expressive." That's got to be one of the most bizarre statements I've ever read.

    More like template meta-programming has increased the language complexity by several orders of magnitude. At least you could step through pre-templatized C++ and understand control flow. With these template meta-programming, the language is completely and utterly incomprehensible, they've truly made it a "write only" language. Case in point, take a look at Eigen.

    No, C++ just needs to die, the standards committee just can't seem to figure out how to simply the language, and please the meta programming language geeks. C++ needs to die and get replaced by something like Go or Rust.

  21. Golang is the future by skinlayers · · Score: 3

    C++'s days are numbered.

    https://en.wikipedia.org/wiki/...

    "The designers were primarily motivated by their shared dislike of C++."

    References:
    "Dr. Dobb's: Interview with Ken Thompson": http://www.drdobbs.com/open-so...

    "Less is exponentially more": http://commandcenter.blogspot....

    ""The Evolution of Go": https://talks.golang.org/2015/...

    And I'm not the only one who agrees.

    "Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C"
    https://slashdot.org/story/334...

    1. Re:Golang is the future by Anonymous Coward · · Score: 0

      Go Lang is nice, and I think will replace a lot of c++. But tons of c++ just can’t be garbage collected. I assume these people will move to something like rust. Although in cpp11 it is fairly easy to scope to similar semantics as rust people seem to be more willing to rewrite into rust.

    2. Re:Golang is the future by Anonymous Coward · · Score: 0

      straight up though, golang is awesome. The package system embeds namespaces and keeps separate code separate. Channels are so nice other languages try to make their own implementations of them. Implicit interface compliance is nice. Explicit error handling in tuple returns makes handling errors front and center. Honestly if there was a better way to manage memory without using garbage collection golang would be one of the best replacements. Add in that vulkan isn't main thread bound like opengl and we can clearly see a future of much simpler multi threaded game applications built on a much simpler language.

    3. Re:Golang is the future by serviscope_minor · · Score: 2

      C++'s days are numbered.

      Techincally everything's days are numbered.

      "The designers were primarily motivated by their shared dislike of C++."

      Euch. You could insert "irrational" or "misinformed" into that sentnce. I use C++ a lot. I could give you a long list of complaints about it. A very long list. There are things I'd love to see fixed, or a "better" language replace it.

      That language isn't golang.

      In fact that article you posted:

      "Less is exponentially more": http://commandcenter.blogspot....

      Basically degenerates into a whiny rant about go is too awesome for C++ programmers and that's why C++ programmers have been pretty uninterested in go. It seems he can't really cope with the possibility that go isn't that amazing and certainly doesn't cover as many use cases as C++.

      "Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C"

      Yeah well, ESR is a bit of a plonker. What are you going to post next? His guide to sex? (no realy this is a thing http://www.catb.org/esr/writin...)

      --
      SJW n. One who posts facts.
    4. Re:Golang is the future by Anonymous Coward · · Score: 0

      > C++'s days are numbered.
      > [Go (programming language)]
      > "The designers were primarily motivated by their shared dislike of C++."

      To misquote Henry Spencer:

      Those who don't understand C++ are condemned to reinvent it, poorly.

      To understand why C++ is the way it is, and why it is popular:

      https://youtu.be/ltCgzYcpFUI

    5. Re: Golang is the future by Anonymous Coward · · Score: 0

      ESR is a god. He's given more to linux and done more for open source than anyone. He's smarter and more capable than all the current crop of SJW idiotarians who rule over the linux ecosystem put together, including the dumbass in chief linus torvalds.

    6. Re:Golang is the future by squiggleslash · · Score: 1

      I'm not exactly a fan of C++, and would like to see a decent programming language take over from it, but what makes you feel that Go is that language? It's the internal programming language of one company who hasn't done anything to encourage development in Go in the projects its released. Chrome/Chromium (and Blink) is still 100% C++ (even Firefox is putting its money where its mouth is with Rust), Java is still the only first class language supported by Android, with C++ getting more support for that platform than Go.

      If Google's not going to push Go, then who is?

      --
      You are not alone. This is not normal. None of this is normal.
    7. Re:Golang is the future by Anonymous Coward · · Score: 0

      Isn't Kotlin first class for Android?

    8. Re:Golang is the future by squiggleslash · · Score: 1

      Yes, you're right, I forgot Kotlin, but obviously that only underlines how little support Google is giving Go.

      --
      You are not alone. This is not normal. None of this is normal.
    9. Re:Golang is the future by strikethree · · Score: 1

      The language Go is not going anywhere. I don't know how to verbalize what I am seeing in my mind, but the summary is that Go is, ultimately, a dead language.

      Here is a best effort (very bad results):
      You need to be able to address all aspects of reality for a programming language to be generically useful. Go limits the ways that you can address reality; therefore, it can never replace C or Assembler.

      It is impossible to create a powerful tool that is NOT dangerous in the wrong hands. Go is like handing a soldier a weapon that can only fire when it is in contact with a base station authorizing it to fire. Sure, it can work and be useful... but the failure modes are... hilarious (in a bad way).

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    10. Re:Golang is the future by Anonymous Coward · · Score: 0

      So ... Did Go ever solve its problem with (lack of) generics?
      Can I write Go programs without a garbage collector?
      How about transparent error propagation with automated resource release?
      Stack only allocation? (i.e., no dynamic memory).
      No? OK, then, go play with your toys, the adults will do some actual work now.

  22. Useless measure by Anonymous Coward · · Score: 0

    Any language measure that doesn't put Swift at the top is useless. Its the best language and used by all the top developers in the world.

  23. The Truth by Anonymous Coward · · Score: 0

    The only reason C++ is ranked is because it compiles C because it is C.

    ------------------ END OF STORY ------------------

    1. Re:The Truth by Anonymous Coward · · Score: 0

      Cool story bro

  24. Be computer scientist, not a programmer by Anonymous Coward · · Score: 0

    Memory management seems to be the thing that scares the hell out of noobies learning C++. This is a lot less daunting if you understand how the runtime you are targeting manages heap space. Don't know/care what the difference is between stack and heap storage spaces? Keep on hacking Python scripts, kid. There's plenty of H1-Bs out there that will code circles around you.

    No, I don't have time to be your CS prof while doing your job and my own at the same time.

  25. Nice joke. by Anonymous Coward · · Score: 0

    Not a real interview, if that wasn't clear.

    I've seen C++ save companies because the code was too complex for structured languages.

    As for reuse - we reused all sorts of common classes. Fixes were shared across 20 different programs and helped the entire software company.

    We had programming standards which didn't allow overloading operators unless is was so intuitively clear that it wouldn't be confusing.

    We used inheritance, but not multiple inheritance. Coding standards.

    Coding standards help new programmers learn defensive coding. C is 100% offensive coding, but so is Java, Javascript, Python ... I'm offended every time I'm forced to deal with code in those languages.

    At this point in my career, I'd coded in over 40 languages and consider myself expert in 3.

    Rust and C# need to die, die, die. If you suck as a programmer, stick with php or Python. Do the world a favor. We expect those programs to crash, fail, leak, and be slow.

    1. Re:Nice joke. by Anonymous Coward · · Score: 0

      jack of 40 languages

      master of none

      do the world a favor and kill yourself

  26. The problem with C++: Insufficient documentation. by Futurepower(R) · · Score: 1

    "You would have to remove things from it, not just keep adding every paradigm from every other language."

    That's not the problem, in my opinion. It's good to have all the possibilities, even if they are rarely useful.

    One of the problems with C++ is that NONE of the rarely useful features are documented well. The rarely useful features should be documented with warnings about the messes that are created when they are used in a way not intended.

    I have never seen excellent documentation of ANY features of C++. People who design computer languages are apparently generally not good at professionally careful and helpful communication.

  27. Sometimes Assembly language is the easiest. by Futurepower(R) · · Score: 1

    "... all assembly across all processors..."

    Sometimes Assembly language is the simplest, most easily understood way of coding something.

    1. Re:Sometimes Assembly language is the easiest. by Anonymous Coward · · Score: 0

      > Sometimes Assembly language is the simplest, most easily understood way of coding something.

      Only if your problem domain is simple. If you need any abstraction at all, assembly is a royal pain.

      "We can solve any problem by introducing an extra level of indirection...except the problem of too many levels of indirection."

  28. Interesting. Excellent point. by Futurepower(R) · · Score: 1

    Mod parent up. Excellent point:

    "The C optimizer of course has an advantage -- no one has to maintain the code it generates so it can be very obtuse w/o causing problems whereas a human writing assembly code using the same approaches would usually be rightfully castigated for writing unmaintainable code."

    1. Re:Interesting. Excellent point. by Anonymous Coward · · Score: 0

      People always make this point, but in practice, it's ridiculous. ANYBODY can EASILY beat the compiler's assembly language code. Just use "gcc -Os -S myprog.cpp -o myprog.S" and start with the compiler's assembly language code. After getting your bearings of where things are and what the compiler did, you start making little optimizations here and there and before you know it, you've got assembly code that is far tighter and better than what the compiler did. There is just no excuse for doing worse than the compiler.

    2. Re: Interesting. Excellent point. by Anonymous Coward · · Score: 0

      Not -O3? While hand assembling for speed was fine and dandy in the past, cache lines, branch mispredicts, data alignment and a slew of other gotchas mean that although you can count the basic T-state count of your code and confirm its lower than the compiler produced, in reality your code will be way slower.

    3. Re:Interesting. Excellent point. by TheRaven64 · · Score: 2

      If you're starting with -Os, then your baseline is optimising for size, so presumably that's what you care about. To beat it you need to either remove instructions entirely, replace multiple instructions with a shorter sequence, or pick instructions with shorter encodings. All of these are things that are really easy to automate. Most of the bloat comes from ABI constraints, and if you pass the right flags the compiler will ignore these (e.g. omitting the frame pointer).

      If you're optimising for speed, then start with -O3. At this point the compiler has already done things like loop rotation, common subexpression elimination, and autovectorisation. You might be able to beat it, but even understanding what the code is doing for a nontrivial example is quite hard.

      --
      I am TheRaven on Soylent News
  29. I stopped at TIOBE by Anonymous Coward · · Score: 0

    That scumbag of indicies. All it measures is how often the term "programming +language" appears in Google.

  30. Re:The problem with C++: Insufficient documentatio by Anonymous Coward · · Score: 0

    ISO-C is pretty well documented.
    It's when you use things that are "compiler defined" that things gets iffy since you then have to rely on the compiler documentation.

    Also, many "languages" aren't really languages but rather a compiler or interpreter that does something and whatever it does is called the "language".
    Anyone who tries to write another compiler for the language is just looking for problems because every bug in the original interpreter needs to be recreated for compatibility.

  31. the honest ruth about value by epine · · Score: 1

    You would have to remove things from it, not just keep adding every paradigm from every other language.

    You're addressing inherent simplicity: simplicity that inheres in the object itself. Inherent simplicity is overrated.

    Not so simple: maintaining your own fork of a major development language, because a recent major release— in pursuit of round-fingered, bent-legged enlightenment—gored your ox on a multi-million-line code base.

    Our quest for simplicity is quite primal. It's often just a power move to demonstrate that you occupy the summit of the power hierarchy. Because your vaunted simplicity usually amounts to making something ugly (but very, very real) into somebody else's ugly (and very, very soul-destroying) daily slogathon.

    The C++ culture is what you get when there's an iron-clad social contract that Peter does not rob Paul.

    The direct consequence of this is that nobody can stand on the summit and gloat about their immensely refined slickitude (to hell with the peons working the actual trenches).

    As has been remarked once or twice in the history of Slashdot, C++ lacks any semblance of pointy summit of slickitude; no—father forgive me, for I have sinned—C++ lacks any possibility of a semblance of so much as a stubby, manicured outcropping of soapbox sainthood.

    The only other language I know with a similar value system is Perl 6.

    Evan Miller: A Review of Perl 6 — 13 August 2017

    It doesn't help that the purveyors of Perl 6 provide few hints as to what you should actually do with the language, besides the facile answer of whatever you want. Perl 6 is multi-paradigm, maybe omni-paradigm; it claims to support object-oriented programming, functional programming, aspect-oriented programming, array programming, and (good old) procedural programming.

    It's a new language, and not just a cleaned-up version of Perl 5, any more than English is German minus the umlauts.

    Knowledge of previous versions, alas, won't get you very far. By the same token, prejudices regarding the preceding incarnations don't necessarily hold today's water.

    The difference between C++98 and C++11 is roughly the same thirteen years that the Perl 6 development effort went almost entirely offline. Perl 6 probably shaved off no end of warts to achieve its grand synthesis of becoming all things to all people (forsaking mainly performance, though this is prudently localized—in many cases—to quality of implementation). Meanwhile, C++ dragged its crufty ass through tens of millions of battle-hardened hours in the deep trenches. Will Perl 6 ever achieve the quality of implementation required to obtain a community of critical mass, to justify the immense implementation burden? This remains hard to judge.

    I've long taken a Band of Brothers attitude toward C++.

    Yes, you can shoot yourself in the foot, if your team is some random unit of random grunts.

    But if your team is elite, and cares about being elite, you just don't shoot yourself in the foot on a daily basis, and you don't shoot your teammates in the foot hardly ever, and you go into the worst battles with the best people, and mostly you come back out alive. With C++, there's no such thing as bad weather, there's only bad clothing. The clothing is your job. Other languages do have bad weather—tasks for which the language is fundamentally unsuited—and then there's no clothing at all that will save you, and then you're fucked.

    If the guy you're sitting beside has recently graduated from a puppy mill, and has no respect for the game, you probably want to steer clear of C++ with a vengeance of extreme scorn.

    If the guy you're sitting beside has recently graduated from an ivory tower—with a raging case of L

    1. Re:the honest ruth about value by hawk · · Score: 1

      >, and you go into the worst battles with the best people, and mostly you come back out alive

      All in all, I think I'll choose a programming language that lacks an intrinsic ability to *kill me*!!!!

      *shudder*

      hawk, who has never even *worried* about dying while programming before . .

  32. Re:The problem with C++: Insufficient documentatio by vyvepe · · Score: 1

    Get a draft C++ specification. The final versions are ISO standards and not available for free. But drafts are good enough.

  33. The C++ standard is UTTER GARBAGE, says ISO CPP. by Futurepower(R) · · Score: 1

    FAQs:

    "Q: Why is the standard hard to read? I'm having trouble learning C++ from reading it.

    "The standard is not intended to teach how to use C++. Rather, it is an international treaty -- a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.

    "Fortunately, there are lots of good books that do teach how to use C++! See these recommendations as a starting point for high-quality tutorial and reference information about how to learn and use C++."

    Free book about C++ (PDF file): A Tour of C++ by Bjarne Stroustrup.

    I doubt the problems are solved by that book. But I haven't yet investigated.

  34. Re:The C++ standard is UTTER GARBAGE, says ISO CPP by serviscope_minor · · Score: 1

    The C++ standard is UTTER GARBAGE, says ISO CPP

    You're a fuckwit says you.

    I mean that statement has about as much logic as your post.

    --
    SJW n. One who posts facts.
  35. Poor technology documentation is a HUGE problem. by Futurepower(R) · · Score: 1

    Quoting from ISO CPP: "... sometimes mind-numbingly detailed technical document..." I translated "mind-numbingly" to "utter garbage", an exaggeration, I agree.

    Poor technology documentation is a HUGE problem. "Mind-numbingly" is just one of the problems with poor documentation. Bad documentation discourages people from entering a technical field. Poor documentation sometimes makes fixing coding errors FAR more difficult.

    Also, personal attacks are unhealthy for the attacker.

  36. Re:Poor technology documentation is a HUGE problem by serviscope_minor · · Score: 1

    I translated "mind-numbingly" to "utter garbage", an exaggeration, I agree.

    So you translated one thing to something completely different. It would make sense if the ISO's job was to entertain. But it's not. Boring/exciting is not within the remit of the ISO and frankly is not an issue for standards.

    Poor technology documentation is a HUGE problem. "Mind-numbingly" is just one of the problems with poor documentation.

    Lack of precision for for a standard is a bigger problem then being boring. Much bigger.

    You're lumping in user guides, getting started tutorials with standards, which is frankly facile. The goal of a standard is not to entertain, it's so that two gery techincal groups can without talking to each other make two implementations of something which behave in a consistent manner.

    A standards documentation is needed so that I can determine if struct {int a;b;} a; &(a.a)+1; is valid.

    Also, personal attacks are unhealthy for the attacker.

    So why did you do it then? You started off on the attack about a group of people some of whom I've worked with.

    --
    SJW n. One who posts facts.