C Drops, Java (and Rust) Climb in Popularity - as Coders Seek Easy, Secure Languages (techrepublic.com) 108
Last month C dropped from 3rd to 4th in TIOBE's ranking of programming language popularity (which tries to calculate each language's share of search engine results). Java moved up into the #3 position in September, reports TechRepublic, which notes that by comparison October "saw relatively little change" — though percentages of search results increased slightly. "At number one, Python jumped from 20.17% in September to 21.9% in October. In second place, C++ rose from 10.75% in September to 11.6%. In third, Java ascended from 9.45% to 10.51%..."
Is there a larger trend? TIOBE CEO Paul Jansen writes that the need to harvest more data increases demand for fast data manipulation languages. But they also need to be easy to learn ("because the resource pool of skilled software engineers is drying up") and secure ("because of continuous cyber threats.") King of all, Python, is easy to learn and secure, but not fast. Hence, engineers are frantically looking for fast alternatives for Python. C++ is an obvious candidate, but it is considered "not secure" because of its explicit memory management. Rust is another candidate, although not easy to learn. Rust is, thanks to its emphasis on security and speed, making its way to the TIOBE index top 10 now. [It's #13 — up from #20 a year ago]
The cry for fast, data crunching languages is also visible elsewhere in the TIOBE index. The language Mojo [a faster superset of Python designed for accelerated hardware like GPUs]... enters the top 50 for the first time. The fact that this language is only 1 year old and already showing up, makes it a very promising language.
In the last 12 months three languages also fell from the top ten:
Is there a larger trend? TIOBE CEO Paul Jansen writes that the need to harvest more data increases demand for fast data manipulation languages. But they also need to be easy to learn ("because the resource pool of skilled software engineers is drying up") and secure ("because of continuous cyber threats.") King of all, Python, is easy to learn and secure, but not fast. Hence, engineers are frantically looking for fast alternatives for Python. C++ is an obvious candidate, but it is considered "not secure" because of its explicit memory management. Rust is another candidate, although not easy to learn. Rust is, thanks to its emphasis on security and speed, making its way to the TIOBE index top 10 now. [It's #13 — up from #20 a year ago]
The cry for fast, data crunching languages is also visible elsewhere in the TIOBE index. The language Mojo [a faster superset of Python designed for accelerated hardware like GPUs]... enters the top 50 for the first time. The fact that this language is only 1 year old and already showing up, makes it a very promising language.
In the last 12 months three languages also fell from the top ten:
- PHP (dropping from #8 to #15)
- SQL (dropping from #9 to #11)
- Assembly language (dropping from #10 to #16)
TIOBE is complete bullshit (Score:5, Insightful)
Why is TIOBE still talked about? Their data is complete nonsense. Don't believe me? Look at how it's made:
https://www.tiobe.com/tiobe-in... [tiobe.com]
It's basically searching for "$LANGUAGE programming" on various search engines, then taking the "5 million results found" counts. After that they use some fudge factor they seem to have come up by themselves. Why is google.com worth 7.69%? Why is Wikipedia the second in the list, do mentions on Wikipedia go up and down by language popularity? Why is google.co.uk in the list, when it also returns English results?
Does Google even promise that the result count they display is remotely accurate?
Let alone that this barely means anything if it worked because it's trivial for anyone to inflate counts by encouraging the use of the term, or it can also go down if some prominent site happens to go down.
It's an absolutely terrible metric and I don't understand why anyone cares about it. At least try to be remotely accurate. Look at Stack Overflow activity. Look at commits on Github. Look at subreddits. Something that indicates actual usage at a given point in time.
Re: (Score:2)
The "why" is right there in the name: The Importance Of (click-)Baiting Engagement.
I also find it interesting that the focus is in easy and safe languages. Nobody cares about developer productivity or flexibility these days? Usually, you compromise on two -- and at least one -- I irder to get the other two.
TIBOE is helping in some ways (Score:2)
It at least helps keep the over-hyped fanboy languages from widespread use in critical systems.
They should post a comparable list looking at what languages are in actual job postings.
Re: (Score:2)
I don't know - Python is a pretty fanboy language that is pretty effed up still for commercial use. It is a really good scripting language, despite my hatred for certain design things (I hate whitespace/tab syntax. Makefile, I blame you). I don't know if it is the language or the programmers (HIGHLY likely), but I've found serious security issues with code written in it. Again, programs written by non-programmers, but they fired 90% of the programmers and just use coders... I'm now in IT because I'm too exp
Re: (Score:2)
Why is TIOBE still talked about?
I'm assuming because someone is paying for it to be talked about. As you've pointed out it's data based on completely bogus metrics, which usually means they started with the conclusion they wanted and found a way to reach it. Then shitty media companies desperate for any dollars they can get feature stories about this research so that it gets some eyeballs on it. Then they throw a few nickels at the tail-end of the media-human-centipede and get /. editors to post it here because no one actually reads the c
Re: (Score:2)
I'm assuming because someone is paying for it to be talked about.
That's my conclusion by now as well.
On and off I posted about how I can't understand why this is "news" _every month_
Now my guess is that Tiobe pays slashdot somehow.
Re: (Score:2)
I don't mind because it causes people to discuss programming languages and I can pick up pointers about what's good and bad about each.
There should be a monthly list of popular programming paradigms and methods.
Re: (Score:2)
Why is TIOBE still talked about?
The Fucking Headline (TFH) is nothing but clickbait. Wasn't that enough to answer your question? Seriously, /. gets these "stories" about once a week.....
Stand up for traditional bitmaskulinity! (Score:1)
Re:Stand up for traditional bitmaskulinity! (Score:4, Insightful)
Cartoonish machismo aside, the belief that you don't need to think about memory when using a managed language is a real problem.
Re: (Score:2)
If you have performance constraints, you might find yourself using native arrays which are *much* faster. And, in that case, you need to check bounds. Of course, if you do mess up, you'll get a helpful stack trace which will make fixing the bug trivial.
Re: (Score:2)
*facepalm*
This, folks, is why modern software is such a shit show...
Re: (Score:2)
You still have to think about a lot of memory-related things to make applications memory-efficient and free of memory leaks.
For example, somewhere in my code, I might have a map from sockets to users, to keep track of which user is authenticated on any given socket. However, I need to either make absolutely sure that I am removing mappings from that when a socket terminates through any means - even unclean ones - or, I need to use weak references to make the garbage collector do that for me. The fact that j
Re: (Score:2)
You really don't need to think about interning strings. Any string constants in your code get automatically inte
Re: (Score:2)
you won't have to think
You really don't need to think
If you find yourself thinking
The job of a programmer *IS* to think. Specifically, to think about the operations required to complete a task, what is the most efficient way to perform those operations (and in what order), and how to perform those operations securely.
Your post reads like a mockery of the position. The kind that would encourage doublethink. Such politicization will not protect your user's data when your program fails due to bad design. Nor will the language itself. Only proper well thought out design will do that, and
Re: (Score:2)
But have fun thinking about how to write your own bubble sorting algorithm or whatever. I'm going to go think
Re: (Score:2)
I specifically mentioned system resources. For any non-trivial application, the mapping of authentication to sockets should be a miniscule part and it only applies if your application absolutely needs to use raw sockets. If you can use Websockets over https, the entire thing can be managed by the Servlet infrastructure (part of the Java standard) and you won't have to think about that at all.
GGP did not limit the scope to just system resources. System resources are usually not the issue anyway. Nobody says that an app is a "resource hog" because it left a few file descriptors open. They say it's a resource hog because it's using 4GB of RAM to do nothing. The socket to user mapping is merely an example - you're supposed to extrapolate it to whatever use case you have.
You really don't need to think about interning strings. Any string constants in your code get automatically interned by the compiler (which is why you shouldn't use them as lock objects.) If you're really worried about saving a few bytes of memory, put your strings in a HashMap.
You absolutely should be thinking about this. I can tell you've probably never
Re: (Score:1)
The only languages that matter are C (which you are required to know if you want to use any existing software library.)
You can learn any scripting language (eg Javascript, PHP, Perl, Python) and you will generally understand how it works before the idiots inflating the version numbers start core-rotting the language with features that belong in C++ not a scripting language.
Like good god , "WebASM" was the worst possible thing to exist, now you get people porting their rubbish code from "language and engine
Re: (Score:2)
Yes, you can install more than one JRE. I have Java 8, Java 16, Java 17, and Java 21 on my development box. I run Minecraft as a player with Java 8, Java 16, and Java 21.
Re:Stand up for traditional bitmaskulinity! (Score:4, Insightful)
nobody should be using Java to develop anything due to Oracle's meddling.
Nobody in their right mind uses Oracle's JVM or JDK. Everyone uses OpenJDK which is 100% open source thanks to Sun Microsystems open sourcing it before Oracle bought them. Oracle is *nothing* in the Java world, as and their potential discontinuation of the JRE would greatly benefit the Java community.
You should talk about stuff you know. You draw conclusions based on fantasies, no wonder they're completely off base.
Re:Stand up for traditional bitmaskulinity! (Score:4, Informative)
With Java, you don't have to recompile for different architectures. If you have old C code around and want to run it on a newer architecture, you have to recompile. And your code might not compile with the latest compiler. And the older compiler might not be available for a new architecture, so you're stuck.
With Java, you just copy the JAR file anywhere and run it.
Re: (Score:2)
Makes no sense to compare rust to java in this regard. You very much manually manage memory with rust, however most of it is done implicitly through better semantics.
C++ developers complain about it because they don't understand the concept of implicit destructive move semantics -- one here referred to the idea as "cretinous" because he's used to C++ moves, which are fucking bonkers, just like everything else in that language. As Linus Torvalds and Drew Devault have said: It's a language only enjoyed by bad
because the resource pool... (Score:2)
...of CHEAP software engineers is drying up
Companies prefer tools that allow cheap and low skilled coders to quickly churn out mediocre code
Re: (Score:2)
Re: (Score:2)
Cheap coders used to be in India, but now with the tensions building in the world and the mediocre code that is delivered from India that's not the case.
Sure - they can code exactly to spec, but if you have an ambiguous spec then they don't know what to do and takes wild guesses instead of asking which makes things more expensive in the long run.
Cheap coders are now also replaced more and more with AI generated code, but all AI generated code is based on code already written since the AI don't really unders
How much do we care what devs choose? (Score:5, Insightful)
For me, libraries make a much bigger difference than languages. Java is my main language and there are dozens of things it can do better....but I rarely write PURE Java. Most of what I've ever needed to do has been written and is in a library somewhere. I spend more time assembling library code than writing pure Java. But even when I do...it's fine...some languages do things maybe 5-10% better, but it really never adds up.
I will wager that if Rust is a night and day difference for you, then you didn't learn your old language correctly. Certainly, that was the case for everyone I've ever met who jumped ship to node.js and Python.
Great...you improved your productivity slightly by moving to Python/node.js/Rust...now you can write novice code even faster?
Re: (Score:1, Insightful)
Most of what I've ever needed to do has been written and is in a library somewhere
Oh, you're one of those... Gluing hundreds of libraries together, along with their hundreds of dependencies, is the reason that software is so bloated and slow these days.
Libraries should be used sparingly, only for things that it doesn't make sense for you to do yourself. Libraries are coded for the general case, not the specific. It's going to be larger and slower. If your use case wasn't one of the ones the library authors foresaw, you're going to have some ugly hack to make it work the way you want,
You either don't understand English or JIT runtime (Score:3)
Libraries are coded for the general case, not the specific. It's going to be larger and slower. If your use case wasn't one of the ones the library authors foresaw, you're going to have some ugly hack to make it work the way you want, probably involving another needless library.
No, you're not saving time. More often than not, the time it takes to find, vet, and learn a library for whatever it is you're trying to avoid doing takes significantly longer than just doing the job yourself.
No, you're not making your code more secure. As we've learned, just because a library is popular doesn't mean that it's secure. If anything, its popularity makes you more vulnerable, not less.
If you're making such bold statements, you either misunderstood what I said or you don't understand how modern runtimes work. For Java specifically, only the classes used are loaded, not the whole jar. You can have a 1GB jar in your classpath (if one existed), but only the classes called are loaded into memory. So importing a large library, but only using a few classes, is no real tangible penalty...especially on a server. Secondly, you assume I import more than I need. I don't.
The whole reason a company hires a developer with my experience level is because ideally someone who has been doing this as long as I have knows when to use an existing library and when to write their own implementation. Also, due to both my high standards and the use of automated tools my company set up as well as the ones I run, unneeded imports and dependencies are purged.
You specifically mentioned libraries designed for broad purposes rather than specific ones. Modern JIT compilers, like the JVM, optimize for use case, so while my code may be simpler and more beautiful....I can't benchmark a difference...I've tried....unless the algorithm is fundamentally different and you're explicitly telling the runtime to do more, complex code runs at the same speed as simple code, when given the same instructions. So you may scoff at that Apache library that was designed to do 20 things when you only need it to do 5, but have you actually tried benchmarking your work? I have...the difference disappears within a dozen executions and everything people have ever paid me to do is business code running on servers for thousands to billions of users.
Believe me, I wish what you said was right. I'd love to get paid to reinvent the wheel and show off how much faster my beautiful code is than those decades old libraries written by specialists....too bad the JVM disagrees. I'd love to solve old simple problems in faster ways than do what my employer paid me to do, which is solve their business problems.
So yeah...I would wager I've been doing this much longer than you have....and if not...well, then I will also wager I do a better job than you do if you think we should reject most libraries in favor of writing our own implementation. There's time to market, performance, security, as well as long-term maintenance. Have you seen what happens to your code 5 years later? 10 years? How about 15? I have seen code I wrote almost 20 years ago still in use today, having changed hands a dozen times, been modified many times and evolved....that's why I use standard libraries. I know what is easier to maintain by strangers I will never meet.
Anyone who pays me money wants to get a return on their investment...and having something that is easy to maintain, reliable, and secure is far more important than any minuscule performance improvements an individual can write....if you even could...which I seriously doubt....why?...because I've tried myself. I've tried writing methods that are a fraction of the functional complexity, highly optimized, and I even tried both highly threaded and not...the JIT optimized the standard library to the point where no one could tell the difference.
Re: (Score:3, Interesting)
I have found that you can have years to decades of experience, but in my experience with job hunting, if you don't have experience in that language, even though it is like 100 other languages, but written by a startup so they can make money on support of it, you get shown the door. I wouldn't be surprised to see another language popping up out of nowhere and becoming the latest "fad", just because C-levels will demand it used just to keep up with the Joneses, and we get a generation of programmers who know
Re: (Score:2, Insightful)
"The funny thing is that C and C++ have so many tools to check for pointer issues, and dangerous function calls like scanf(), that show-stopping memory leaks or buffer overflows is pretty much past us, other than for legacy code."
Holy fuck I can tell you don't actually make software for a living
It sounds like you're making my point (Score:3)
I have found that you can have years to decades of experience, but in my experience with job hunting, if you don't have experience in that language, even though it is like 100 other languages, but written by a startup so they can make money on support of it, you get shown the door.
It honestly sounds like you're making my point rather than rebutting it. The employer chooses the language and technology in nearly all cases. It's extremely rare for a company to hire an experienced developer and have no opinions on what platform they want the work written in. In fact, I don't think I have ever been hired to write an application where there wasn't already some code in place. Thus, I don't care what brings joy to developers. I am a professional. I go in and write what I am told to writ
Re: (Score:2)
> I will wager that if Rust is a night and day difference for you, then you didn't learn your old language correctly.
What do you think is the percentage of C++ programmers who can be trusted to write safe code, empirically? Every study shows Rust code is safer, significantly, with no loss in performance or productivity.
C is a night and day difference from assembler. Would you blame C programmers for not knowing how to write assembler safely? C++ to Rust is just progress, just as assembler to C was.
There
Python is a maintenance nightmare. (Score:2)
What do you think is the percentage of C++ programmers who can be trusted to write safe code, empirically? Every study shows Rust code is safer, significantly, with no loss in performance or productivity.
Aren't you making my point? If the C++ programmer isn't skilled enough to safely work with C++...well...should they be writing in C++? I have never been a professional C++ programmer, so I will leave it at that...maybe rust is superior.
However, I am a professional Python and Java developer. Python has SEVERE maintenance issues and if you were a professional, you would know this too. Yeah, it's nice...it's easy to get out the door. Here's the problem...you're a Python rockstar, you write a nice appli
Re: (Score:2)
I don't disagree with any of that. My experiences are similar.
I am not suggesting that Python is a panacea. In fact, it has the worst technical foundations among the currently popular languages. Java is better for business apps. Python is generally better for scripts, science and analytics.
My point was that Rust is better than C++ in most cases. Nim and mojo are other interesting alternatives which likely won't get that level of traction.
C is still great (Score:5, Insightful)
IMHO C is still one of the most useful languages and perfectly fine even for large projects (why should this have changed suddenly after many decades?).
Safety is an issue but there are also many great tools to help with this and which get better continuously (e.g. GCC's analyzer), and the alternatives have their fair share of problems too.
Re: (Score:3)
Indeed. The problem with C is mostly people that try to code in it while not being sufficiently competent. It is absolutely no problem to code defensively in C and to not screw up. But it requires real insight to do so. The good thing about C is that the really incompetent will not even get their code to compile. But that turns out to be a too low bar.
Re: (Score:2)
Exactly! No one should ever write a line of C until they're an expert.
Re: (Score:2)
I work a lot with inexperienced programmers and this is not a problem. But they need some good examples, some guidance what not to do, and need to use good tooling (C has excellent tools). The idea is that nobody (or only experts) can write good C code is wrong. Of course, this is part of the foundation myths of certain other languages..... And don't get me wrong, there is certainly a huge amount of really bad C code out, but this does not mean it is fundamentally difficult to write reasonable C code w
Re: (Score:2)
I imagine what they were trying to say is that they shouldn't be releasing code or contributing to releases until they're sufficiently competent. But the Dunning-Kruger Effect leads to people believing they're far more competent than they actually are. If a programming language has that high of a barrier to entry, then it's proba
Re: (Score:2)
Have you looked at Rust? It requires a lot more skill and experience to use it competently than C does.
Re: (Score:2)
Re: (Score:3)
This is a lot of nonsense. I enjoy writing C and so do many others. You certainly need to know how to structure large projects in C, but this is no secret. The benefit is also clear: Fast compilation times.
Re: (Score:3, Insightful)
Re: (Score:3)
You response reveals you are a bit immature, which lets me to the conclusion that you are not the one having responsibility for anything important.
Re: (Score:2)
One look at his website should tell you everything you need to know about him.
A few other nuggets:
He prefers linkedlists over vectors and deques because he doesn't understand how cache works.
He says no normal developer should ever run into problems with Java's type erasure, and type erasure is awesome.
He thinks C#'s ability to influence the GC from normal code doesn't exist even though it's documented [microsoft.com], and his reasoning is that Java can't do this, and C# just copied everything from Java.
If you're here long
Re: (Score:3)
He says no normal developer should ever run into problems with Java's type erasure, and type erasure is awesome.
I believe that the Java designers would agree with this statement which is part of why they chose to use type erasure. Type erasure means you can't have template specialization which certainly has drawbacks. But it *also* means the compiler doesn't have to generate code for each template instantiation making the final code smaller and potentially much faster if it means more cache hits. Overall the decision seems to have worked out.
Re: (Score:2)
I ran into problems with type erasure the first time I created a string formatter, which was only about three months after I started using Java, so I don't buy for a second that "normal" developers should never run into problems with it. I don't know what advantage this brings over whatever C# does, which I had some prior experience with and never had to deal with. It doesn't matter if it's the most ideal solution for Java, it still fucking sucks, just like Java as a whole. The JVM is and always has been co
Re: (Score:2)
For code that eschews the legacy collection classes, the type erasure is largely invisible
Re: (Score:2)
Re: C is still great (Score:2)
I don't recall precisely, is been over two years since I used that shit language which I hope I never have the misfortune of using again, but what I do remember is it involved the varargs pattern, which was required to create a custom string formatter.
Which means that normal java developers should never create string formatters or use varargs, I guess. Admittedly, varargs is one of the shit anti-patterns java is infamous for abusing, just like type factories.
Re: (Score:2)
Re: C is still great (Score:2)
You misunderstand, there are a lot of things to condemn java over:
- Write once, debug everywhere, including minor revisions to the JRE
- Stupidly deep and overused inheritance trees in the standard library
- Two libraries need mutually incompatible versions of a third library? Dependency shading kludge to the rescue!
- Two libraries need different versions of the JRE? Sucks to be you.
- Despite everybody's best efforts, because Oracle doesn't even make any, all of the tooling sucks. Bad. I've never had to dig i
Re: (Score:2)
Re: C is still great (Score:2)
There are plenty of limitations in Java and the surrounding ecosystem. That wasn't the original discussion.
You kind of hopped into a decades old problem with angle of sphere and his love for bad coding practices and even worse languages.
Java is a thirty-year old programming language. When it was first released, it soared in popularity because it was significantly better than anything available at the time. Early Java users were all experienced C/C++ programmers who recognized the benefits of the language and that they would be able to produce applications much faster than using C/C++.
It's a good thing there are much better tools for that now. In fact google's own research has found that rust developers can produce applications just as quickly as go developers, only with a lower defect rate and using less memory. And you'll produce applications with go faster than with java, and without the burden of having to drag a shitty bloated runtime along with it.
This was all adopted by the same C/C++ developers who you seem to extol.
Oh no.
Re: (Score:2)
100 times, eh?
As usual, you're completely full of shit.
Re: (Score:2)
LOL! You've proven time and again that you don't have a clue.
It is easy to estimate that Java and C# compilers are indeed 10 to 100 times faster.
Oh, look at that! You're already back-peddling! You've softened your claim by an order of magnitude! You're such a fucking joke!
Put up or shut up, moron. Post some independent benchmarks showing anything close to your 100x claim.
Re: (Score:2)
Well, I suggest to compile a million C files.
And then compile a million similar sized Java files.
Simple.
Java is usually compiled instantly. Same for C#
And C? Well, are your precompiled headers up to date? How big is the file?
Sorry, Narcc: you have no clue about stuff like this. Because you are stuck in your dinosaur word.
There is no C compiler in the world that can beat a Java/C# or similar language compiler in speed.
Re: (Score:2)
You keep moving those goalposts. Did you finally figure out that, as usual, you're full of shit?
There is no C compiler in the world that can beat a Java/C# or similar language compiler in speed.
LOL! That wasn't your bullshit claim, asshole. You claimed that Java compilers were 100x faster than C compilers. A claim that you can't back up.
You're such a fucking joke!
Re: (Score:2)
Maybe in business apps. But that's far from the main genre of software. Embedded is still C. I've worked on some massive C programs. While the Linux kernel is large by line count, it's mostly individual drivers that all fir an API. So it's not even as daunting as you may think. For the last 30 years I've done mainly C and assembly doing everything from chemical process monitoring to linear accelerator beam control. C is a capable language for huge sys
Re:C is still great (Score:5, Insightful)
The Linux kernel is, by basically any metric, the largest software project on the planet. It works well. It is under active development. It is not ossified in any way.
That alone proves without any room for doubt that C is suitable for large and very large projects and does not make things harder than needed. In fact, there is reason to believe that C is, at this time, the only language suitable for competent kernel development and one of the very few languages that has proven itself in very large projects. Obviously, a lot of "coders" are not suitable to work on large and very large projects, or kernels, though.
Re: (Score:3)
"That alone proves without any room for doubt that C is suitable for large and very large projects and does not make things harder than needed. "
No, it only proves that it is not impossible to use C for large and very large projects..
Re: (Score:1)
Actually yes. The project would have failed if the tool was not quite suitable for the task. Like other projects that did fail. But I get it, there always has to be some big-ego-small-insight asshole. This time you are it.
Re: (Score:2)
It is not impossible to use any language for large and very large projects.
It's just that some programming concepts and languages only make it (up to infinitely) more complex, and you always need skills in organising code at code, file, and tools levels.
That's why C is perfectly useable for any size project because using another language doesn't magically eliminate those essential skills.
Re: (Score:2)
It is not impossible to use any language for large and very large projects.
Actually, it is. The project simply fails for most languages if you do that.
Re: (Score:2)
It only fails because as I said, it becomes (infinitly) more complex.
Just look at what they're forcing javascript to do for example.
ERP system in BASIC? Sure, it'll be one massive source code file, but still technically possible.
Re:C is still great (Score:4, Insightful)
The closest recent example we have is UEFI which is written in C++.
When you look at *commercial software* (where developers time isn't free), C is popular for real-time solutions where it's necessary and embedded solutions where there is limited processing power.
In all other situations, a language that is more efficient with developers' time is chosen.
Re: (Score:2)
It does hold up. That the Linux kernel project has not failed is already more than enough evidence.
Assembly Will Always Be the King (Score:2)
Re: (Score:1)
Everything you write in assembly, you can write in C, or Pascal, or Oberon or Ada ... and so on.
Re: Assembly Will Always Be the King (Score:2)
Re: (Score:2)
ignorant much?
Re: (Score:2)
Ignorant about what?
If you do not know how to make C code that compiles to the same assembly that you would write by hand: your problem.
Same with Pascal and the other languages I mentioned. Your problem.
There is nothing in Assembly you can not write in a high level language.
Re: (Score:3)
All languages as the final step of their compilation are rendered into assembly language. All the low-level bits of an OS that deal directly with the hardware are also written, at least partially in assembly language. Ditto low-level library bits like memcpy. Assembly language is the giant upon whose shoulders all else rests.
Why are you obscuring how the computer really works with a bunch of human constructs like symbols, mnemonics and labels?
Computers work exclusively with binary numbers. You need to look directly at the bits to fully understand your code.
Preferably, you should exclusively use rows of toggle switches and neon indicators to interact with your system.
Re: (Score:2)
All languages as the final step of their compilation are rendered into assembly language. All the low-level bits of an OS that deal directly with the hardware are also written, at least partially in assembly language. Ditto low-level library bits like memcpy. Assembly language is the giant upon whose shoulders all else rests.
Why are you obscuring how the computer really works with a bunch of human constructs like symbols, mnemonics and labels?
Computers work exclusively with binary numbers. You need to look directly at the bits to fully understand your code.
Preferably, you should exclusively use rows of toggle switches and neon indicators to interact with your system.
I mean, ostensibly, we have been there and have done it that way in the past. The discipline has evolved with newer tools and better techniques, but at the end of the day if you are writing performance-critical software, stuff that needs to be hard realtime (not as uncommon as a lot of people think) or work in resource constrained environments (again, way more common than a lot believe) it is still not uncommon to drop down into assembly to hand-code things where you need absolute control of the instruction
who writes (this crap) (Score:2)
WTF is with (all of the parens)? [Why not take it to the next level with some brackets too?]
Maybe (it's all) [bullshit] anyway.
Re: (Score:1)
Maybe they miss LISP?
A bit old, but still relevant (Score:5, Funny)
For all you coders, a list [imgur.com] of programming languages and how they work.
Re: (Score:2)
Still missing the panels showing the horse built in C both looks good and is fast (but should not be ridden by a fat jockey).
Not to mention it'll translate between all the other horses, as well as ponies and donkeys.
Re: (Score:2)
Funny enough, but I thought it was going to be a list of "How to shoot yourself in the foot using <language>" jokes. Predates Rust?
Not really (Score:3)
Good coders will code in whatever suits the task best. Bad coders do follow-the-hype and often cannot even really go to another language on short notice.
That said, Rust is still niche and will remain niche. It is too complex and requires too much experience with different coding concepts to be accessible to bad and mediocre coders, and these are the vast majority. That is not to say it is a bad design. I had a look at it a while back and it gets some things right, like prevalent immutability, functional concepts, dropping of "classical" OO (which never delivered on its promises, but made everything more complex) and some other things. But the average (and worse) coder is not on a skill-level to be really able to leverage these features competently. So, nice as a systems language (if you ignore the defective woke "community"), but it will never be mainstream.
Re:Not really (Score:4, Interesting)
Rust has some good ideas. But for my taste it is far too complex. With respect to C it has essentially thrown out the baby with the bathwater.
Other problems I have with Rust are: long compilation times, instability of language and dependencies, the supply-chain disaster that is cargo.
Marketing wise I find it annoying that they pretend that memory safety is the only important thing and that they like to compare safe Rust to arbitrary C (no tools for improving safety) when talking about safety and compare C to unsafe Rust when talking about speed, which I think is not entirely honest.
Re: (Score:2)
Marketing wise I find it annoying that they pretend that memory safety is the only important thing
Well, that is pretty much its only real selling point...
Re: (Score:2)
Yes. The Rust propaganda and the claims of its community are dishonest on an advanced level. Or maybe they are simply collectively delusional.
Re: (Score:2)
That is certainly a matter of opinion. I love the fact that I can quickly download and build a project to make some small tweaks without having to spend hours of frustrating work manually identifying and installing all of the exact versions of the dependencies necessary to build the project. Almost anyone who has worked with a modern language will find the process of starting development on a mature C/C++ project to feel absolutely archaic. I'm not even that big of
Re: (Score:2)
I usually use apt-get to install my dependencies, which works flawlessly. But yes, this is then a then on the level of Linux distributions.
But my issue with cargo is not that it makes installing dependencies easy, but that it is an essentially un-curated list of unstable code that changes all the time, where a project might not actually be associated with the repository that it claims to be, can run arbitrary code as your users during compilation, and hides in a hidden directory in your home directory. (A
Re: (Score:2)
The issue is how do I know which dependencies I need? Sure, that should be in the documentation, but the docs are often non-existent or very out-of-date. And which package contains the dependency (packages are named differently across Linux distros)? And which version of the dep do I need? And how do I get that version if my distro doesn't offer it? Cargo, like the
Re: (Score:2)
apt-get build-dep installs all build dependencies of a package.
Regarding the issues, the first is obvious, for the second see the recent Rust foundation activity report, for the third see proc macros and Rust build scripts, and I think the last is known.
Re: (Score:2)
Re: (Score:2)
cargo only installs software which is in cargo. That is very easy go list software there because there is no quality control is part of the problem.
TIOBE (Score:3, Interesting)
And, as ususl (Score:3)
They don't mention that the 27 year old language, Delphi, has risen into the top 10 and displacing those so-called wonder languages.
Delphi's Object Pascal is very capable, easier to read and write over Rust, quick and backwards compatible with older code.
Still, Tiobe, goes to great measures to ignore it for years.
Oh thank heavens, another monthly TIOBE post (Score:4, Funny)
I was worried someone might forget.
Smart tools for the kiddies, cause programming is (Score:2)
The smarter the tool the dumber the operator. That's the point of tools, isn't it?
Then of course, the cheaper the operator is too... as pointed out above.
Look at "network operations centers" now. I read a few of the job postings lately for fun and they want a monkey to "monitor alarms"
Re: (Score:2)
Re: (Score:2)
You don't hire pricy brains to do that, you want a large pool of cheap labour, so the guy sitting there has virtually no training beyond a Cisco or similar certification, and the job is procedural, so he's going to have respond using a pre written script. If a truly unexpected condition comes up, he excalates to the more brainy people.
That is truly the low
Re: (Score:2)
C# shooting own foot with async fad (Score:3)
Java is possibly up because C#'s libraries are getting bloated with async/await shit. Most projects are NOT web-scale. In addition to syntax bloat, it complicates debugging. Other approaches can handle occasional parallel tasks without bloating the 98% that doesn't need it.
I like C# overall, but the async fad is F'ing its libraries. Java will be the beneficiary of asyc frustration. (Java & JavaScript, please add optional named parameters, one of C#'s best features, lovit! The workarounds/emulations are not good enough.)
Oh no (Score:2)
What if the programming language I'm using is no longer popular? How will I face the other programmers at work? I desperately want to avoid becoming unpopular or ostracized by my peer group.
Re: (Score:2)
All the other developers will hate you! How to look good in any code review. [techrepublic.com]
Is COBOL the elephant in the room? (Score:1)