Pelles C forum
Pelles C forum => General discussion => Topic started by: John Z on September 07, 2023, 06:03:52 PM
-
Here is the most recent programing language survey, always sure to start a discussion :)
https://spectrum.ieee.org/the-top-programming-languages-2023
Summary chart attached -
John Z
-
And I've seen this comparison, a little different though largely similar. Python ranks first with 30.09%, followed by Java with 18.84%, then JavaScript with 8.1%, C# with 7.27%, PHP with 6.08% and C/C++ with 5.86%,
-
While there is a big propaganda behind the popular scripting languages, the C language is not losing it's importance.
-
That data should be related to the software products distribution.
The big explosion of web applications requires a large use of web programming languages, this leads to the grow of script languages, HTML, javascript, python, etc.
Similar reasons drive the grow of multiplatform languages/frameworks (Azure and similar).
Making 100% the whole, those new programming field apparently seems to occupy the 90%, but this is exactly the growth, more or less, of new applications. Conclusion the use of imperative strong languages, as C/C++, are the same.
Why? Because an OS, time critical programs, high efficiency computation, requires them, C/C++ and even FORTRAN sometimes. ;)
Anyway the software/hardware development always follows the dog-tail law: when a more powerful hardware is created there always follow a new OS or language or user interface to make it slow! ;D ;D ;D
-
And how Python is build ::)
With what language ?
There was Visual C++ for Python 2.7 package VCForPython27
-
Hi Timo,
The WayBack Machine \ Internet archive is hosting a copy of the Visual C++ for Python 2.7 package.
-
As always, I guess it depends on how they collect the data.
Web developers will be active on the web, COBOL developers no so much...
-
As always, I guess it depends on how they collect the data.
Web developers will be active on the web, COBOL developers no so much...
As said FORTRAN or COBOL or ADA are not so active in popular github or sourceforge anyhow in some domain it remains the main language with no choice. This ranking is good for hobbyist or HR but for most professional developer do not have to be top notch usually being efficient with tons of code to maintain is enough.
As a teacher told me long time ago implementation language is not so important if you understand algorithmic and can calculate complexity of your code (Just stay open minded to learn new language).
-
TIOBE Index for September 2023 (https://www.tiobe.com/tiobe-index/)
-
As a teacher told me long time ago implementation language is not so important if you understand algorithmic and can calculate complexity of your code (Just stay open minded to learn new language).
Yes, and it helps that new successful languages are mostly (always?) incremental improvements over existing languages. New languages with radically new ideas tend to flop...
-
Hi Pelle,
Yes, and it helps that new successful languages are mostly (always?) incremental improvements over existing languages. New languages with radically new ideas tend to flop...
I agree with you.
What are your opinions and ideas on the future of programming paradigms?
-
What are your opinions and ideas on the future of programming paradigms?
I have never been good at predicting the future. Here are some random ramblings...
I started on a 'micro-computer' with 16 kB memory, where I eventually had to write my own Z80 assembler when the BASIC in ROM wasn't enough. When the IBM PC and X86 family came along, you still needed an assembler - or more realistically a compiler - to reach the necessary speed and/or to fit code and data into the available memory. Small and fast (enough) programs were a necessity.
Today, processors/computers are often fast enough even for poorly designed script languages. For maximum speed, though, you need to do things in parallel: either by using multiple threads and/or by using SIMD instructions. This more or less requires a compiler, but the language is not so clear. AFAICT, this is still a research area. It has been for some years, and with computers being everywhere now, it's not hard to guess people may pick an easier are to research (considering how research is conducted an financed in parts of the world, at least).
I doubt "normal" processors will see anything but incremental improvements over the forseeable future. If they ever get quantum computers to work, it sounds like they will be good for some specialized problems only. Since we need a processor in the end to run our program, and with more than one family potentially relevant these days (X86, ARM64, RISC-V, ...), a compiled language makes most sense; never assembly code unless you need the last few percent of performance (and can accept rewriting for every architectures), and not an interpreted language if you want top performance (and can accept recompiling for different architectures).
One of the more popular compiled languages in recent years is C++, and I suspect it will continue so (unsure, but I doubt one of the "better C++" languages will get popular enough to make much difference). Personally I have preferred the minimalistic approach of C, but this seems to be going away with new people on the C standard committee.
There are currently many other languages, but if the future is similar to the past, many of them will be largely forgotten in a few years.
All in all, I spend (too) much of my days working on small details, so I'm probably not the best person to ask about "big picture" things...
-
Pelle, what can you say about Rust? I see, many people like it. And they see it as a replacement for the с++
-
A comment on Rust binaries :
Rust uses static linking to compile its programs, meaning that all libraries required by even the simplest Hello world! program will be compiled into your executable. This also includes the Rust runtime.
To force Rust to dynamically link programs, use the command-line arguments -C prefer-dynamic; this will result in a much smaller file size but will also require the Rust libraries (including its runtime) to be available to your program at runtime. This essentially means you will need to provide them if the computer does not have them, taking up more space than your original statically linked program takes up.
For portability I'd recommend you statically link the Rust libraries and runtime in the way you have been doing if you were to ever distribute your programs to others.
https://stackoverflow.com/questions/29008127/why-are-rust-executables-so-huge
-
Pelle, what can you say about Rust? I see, many people like it. And they see it as a replacement for the с++
Sorry, I don't know enough about Rust to have a strong opinion.
Over the years I have seen enough programming languages being described as "the next big thing" only to disappear after a few years. By now I'm old and skeptical enough to wait a while for things to clear up...
-
Over the years I have seen enough programming languages being described as "the next big thing" only to disappear after a few years. By now I'm old and skeptical enough to wait a while for things to clear up...
Me too.
At least ... old :-\
;D ;D ;D
-
If I hear about Rust one more time... I'll implode lol (jokes). But seriously.
Next will be Python competing with Rust, now that they are considering moving to this language in the Linux codebase (memory safety, etc)
I am blind to the first 2 in the list, I am fluent in the rest for many years now. PHP and C until the day I no longer touch a keyboard 8)
PHP has a lot of issues, but it has really become a solidified player since PHP 7 (I started using it since 5.6), and is much faster now. The async support is next to a laugh. I leave that up to PECL now for heavy multi-threaded tasks. Of course, this expects a thread-safe compilation. I hope it improves. I know they push out Fibres support, but I have not played with it because I don't feel like rewriting core classes to accommodate the new feature and experience breakage across the board. Very risky for critical cron tasks that should not be interrupted and get out of sync at a large scale. The PECL parallel extension works fine for me.
String/array manipulation is beyond easy and I am very pleased with the OpenSSL support (my app appreciates it too).
SQL is SQL. I can write it blind, but the focus is the RDMS and its engine performance long before advanced syntax. The rest falls into place quite easily, and is hand in hand with multiple languages.
I'll never touch Python or Java. But Java was my entry to ASM and other learning curvs in the early 2000s ironically. I never stayed with it, I peeled off to web technologies at the time and shaped my learning. Today its second nature.
-
Hi WiiLF23,
But Java was my entry to ASM
Kindly, could you provide more details? Assembly and Java are totally different worlds.
-
Hi WiiLF23,
But Java was my entry to ASM
Kindly, could you provide more details? Assembly and Java are totally different worlds.
General logic, structure and how everything binds together - in any language. Just a learning curve. I learn by analyzing. They have no relation to each other, I agree. Also being young at the time, I was exploring everything in-between, including the operating system I was using at the time.