Slashdot Mirror
C/C++ Back On Top of the Programming Heap?
Drethon writes "On this day in 2008, a submission was posted that C/C++ was losing ground so I decided to check out its current state. It seems that C has returned to the top while Java has dropped by the same amount, VB and PHP have dropped drastically, C++ is holding fast but now in third place and Objective-C and C# have climbed quite a bit. 2008 data thanks to SatanicPuppy: 1. Java (20.5%); 2. C (.14.7%); 3. VB (11.6%); 4. PHP (10.3%); 5. C++ (9.9%); 6. Perl (5.9%); 7. Python (4.5%); 8. C# (.3.8%); 9. Ruby(2.9%); 10. Delphi (2.7%). The other 10 in the top 20 are: JavaScript, D, PL/SQL, SAS, Pascal, Lisp/Scheme, FoxPro/xBase, COBOL, Ada, and ColdFusion."
the whole OS is compiled in C++
How comes the summary list doesn't correlate at all with the list on the article?
And you know your language is dead when it's less popular than Lisp.
I would expect that a lot of companies are probably working on importing their legacy systems to work for the new 64 bit systems.
Now that most PC's are out with more then 4 gigs of RAM. Many OS's are going towards 64 bit OS's and a lot of those old 32 bit systems programmed in C for performance, needs to be upgraded.
A lot of those programs that seemed to run fine in windows 3.1 are finally stop working in windows 7 64 bit.
I am not saying C coding is just for legacy systems, but a good amount of legacy systems are written in C, and most of those C written programs are fairly optimized for their platform they were designed to run, and we are starting to switch to 64 bit and multi-core architecture.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
C and C++ are two separate and very different languages.
My two favorite languages aren't dying!
Whatever anyone else thinks, I think they're not only extremely solid languages that have stood the test of time, but they're both really fun to program in. I know it's at least somewhat subjective, and right tool for the job and all, but that doesn't mean you can't have preferences and it's good to see the "Yankees" of programming not headed into obscurity.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Will Java drop even further because of the whole Oracle mess?
I guess I am surprised that Python is ahead of C#, and that Ruby is so low given its underground buzz.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Is this the same C that is ignored by almost every developer in the field in lieu of more "business-friendly" languages that add bloat and inefficiency?
That's interesting to me that PHP is more popular than a language like C#. But I guess when you include VB and all of its legacy, then the whole ".NET" stack is quite a bit more popular.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
Of this list, C#, Ruby, and Python are clearly the best languages as far as I'm concerned.
;)
The C++ longevity is expected. Every engineer worth his weight in salt should be able to write C++ code. (get off my lawn etc.)
I am curious abobut where the C growth is coming from. Embedded stuff? Native libraries for the increasing volume other higher level languages?
The Tiobe index is a popularity contest - a pageant for programming languages - so, you get the trend on what's hot, but that is just part of the IT business.
I challenge you to find 5 banks whose core are not built with Cobol, for example.
My point is that real use != trending languages
The trend after the web became big in the mid-90s was to find specialized languages and try to code in those.
The trend has swung backward. People are now looking for general purpose languages. They want Swiss army knives, not specialized tools.
The Windows OS kernel is mostly in C with some assembly (just like Unix/Linux/BSD/OSX). The Windows GUI is mostly C++ (but so is KDE).
Support Right To Repair Legislation.
Because you NEVER have enough speed. Besides most useful libraries are written in C or C++
and lather binds are built for other languages. So, if you want or need to use the latest
version, or the library hasn't bindings, you must go for C or C++.
The 20th language is NXT-G. What the fuck is that? Is it really lego's programming language for robots as wikipedia indicates (http://en.wikipedia.org/wiki/NXT-G) ? And that is more popular than bash or matlab?
From the article: "Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written." [Emphasis added]
It's a survey, no more, no less. Using it to make decisions about your career is foolhardy at best.
If I used a sig over again, would anyone notice?
C++ is the hard core, it must work, programming language of choice. The F-35's software is being developed in C++.
I thought they were counting actual use, and not vague childhood memories?
It's unbelievable that people still pay any attention whatsoever to it. Some company comes up with a ridiculous 'methodology' to gauge the popularity of languages, and people assume that it's actually related in any way to reality.
Further reading:
The best place to start is at TIOBE's own methodology description page: http://bit.ly/h3ftBa
No need to go much beyond that, to figure out that it's a meaningless index. To save you the reading, it more or less boils down to this:
---
The ratings are calculated by counting hits of the most popular search engines. The search query that is used is
+" programming"
---
That's all.
Still need some more convincing:
Why TIOBE isn't all that useful (mild): http://bit.ly/IeG0yA
The TIOBE index is being gamed: http://bit.ly/IeGnt1
It's no short of ridiculous. Time to stop paying attention to it, move along!
The whole survey looks odd to me. I work on MS sites and a decade or so ago, there was quite a lot of C around, but with today's hardware, I hardly see any of it now. Maybe I'm hanging around in the wrong sites or job boards, but most of the demand on places like Jobserve seems to be around .net, Java and php. Any chance that this survey is including a load of c# results in c?
Sure. As soon as someone comes up with a language that produces code that runs half way as fast as C on any OS, and that at least pretends to integrate with the rest of the OS. You know, make it nice for everybody else other than developers. Oh, here's a though: how about developers get their heads out of their butts and learn how to be programmers, instead of whining that real languages don't do everything for them?
What compiler are Pascal developers using that isn't Delphi. Aren't most Pascal compilers capable of handling Delphi's Object Pascal anyway?
Shouldn't the Pascal and Delphi be combined into one grouping the way that all the different C++ are combined?
A shout goes out to this site which actually does a pretty good job of comparing all the languages on 'subjective' attributes such as "I find it easy to write efficient code in this language" (C being top here), or "Code written in this language tends to be verbose" (Cobol and Assembler are worst here, but Java is 3rd place, and that's bad considering it's meant to be a modern higher level language).
You can even click each language and see what comment it is best for. For example, Haskell is top for "This language has a strong static type system" and "When I write code in this language I can be very sure it is correct". Meanwhile, something like PHP is top for "I am sometimes embarrassed to admit to my peers that I know this language" and "This language has many features which feel "tacked on"".
Why OpalCalc is the best Windows calc
Java floating point management is flawed by design. Using java for controlling anything serious opens up a Pandora box: just look at this (and look here if you don't know dr. Kahan)
Because we can't trust programmers to be smart enough to avoid these conditions...?
My pocket knife can be used in a completely safe manner. It can also be used in a completely unsafe manner. How it's used it up to me. Because it can be used dangerously doesn't mean that we shouldn't have pocket knives.
Strange, Classic ASP doesn't seem to be on the list anywhere. Some people where I work seem to think that our "enterprise" processing system is just fine written in Classic ASP. Well, at least they migrated most of the Access crap to Classic ASP. Baby steps.
If you are not allowed to question your government then the government has answered your question.
Modern OS protection schemes make it very, very, very difficult to actually exploit buffer overflows nowadays. Coders really ought to be knowledgeable enough to avoid making the mistakes on their own anyhow.
JOSS?
* http://www.tiobe.com.nyud.net/content/paperinfo/tpci/images/tpci_trends.png
Join the Slashcott! Feb 10 thru Feb 17!
Such as? What language protects you from bad programmers? If they can't add and subtract integers they sure as hell aren't going to be any good at sanitizing input either. If you can't cross your t's and dot your i's you shouldn't be a scribe.
I find it endlessly amusing that the only "new" tool in that list is Ruby (and even that's been around a few years.)
Particularly in light of yesterday's Bloomberg article claiming that the income and job pressure on senior developers is because they weren't trained in the "new tools." It looks to me like marketshare demonstrates companies are more interested in stable technology than new technology.
I'm not surprised Java is sliding, though. It's really become a server-centric language over time, which means there are far fewer deployments per customer than there are for the client-side components of the whole system, such as C# and Objective C++ clients that access those Java servers.
Still, I'm quite comfortable continuing my Java development work. My focus in computing life has always been the server, though I did spend several years on client-side programming as well. While client-side GUI programming is fun, it's also far more time consuming and tedious. I find server-side coding and the performance tuning aspects of it are far more entertaining and challenging. (You can write shitty client code and get away with it because the load is distributed, but if you write shitty server code you have thousands of cranky users, not just a few who's devices are underpowered.)
I do not fail; I succeed at finding out what does not work.
Yes. It's called the Standard Template Library. C++ has them and should be used. There's hardly any excuse not to use them, especially now that C++ will get move semantics which can increase performance of the containers by an order of magnitude.
Those who do not learn from commit history are doomed to regress it.
Home Depot has reported that the hammer has moved up 2 places in the rankings overtaking the Phillips head screwdriver and pliers as the most widely used hand tool. Also moving up in the ranks were the flashlight and the crescent wrench, precipitating the further decline of the Allen wrench and the drill bit in the rankings.
Haha, who still uses the Allen wrench? Clearly the Phillips head screwdriver is superior. Newbs.
Here is their detailed method. It's far simpler than it claims to be, basically just summing up the search results for a particular language. I couldn't find any mention of the "number of skilled engineers world-wide, courses and third party vendors". Also, there are some shortcomings such as excluding AJAX hits from Javascript and Rails hits from Ruby, the reasoning behind that not being convincing. Still, this list is similar to other comparisons using search results, and i don't think we will invent a method better than that soon.
Because we can't trust programmers to be smart enough to avoid these conditions...?
Well, obviously we can't.
Given the prevalence of SQL injection attacks, which could be prevented with a single function call, I have to say that buffer over-(and under-) flows are really a red herring. Unless a language makes it literally impossible to write insecure code, lazy and bad programmers will find a way.
Github thinks my Python web projects are mostly Javascript because I stuck dependencies like JQuery in the repo.
Two separate languages to make a more impressive total I say java is still on top: Java/VB = 32%
Sure. As soon as someone comes up with a language that produces code that runs half way as fast as C on any OS, and that at least pretends to integrate with the rest of the OS. You know, make it nice for everybody else other than developers. Oh, here's a though: how about developers get their heads out of their butts and learn how to be programmers, instead of whining that real languages don't do everything for them?
Switch to Windows. C# and .NET do in fact run at least "half way as fast" as C and integrates with the rest of the OS fine.
In any case, excluding a managed language on the grounds that it is not fast enough sounds like premature optimization to me. Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.
C++ has very complex rules that take years to hone and understand correctly, and even then mistakes are easy to make. The proof is that even today when you go to C++ forums people are still asking about obscure language rules while in Java forums the conversation has moved on to issues of design. Nobody needs to discuss the meaning of language constructs in Java because they are obvious.
It isn't however obvious that an error in your cannonical class definition could cause this code to create a memory leak:
a = b;
Clearly proper use of a tool is important. But tools without safety features are more likely to cause accidents.
C is awesome incarnate: lean, readable and full of low level goodness.
C can be readable .... if the programmer has kept to a reasonable kind of discipline and order in the coding, that is. (FTFY)
Obfuscating C can be as hard to read as old 'spaghetti Fortran', I think.
-wb-
now that C++ will get move semantics
Not will, _has_ move semantics. As of last August.
64-bit hardware doesn't require reworking old apps, most 32-bit apps will run just fine as is. Unless you need more memory than your 32-bit environment can provide I doubt many 32-bit apps are being revisited.
Games are an area where C/C++ has always been strong, one needs the performance, except possibly for casual games.
iOS is another thing that may contribute to increased C/C++ usage. When you target iOS you have to use Objective C, this is what the iOS API uses. However there is no problem using C/C++ code in the non-user interface portions of your code. For example in an iOS calculator app (rpn, scientific, statistics, business, hex) the user interface code is all Objective C but all the handlers for the button presses and all the math is in C/C++. This makes porting and testing easier. With respect to testing I can build regression and fuzzing test apps for the Linux console that include the button handlers and math code, these test apps then simulate button presses and check "displayed" results and various calculator registers (stack, memory, special purpose, etc).
And of course there is the combination of the two. iOS games. The core of the game itself should be written in C/C++ for performance and portability.
The list in the article isn't the same as in the submission... there is no trace of cold fusion, but there is Logo(!... !!!!) in spot 19. Is there something that would explain why the moving turtle of my childhood can be found on such a list?
Based on the "number of skilled engineers" as evaluated by a scraper.
Tell me again about the tenths of a percent.
Can we please adopt programmers that are not susceptible to writing bad code? It's really pathetic that after all these years, that's still a huge cause of security issues.
now we need to go OSS in diesel cars
totally agree, learn to program, learn to debug, and write read software.
Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore. First, compliers represent the result of the best and brightest and trial and error for optimizing code structures into streams of assembly that are frequently counter-intuitively faster than a person is likely to think of on their own. Secondly, prcossor manufacturers tend to get their latest and greatest instruction sets into compilers, and trying to keep up with those dynamics would be implausible for a human writing special purpose code.
So manually writing in assembly is no longer always faster in practice and in fact usually slower. I don't think the same claim can be made of any particular managed language compared to C/C++.
Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.
XML is like violence. If it doesn't solve the problem, use more.
No matter what the question is, "switch to a different OS" is never the correct answer. People should be able to pick the best OS for the job, as well as the best language for the job. C# and .NET integrate well with Windows because they don't run on anything else. I would rather have options. And the term "premature optimization" is a good example of the kind of idiot that writes code these days. Not doing what you call "premature optimization" is what I call being sloppy. Being lazy. Do it right in the first place so you don't have to do it again.
Java is not exactly issue-free as well. For example lack of comparison operator for strings forces a programmer to abandon an intiutive ways of doying things and to always remember to follow the language obscure rules. Same for unsigned bytes and integers. Same for resource leaks and forgotten "finally" blocks.
There is definitely movement away from Java and toward C/C++ for some types of software. Applications bottlenecked by memory performance, like databases and high-performance codes, will often be faster than a language like Java by integer factors. When people assert that Java is about as fast as C/C++ they are talking about code like tight, CPU-bound loops. However, Java is wasteful of memory and CPU cache lines in a way that C/C++ is not under normal circumstances which has a significant adverse impact on the performance of some codes.
On recent processors, memory performance is a bigger bottleneck than CPU performance for performance-sensitive codes. The throughput of CPUs has grown faster than our ability to keep those CPUs fed from memory. In the supercomputing world this started to become evident years ago; memory benchmarks like STREAM became more closely correlated with real-world performance than CPU benchmarks like LINPACK for a great many algorithms. The resurgence of C/C++ is partly driven by this reality since it makes memory optimization relatively straightforward and you can receive large gains relative to Java for modest effort.
A smaller but also important driver away from Java is the GC. The increasing focus on "real-time" and predictable latency for applications like analytics and database engines is complicated when Java's garbage collector is inserted in the middle. This is a chronic point of pain for some applications.
I developed Java for years but my latest project (a real-time analytical database engine) is being written in C++ for the above reasons, among others. Writing high-performance applications of this type is actually pretty painful in Java because you end up doing unnatural things in the language to even approach the efficiency of conventional C++. Anecdotally, many of our C++ developers were doing Java until recently so the statistic does not surprise me.
I think the trend is just beginning. I'll grant you that this is currently speculative and is based more on trends I've seen in a highly responsive section of the economy as far as technology is concerned.
As much as I am not a big fan of PHP, I'm going to stand up for it. No one with a computer science background seems to like it, but it's a good general purpose tool. If you're going to put up a web application and it just needs to work and do so quickly, PHP is how most people will do that, especially the self-taught.
I'm not in denial of its many problems, including slowness and security issues. I don't want to code in it ever again. But it's a good general purpose web templating language.
"Switch to Windows. C# and .NET do in fact run at least "half way as fast" as C and integrates with the rest of the OS fine."
Does it? Well good luck writing a low level device driver in C# in that case,.
A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.
C++ has very complex rules that take years to hone and understand correctly, and even then mistakes are easy to make
I am not sure why you do not understand this but....
Idiot programmers are idiots.
We need good programmers. Programming IS complex. It needs to be. There is not a language that is flexible, powerful, fast and will wipe your fucking ass.
Pointing out that your experience in forums is crap.
What you see in C++ forums is what you are looking for. Same with Java.
Java doesn't have obscure commands because it can not do anything obscure.
Just because you are comfortable in Java and are clueless when it comes to C++ says nothing about the languages.
When you start working on some real machines in environments that just get shit done you will see C, C++, Perl, Assembly and shell scripts.
Then you will start looking around and notice PHP shit and Java and bits of shit all over.
In all of that you will see crap coding and good coding. If you can not code well you can go play with with languages that are weak and slow but may allow your shit code to run. But when someone else looks at your code they will still see that it is in fact, Shit.
Why is it so hard to only have politicians for a few years, then have them go away?
Except in Java, in practice, despite all of it's fancy features, still has all of the same problems A C/C++. No language will let any programmer gloss over the fundamentals.
The Java programmers really should still be asking the hard/unusual questions, but they've got some half-baked tools to plaster over the issues. The end result is a bunch of smug programmers that make the same basic mistakes, generating code of no greater quality but far worse speed. - Honestly, doesn't that remind you of ever Java project, ever?
Java is not exactly issue-free as well. For example lack of comparison operator for strings forces a programmer to abandon an intiutive ways of doying things and to always remember to follow the language obscure rules.
String is an object. All objects are to be compared using equals method. It's not obscure by far. Compare that most C++ queries.
If you want a good obscure Java language requirement, it's the fact that arrays are objects and essentially don't have a functional equals method(you have to use java.util.Arrays).( So next time you post this, at least you'll have a good example)
Not sure how you shoved Perl into "get shit done" and PHP into "shit". Both are equally awesome and terrible. Depends on the programmer.
http://soylentnews.org/~tibman
Everyone that isn't me is an idiot and a bad programmer. I know everything. Watch as I beat my chest for 10 lines.
What a bunch of drivel.
...And as with most language standards standards, that actually means that a developer can safely begin to use the new feature in portable code starting around the year 2025.
Niope! And there are a lot of HFT platforms to prove you're wrong.
You write the C# -> native compiler first ;)
No colour or religion ever stopped the bullet from a gun
Can't an entire OS, including drivers and everything, be written completely in Java, w/o involving C or C++ at all?
Errors != security issues. Buffer overflow and underrun errors are serious issues (mostly mitigated by modern libraries and safer coding practices), but security issues that arise from them are mainly the OS fault. 1:1 mapping of code and data segments is dumb securitywise. It's not we were lacking in linear address space in popular architectures all these years (today maybe). Long story short - the shortcomings of a given language are only a part of the shortcomings of the whole system.
the ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings.
This doesn't give much to go on, but I suspect you could adjust the algorithm to give different results pretty easily.
Get reasonably recent compilers. GCC 4.3 already had some of the C++11 stuff implemented, as did Visual Studio 2010. Move up to GCC 4.7 and Visual Studio 11, and you get more complete C++11 implementations (as well as Clang).
For the record, this has been true for a couple of decades. There are only a small number of cases where writing assembly can produce better code, and most of those have to do with application-level semantics that can harness register data to get better results. One example of this is bignum math, where it's frequently useful to sample the carry flag to optimize sequential addition. Even here, however, this effect is usually achieved by compiling the C code to assembly and then hand-optimizing only the smallest portion of the code to use the carry/borrow flag.
While, technically true that the compiler can almost certainly optimize code as good, if not better than most developers. It still has to optimized the actual code written, which may not be as efficient.
People tend to use libraries for everything in higher level languages. And those libraries are typically filled with code that's not necessary for the specific job being accomplished.
In general, you are better off with this, since the library code is debugged and well designed. So programs are typically filled with well written, well designed "average use case" optimized algorithms.
If you need web hosting, you could do worse than here
compliers represent the result of the best and brightest and trial and error for optimizing code structures
Clearly you haven't used the Intel C++ compiler..
"If anyone needs me, I'm in the angry dome."
Moving to 64-bit may be a recompile away *for perfectly written code*. In the real world, a lot of 32-bit code assumes you can store pointers in ints, assumes that alignment and packing rules of pointers and ints are the same, prints out pointers using int formatting, uses algorithms that don't scale beyond ~16GB of memory, etc.
Wow... I haven't touched assembly since about 15 years ago. Trying to program your assembly to outperform a compiler with out-of-order instruction execution on the CPU takes a mad genius. You probably would get about 10x the speed boost by rewriting code to use GP-GPU instead.
In defense of the grandparent, I'm fluent in C++, program it every day, and find it a mindbogglingly complex set of bolted on features that keep expanding and some that overlap each other. From a design perspective, elegant would be the last word I'd use for it, and it really was never a well designed extension on top of C IMO. Objective-C is a MUCH cleaner object extension to C, but it ties you to Apple (yeah, I know about GNUStep, but Apple drives the development of the language). In addition, many C++ features were so poorly implemented that they are rarely used, like try-throw-catch (I have yet to see professional code that uses them - hell, I've seen more code that uses the taboo GOTO for error handling than try-throw-catch). Templates are extremely powerful in C++, but often lead to ugly, obfuscated code. Multiple inheritance has also caused me many headaches compared to interfaces (like Java and Objective-C). C++11 only adds to the feature bloat, but some of the features are more "finally" for me like lambda functions and native multithreading. I've wanted native multithreading since I first started thread programming back in 1991, having to use 4 different thread libraries for 4 platforms (I believe pthreads, Windows threads, MacOS9 threads, and BeOS threads at that time - this was all student programming and I was still learning C++ and very self-motivated). D seems to have cleaned up a lot of the issues I have with C++, but wasn't ready for prime time when I tried it last (several years ago).
I have a love hate relationship with perl, too (another language I use practically every day). It gets the job done, but really, I never needed objects in perl, and haven't used any new features since about perl 3. That said, it is the best cross platform shell language that I've found, and I can write and run quick powerful cross platform scripts.
There are many applications and games written in C/C++ that I love.
I also occasionally code in C - sometimes it is fun to use pointers and read/write files without chaining two or three objects.
There are however huge drawbacks to using C/C++.
There is surely a full list somewhere, but for me currently the not-buying-point is the preprocessor.
The preprocessor allows conditional compilation of any file. Sometimes the file might do that, sometimes something different.
This means that it isn't practical to have pre-compiled modules (although I guess you could go the route of splitting your project into dozens of libraries).
Thus, a very small file can require Gigabytes of memory to compile, because all the dependencies have to be pulled in, and represented in memory.
C is cool for learning how things work, but not good for making things work.
Hey don't blame me, IANAB
It is steadily going down in last 10 years. And I do not think these 0x and 11 ting will bring any good news to it.
C is very very stable...And do not mix C with C++. It DOES not make any sense.
TIOBE makes for an interesting toy measure. But for truly reliable conclusions, particularly those related to the health of our favorite technologies, we must instead ask: does NetCraft confirm it?
Comment removed based on user account deletion
Make the insecure code hard to write and make the secure code easy to write. Problem 99% solved.
HAND.
Can we please adopt languages that are not susceptible to buffer overflow/underrun errors? It's really pathetic that after all these years that's still a huge cause of security issues.
That's down to programmers, not languages.
eg. C++ done properly is as safe as Java. Modern C++ compilers have bounds checking enabled by default for all STL containers (on "operator[]", not just "at()"). If you're seeing overflows it's because of uneducated C programmers who think they're too cool to use them (eg. Linus Torvalds).
SQL injection attacks are similar. Everybody knows about them, everybody knows how to avoid them, but people are still coding them.
No sig today...
A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.
What compiler are you using? Mine gives me a warning if I forget that (and has done for at least the last eight years or so).
No sig today...
Since about 2010 you'll have to try pretty hard to find a platform that doesn't have a C++ compiler with move semantics.
Even before that STL containers had a "swap()" function that worked pretty well for moving data.
No sig today...
My point is not that strings are objects but that it's easy to make a mistake by coding == instead of .equals (especially when coming from other languages where no such issue exists, C++ or Python). How's that different from forgetting virtual destructors?
Another annoying issue is absolute incosistence in the method name (or property name) that returns the size of the collection.
While it would be nice for developers to "get their heads out of their butts," that's not a real solution and you know it. Developing some kind of extension to C, or some other systems programming language which has protection against buffer problems is.
Problems you can fix vs. problems you can't. There are bad programmers. Some people are bad programmers all the time, all of us are bad programmers some of the time. That's just life. So what are you going to do about it? In my experience I'd MUCH rather debug some bad code written in Java/Python/Ruby than bad code written in C/C++. All other things being equal if you don't *need* C/C++ for some specific reason based on the type of work you're doing (speed/very careful memory management/etc.) you'll *probably* get a better result writing your code in one of the higher level languages.
Tell me, did that language rant make you finally feel like a big man, with a big ePenis?
Actually 'C' is the "top dog" whereas 'C++' is #3 behind Java.
C recently had its standard updated and the uptick could be a reflection of this. Not to mention the increased exposure that C is getting from objective-C.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
C++11 only adds to the feature bloat
What feature bloat? If you don't use the new features, you don't incur any cost. No bloat.
And many of the new features that you really should be using (smart pointers) have very little, if any overhead.
There is nothing I'd love more. But at work, we're still stuck on VS2003.
Man, the good ol' days. I was able to crank out custom small-to-medium apps in FoxPro/xBase like nobody's mother. There was something magical about xBase that's hard to explain.
Part of it was the tight and seamless integration between the database language and the imperative language. One could do a lot in so few lines and commands. The API's between the database and app code used now are so damned bloated and verbose in comparison. The granularity of the query language was also better than SQL. It's difficult to break SQL into multiple smaller queries in most RDBMS.
Microsoft Access just doesn't quite cut it as a replacement. Apart from the fact MS keeps changing MS-Access, there is a disconnect between "mouse-based" design and the language (VBA). It's not very seamless to switch between them, and it takes almost 3 times as much VBA to code the same thing as xBase (at least non-GUI processing. xBase never quite got it's GUI act together, which is part of the reason for its shrinkage).
I realize that much of the xBase code in practice ended up being a maintenance headache, but that's only if you didn't follow certain "safety" conventions. The slop-heads gave it a bad rap.
People used to do things like put code expressions into tables, making it almost like a domain-specific spreadsheet or an instant Expert System. That's where my handle comes from.
I hope something like it is reborn with some modernizations and better "safety". I really miss it for quick-and-dirty apps especially.
Good Bye, my ol' friend.
Table-ized A.I.
Sorry, maybe I'm old, but I don't believe in systems designed to think for people.
Get businesses to pay for good programmers, and stop hiring the cheap, shitty ones.
NOTE: This is not to insinuate that all expensive programmers are great, and all cheap programmers are crap.
Funny, your comment reminds me of a teacher I had, he used to say the same thing with almost the same words. You're not from Portugal, are you?
You are right about C++ of course. During the recent years I've been doing Java work. I really like the language and think it is optimal for many performance-critical, complex systems.
However, in my experience Java, too, has its intricacies that baffle many experienced coders. For one, I don't see how you can code anything in Java without reading the chapter about the happens-before relation. Most Java programmers instead seem to have developed various degrees of superstitious taboos with regard to memory consistency.
Another thing is the mindless reliance on the heap and threads. Java programmers have been encouraged since the nineties to pile objects on the heap and start hundreds of threads or more. With the abundance of RAM, GC problems are "solved" with memory upgrades, and network bottlenecks are "solved" with more threads. While its always good to have more RAM (eg, for automatic file system caching), you should not keep gigabytes' worth of tiny long-term objects on the heap because you are going to choke the GC. Instead, only keep a few hundred megabytes worth of temporary objects on the heap and store other objects in a file or -- equivalently -- serialize them in RAM.
Mono implements the majority of .Net these days. It also runs great on Linux and OSX.
Modern C++ makes it very difficult to produce buffer overflows. I wish people would stop criticizing C++ with age-old arguments that have been rendered obsolete long ago.
This sig does not contain any SCO code.
err. freecode, lately, at least that's how it seems to me.
The oracle buyout is bad for java, but android is good for java.
Don't use either anymore except for the occasional hack of existing C code, but in the olden days (Borland) when you compiled a C++ program you actually were running a pre-compiler to turn the C++ into C and then that went through the C compiler. Is that two pass methodology still used today or are there C++ specific compilers now?
Average Intelligence is a Scary Thing
Oh, come on, everyone makes those mistakes, even respected maintainers of important libraries. And hell, even the damn cstdlib has functions like gets(), practically inviting programmers to introduce buffer overflows in their code.
It's just irresponsible to rely on not ever making a mistake to secure your code.
Dilbert RSS feed
Huh.. I thought we were bad with VS2k5 ....
What no Groovy? Oh well, I should follow the masses mindlessly without considering the right tool for the job.
Its all the same.
I was making the point that depending on your point of view there are the "Good Tools" and the "Shit Tools".
But when you look into it they are all being used and they are all being used at different times and by different people both badly and well.
Tools are tools. Craftsman are the makers.
Why is it so hard to only have politicians for a few years, then have them go away?
RosettaCode.com shows solutions for common programming task written by experts in each of the different languages http://rosettacode.org/wiki/Main_Page
I think over 400 languages are shown for hundreds of common problems.
I do not think I stated that I was good or bad at it.
In fact I am sure I did not.
I am pointing out that bad fucking programmers are bad fucking programmers.
Holding their hand with slow, hand holding languages is not a good solution.
Teaching good coding is.
Why is it so hard to only have politicians for a few years, then have them go away?
Because too many of these programmers don't program anymore. They just tie together modules and libraries with function calls and templates.
The reason C is still big is because there's just so much stuff out that that is not a PC. On a PC you can get away with being unskilled and sloppy, because memory is getting cheaper, CPUs are getting faster, and users are becoming less discerning. Most computers in the world though are not PCs, they're small things hidden inside of devices and they don't run Windows. Some may be slow, some may be fast, but most have resource constraints of some form. Quite a lot of them come with no third party OS or run time library either. And someone has to write all that stuff in something that's reasonably efficient and portable and C and C++ are pretty much the common choices.
lol.
You know why computers are useful? cus they do shit for us.
how about developers get their heads out of their butts and learn how to be programmers, instead of whining that real languages don't do everything for them?
Is such a stupid statement. To err is human. You give people the opportunity to make mistakes and they will. Doesn't matter how 'good' they are.
Comment removed based on user account deletion
For a lot of functions it is not difficult to write if more efficiently than some good compilers. It's a trick to optimize it the way you need to for certain resource constraints. You wouldn't want to do that for everything, it would take too long. But it's doable for key functions in run time libraries (ie, writing a memcpy that knows how to use your cache instructions).
The "average case" is fine most of the time but quite often there are exceptions. I've seen people who rely on this stuff too much, who argue until they're blue in the face that STL maps are "proven optimal by people smarter than you".
My point is not that strings are objects but that it's easy to make a mistake by coding == instead of .equals (especially when coming from other languages where no such issue exists, C++ or Python). How's that different from forgetting virtual destructors?
A) No idea what a virtual destructor is. .equals(). Comparing something using == is not that widespread in day-to-day coding, even in a short program. Most books and tutorials will point that out early. .equals() was never, ever, a problem for me nor anyone I know.
B) It's not easy to make that mistake even after a few days, because in Java you mostly compare everything using
C) If you're using something like PMD or FindBugs (Eclipse even has plugins for that), you will get errors with explanations.
D) There are some very clear and straightforward tenants of Java language. If you're coming from other languages and not familiarizing yourself with them, it's really not an issue of the language. Complaining about Java without familiarizing yourself with essential principles, is like complaining that C/C++ has manual memory management and pointers. I came to Java a mere 12 years ago from C, ASM, Pascal, Perl and PHP. Picking up
I see too many people who assume that "don't optimize prematurely" means that they should never optimize. These sorts of people I think learn some catch phrases in school but never actually think them out and treat them as sacred rules. Similar to the people who think "goto" must never be used.
Without automatic cleanup, it was only a matter of time before C/C++ rose to the top of the heap.
while java is far from issue free, you picked a pretty poor point. In fact, your point is one of the good things about java. that is, when you use an operator you know exactly what it's doing. It's not ambiguous.
Acording to their own documentation (http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm) Tiobe index calculated by how many times the langauge is mentioned on top websites. Really, that has nothing to do with the number of lines of code written.
Fortran2000 is so cutting edge.
We agree! Joyous occasion on the internet :)
http://soylentnews.org/~tibman
As far as I know, ZSNES is still the fastest emulator on Windows. What is it written in? x86 assembly.
We obviously work in very different places. They are fairly common, and quite useful, in C++ code that I've worked on for professional products. YMMV
Am I the only one surprised at the sudden spike in VB.NET's standings? http://www.tiobe.com/index.php/paperinfo/tpci/Visual_Basic__NET.html Don't get me wrong, I love VB.NET and would probably be working on it today if my employer didn't prefer C#, but that spike baffles me,
...and at the same time does away with all resource leaks, not just memory leaks? Your pretty little garbage-collected languages take so much more effort to handle properly than C++'s RAII approach.
(I do Java for my day job, and I kinda think I'd rather do C++ if the jobs were around).
Coffee-driven development.
You write the C# -> native compiler first ;)
And how do you think C# code is executed?
The "Native Image Generator" is
the Ahead-of-time compilation service of the .NET Framework. It allows a .NET assembly to be pre-compiled instead of letting the Common Language Runtime do a Just-in-time compilation at runtime
Not an ordinary .exe, granted, but the native code is there even in normal C# use. Ordinary native binaries can be generated from C# if necessary though - this is how Mono targets platforms like the Wii. The reason you can't write (normal) Windows drivers in C# is because Windows isn't written in C#.
That said, bindings exist for libusb, so that's a start.
(There seem to be a number of similar bindings for Java, and a standard API spec that no-one's implemented.)
Google tells me two operating systems have been written in C#: Cosmos and Singularity.
This isn't to say C# is more suited than C to OS/driver work, but it can be done.
Premature optimization is bad. Premature pessimization is worse :)
Coffee-driven development.
I don't think Creepy's use of "feature bloat" was referring to run-time performance - having too many features in a language is itself a Bad Thing.
It's harder to write a complete and conformant compiler, for one, so it hurts portability - advanced C++ template code is plagued by this already. It also hurts readability: if I code using a certain subset of C++ (because it's too vast a language for me to keep all of it in my head at once), and you're used to another subset, you'll have trouble reading my code.
Compiled C# assemblies are normally run through the JIT - the Native Image Generator is an option.
But you're right in saying it's all down to the bindings.
No colour or religion ever stopped the bullet from a gun
'Optimizing' every piece of code you write, without thought for readability, maintenance, or whether or not the code even needs to be 'fast', is a sure sign that you're doing it wrong.
Java is not exactly issue-free as well. For example lack of comparison operator for strings forces a programmer to abandon an intiutive ways of doying things and to always remember to follow the language obscure rules.
Unfortunately for your argument, those issues you discuss have already been handled so thoroughly, and documented so pervasively in the APIs and JLS that they are no longer the subject of questions for a long, long, long time. Whereas, when you work in C++, you better have Scott Meyer's and the C++ spec next to you at all times. As a programmer that has done Java and C++ for a living, I can tell you that the amount of syntactic/semantic minutia you have to track in Java (or plain old C) pales in comparison with C++.
Your example of comparison of Strings is not an accurate description of how Java is to be used. It is very specific in the JSL what "=" is for - to compare primitives, primitives being char, bytes, ints, longs (the typical scalar stuff) and object references. For anything else, you need a comparator function that, as specified in the language specs, imposses a total ordering. The function is specific to the context of usage - it will be an override of Object.equals, or an implementation of Comparable.compareTo, or, if you need pluggable total order functions, one or more implementations of java.util.Comparator.compare. After 17 years of Java being in the while, this has already been settled.
That pales in comparison with C++ rules for ctors, dtors, operator overloading, constness, the accidental passing of non-pods into vararg methods.
Same for unsigned bytes
There is no such thing in Java as an unsigned byte. A Java byte is just a bunch of raw bytes of an opaque nature (much like a CORBA::octet).
and integers.
I don't follow this. What exactly are you referring to when comparing integers?
Same for resource leaks
Give me a Java resource leak over a C++ one. I can instrument bytecode so that I can record a stack trace on an object creation, which would get printed when its finalizer gets invoked, or with JMX or some type of admin console, with little to no change on an application source code. You could so sorta the same in C or C++ with Valgrind, but there is a lot more elbow grease involved when hunting these kind of things on a C/C++ application. Sorry, when it comes to resource management and resource leak tracking, this is one are where managed code beats unmanaged code, bars none.
and forgotten "finally" blocks.
Which are less demonic than C++ catch(...). At least we get the option of having a finally block when programming in Java. In C++ we do not have that at all. Oh my God, that is one of the things I miss the most when working in C++. That, and structured exceptions as first-class types. THAT is the greatest flaw in C++ exception paradigm. I can understand why that was not included, but I honestly believe it has ultimately proved to be a flaw in the language (all languages have flaws, so it is not that I'm picking on C++ just because I'm jerking my programming language fanboi proclivities.)
I trully and honestly I not using exceptions at all in C++. Hell, I prefer working with plain C or simply use C++ a-la C-with-classes.
The old, sparkling shine I used to see in C++ has become a lackluster dim. I've come to the conclusion that C++ is/was the victim of the state of the art compiler and language design of its time. Too much cobbled together using technology and concepts of the day, coupled with a need to remain compatible/easily integratable (sp?) with C code.
I'd rather work with C, or with a managed, modern (or relatively modern) language. That's just me. Obviously YMMV. So in the end is not whether X or Y language is issue free (none is). The question is what exactly you get in return when dealing the total complexity of a language, and what effort does a person has to take to either a) select a subset of that complexity to complete a task or b) comprehend a large chunk of said complexity.
Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.
Language choice can make a difference, but that's usually because higher level programming languages tend to have very well written string and buffer management libraries that avoid most of the problems that bedevil a lot of code in C and C++ (and Java too). It's not that the lower level languages can't be used efficiently, but rather that a substantial fraction of their practitioners simply don't use their tools well. The higher level languages, because they conceal more, can hide enough gory details that they can actually keep enough useful metadata around to be able to optimize algorithmically. Well, some of the time.
The next time I see someone using strcat() in an inner loop (or += over Strings in Java) I think I'll scream.
"Little does he know, but there is no 'I' in 'Idiot'!"
My reply was mainly to original parent: http://developers.slashdot.org/comments.pl?sid=2807769&cid=39781843. I never had the described issues with C++ (virtual destructors, forgotten cleanups, etc). The "ugliness" and complexity of the code is solely a programmer's fault, not the language. I just tried to show that similar issues exist in Java, including resource leaks, forgotten cleanups, "finally" statements, incorrect object comparison, etc.
It was a best practice before C++ went bonkers... Maybe up to version 2; after that, why bother? The C++ code will eventually be thrown out, or if it is worth keeping, re-implemented in C anyways.
Got me - I'm more into the Java side of things really.
Apparently Paint.NET (the first C# desktop app that sprang to mind) uses it.
Do you know if an ordinary DLL can be generated, say, by Mono? If I recall correctly, it's somewhat complicated in D, because of garbage-collection; I imagine it would be similar with C#.
Wow... I haven't touched assembly since about 15 years ago. Trying to program your assembly to outperform a compiler with out-of-order instruction execution on the CPU takes a mad genius.
In defense of the post you're replying to -- they said "you will see assembly", not "you will write assembly", I take it they meant hand-optimized assembly code delivered by the vendor that makes the lowest level bottlenecks like matrix-vector multiplications or FFTs blazingly fast. The kind of code that takes different paths depending on the CPU model to carefully pipeline instructions, use extensions and to use the cache efficiently.
Every end has half a stick.
Get reasonably recent compilers. GCC 4.3 already had some of the C++11 stuff implemented, as did Visual Studio 2010. Move up to GCC 4.7 and Visual Studio 11, and you get more complete C++11 implementations (as well as Clang).
That's a great idea, but it only works when you deliver executables. If you distribute sources and a configure script you can't reasonably expect all your targets to run gcc 4.7 today.
Every end has half a stick.
Just had a look into NGEN - it still runs on top of the CLR, so still runs within the .NET VM. So I think we're back to my original challenge to write a full C#->native compiler :)
No colour or religion ever stopped the bullet from a gun
Poor up-mod by those that don't understand there are varied means of increasing of code performance. Also poor form to assume the parent post knows nothing of Big O. Also shows a lack of understanding real-time systems, embedded code, FPGA, DSP chips, etc, etc.
Abstractions carry a cost, it's as simple as that.
There is no way to prevent buffer overflows without checking at runtime whether the index is within the buffer, whatever the language. Static analysis can be used to remove that check in certain cases, but it only works in relatively simplistic scenarios.
Usage in C is to not perform this check because buffers are ubiquitous, and given that it is normally relatively easy to prevent the buffer overflow by sane coding practices, it is judged the performance overhead is not worth it.
How are exceptions poorly implemented? They incur no runtime overhead (unlike branches) unless an error occurs. They do, however, make code size a little bit larger, which is why it is often avoided in embedded systems (even if most of them could support them just fine).
I've seen them used in many professional settings, but they tend to be discarded for most high-performance code.
I have to disagree on your badly thought out and trollish position stating that we do in fact agree. :)
(Internet all back to normal now)
Why is it so hard to only have politicians for a few years, then have them go away?
Mono can generate a normal, runs-without-Mono, Windows .exe executable from your C#, but I get the impression that generation of a (native) .dll can't be done, even with Mono.
http://capecoder.wordpress.com/2012/04/09/language-popularity-its-not-about-search-engine-result-counts/
I don't really care. But it seems to me there would be not accurate way to measure this sort of thing.
No. What is irresponsible is not testing the heck out of your code before shipping it. You should be doing that anyway, why not code according to safe procedures and doing some real QA while you're at it? It is also irresponsible to create a whole generation of developers with no concept of security and efficiency, because modern languages are supposed to do that for them, at great expense of everybody else.
Thank you.
I can't believe these people get press for doing web searches with the names of programming languages and counting hits. We all just lost the game for even wasting our time considering it.
I was crazy back when being crazy really meant something. (Charles Manson)
... such as the newer Java, which combines the clean, easy and manageable syntax of C with the blazing speed of Smalltalk.
*Tadum* *Crash* *Thud*
Thank you, thank you, I'm here all week. Try the fish and tip your waitor.
We suffer more in our imagination than in reality. - Seneca
What feature bloat? If you don't use the new features, you don't incur any cost. No bloat.
I'm fairly fluent in three languages, but if I switched between them at random during a conversation depending on which one lets me express myself better I would just have created an insanely complex language with enormous redundancy and extremely inconsistent pronunciation and grammar that would be massive pain for anyone else to learn. You can't simply say "well now you can express everything you could in one language and much, much more" and pretend that's an advantage with no drawbacks. Or even if it's the same language and you're writing a book with each author contributing a page each you wouldn't want the style to change radically from page to page, particularly when editors constantly go in and redo a page here and paragraph there.
I don't think it's possible to completely avoid code style wars, but if there's one generally accepted "best practice" way of doing things - and I don't necessarily mean in your team or in your company but in the language ecosystem and all your new hires too - then everyone can understand a code base much faster and is more productive. Consistency is huge, you want everything to behave in predictable ways. Not to mention basic training time, how long until you know the language features? The more you add to it, the worse it gets because unlike human languages working code doesn't get replaced no matter how archaic the language. Of course there's such a thing as too sparse a language too, but for the most part I'd say less is more even if it doesn't solve everything optimally.
Live today, because you never know what tomorrow brings
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.
The chart would seem to indicate that because it's ranked higher those are the skills you should be concentrating on? I don't think so.
T-SQL is near the bottom, yet if you do any MS SQL development, it's just as important as any other language on that list. JavaScript? If you're doing web development, it's just as important to know as T-SQL or C# or what ever your language of choice is.
The statistics are meaningless for making any real decisions about what you should learn or be proficient at.
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
A long time ago I owned Borland C++ ( also the Lisp and Pascal compilers) but thats long gone and never really warmed to Java
I would like to get back into playing with C / C++ at home and Im happy to pay a reasonable amount for a home IDE to brush up and write stuff and play.... but not 000s
OH I run Linux Mint - on my main PC (although I have a Win XP VM)
What do people use to code in C / C++ - what are your recommendations these days ???
Fool. Have you never worked with other people??
They use features you don't like and bang! you have feature bloat. Of course it's in the mind of the dev, but then that's where it always was...
Why is it that when I search for jobs, I find a lot more C++ than C jobs, and when I do find a C job,
1) either the job is actually "C/C++", or
2) depending on the site or employer, some job postings mung punctuation, thus causing C# or C++ jobs to show up as C.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore.
Compilers are in general horrible at getting anywhere near full throughput out of the SIMD instructions on modern CPUs. At least partially because the languages don't provide data types and operators that map well to how the SIMD instructions work. For most tight number crunching loops, you'll be lucky if straight forward, compiled code is achieving even 25% of the throughput that the CPU is capable of. To achieve full throughput, you'll need to understand the SIMD architecture, and hand roll some assembly language or C/C++ code using SIMD intrinsics.
However, for most programs, it's usually not worth the time, effort, and "brittleness" of the resulting code.
In x86 land the code/data bloat is somewhat offset by the doubling of the number of general purpose registers and other architectural improvements of 64-bit mode. 64-bit mode is not strictly a wider incarnation of 32-bit mode.
... your post reminded me of the Alpha we spent so much time studying in grad school in that mid 90s time frame. :-)
That said your point is very valid. Write portable code, build for both modes and measure is the way to go IMHO.
Now I have to go, depressed and sad
When did Micrsoft begin to specify - as a System Requirement for its software - the rotational speed of one's hard drive(s), ie, as it does - quite explicitly - here:
+ http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-basic-express/system-requirements
?
If it's spinning a bit more slowly, the user waits a bit longer... Right?
Premature optimization does not refer to hacked sloppy solutions as much as it does illegible and neglible counter intuitive code practices that account for little to no gain. You should only be trying to squeeze out fewer microseconds when the program calls for it. It is a widely known rule of thumb to first right things clearly and perhaps even naively, profile and then optimize when the performance is not within acceptable range.
Correction that should be write, not right.
Seriously? Just read the (free) Modern Perl book sometime. You're bound to pick up lots of useful ideas. The Perl community has moved on a great deal since the 90's, you know.
And I fscking hate it.
Thanks for playing.
Others may have more experience or more general experience, but mine has been that language trends come and go but there will always be some constants. To me it seems like Perl is one of them; if you're doing anything short of application development, it's probably the fastest way to get it to work. Anything else would do well in the C++ or Java realm. I have never seen a need to move to Python. It's a fine language but doesn't offer any tangible improvements over Perl.
I'm not sure that's really true. Especially if you want to use bleeding edge instruction sets, you will probably be better at hand-optimizing it than the compiler will. There's also the fact that you can look at the compiler's output, so you should never do worse than the compiler.
I think auto-vectorization has improved a lot recently, but not too long ago it really sucked. C++ is not a very good language for optimization since it has no guarantees about independence or immutability of data (e.g. const can be cast away, the compiler has no way of knowing library functions are pure, and there's the perennial problem of aliasing), and so there are optimizations that are very difficult for the compiler to make.
One example I've run into recently would be the shuffle instruction from SSE. There's no way a compiler would be able to look at C++ code and figure out its purpose to to shuffle some bytes.
The ranking was done simply by "counting hits of the most popular search engines" for each language. A large number of hits might just imply that a language is more difficult to use and requires more on-line assistance.
C is very popular with embedded electronic devices, so it doesn't strike me odd that it is coming back.
I think you would be surprised at how much we are wrong about what a compiler does for us. The fact is that compilers try and do there best, but at the end of the day they mostly just do what you tell them to do. I worked on a contest at my job a little while ago, and found that many of my long held assumptions about what a compiler optimizes for me were just plain wrong. Even though it is true that a compiler can inline functions, or make use or registers for function variables, or do memory and pointer optimizations, the reality was that it didn't do them unless I forced them to. I was able to go through 10 revisions on my entry each time increasing the performance by almost an order of magnitude, and each time it was because one of those optimizations that I thought was supposed to be automatic, was not really happening after all.
Pretty much a smart person can make code faster, and faster almost in perpetuity. Code is never done. It just becomes good enough at some point.
All of that being said... performance really doesn't matter most of the time. The hardware makes up for inadequate code most of the time and that's fine since that inadequate code is probably more readable and will require less maintenance.
Just my humble opinion.
Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore.
LOL I have been hearing that meme for at least 25 years. Anyone who says this has never worked in assembly language. Even an intermediate assembly language programmer will do much much better than a compiler. I rarely need to write in assembly anymore, but when I have had to, I usually can cut the running time in half or better - and I don't consider myself an expert assembly programmer.
For 99% of programming the compilers are good enough - but we use them because it is easier to maintain and write in higher level languages. NOT because the compilers write better code than a person can.