Python becomes the most popular language

[PKTKS]

a decade later you will check again..

 

[bd139]

a decade later you will check again..

 

Yes but this is a winner.

First time you go through the cycle it's hard and takes you 5 days to do a job

Second time you go through the cycle it's easier and takes you 3 days to do a job but you still charge for 5.

Third time you go through the cycle it's even easier and takes you 1 day to do a job but you still charge for 5.

This is how I paid my house off, charging 25 days for 5 days of work

[voltsandjolts]

They will be replaced by a whole new list of new and improved BUGs...

Programmers will forever be fallible and will always produce code with bugs. The idea of newer tools is to ensure those bugs are less security critical, getting away from the 'buffer overflow...here you go...have root access' kinda thing. Hence rust code coming to your kernel soon.

[bd139]

They will be replaced by a whole new list of new and improved BUGs...

Programmers will forever be fallible and will always produce code with bugs. The idea of newer tools is to ensure those bugs are less security critical, getting away from the 'buffer overflow...here you go...have root access' kinda thing. Hence rust code coming to your kernel soon.

Exactly this.

If we can nail that and supply chain attacks I might sleep again...

[Cerebus]

Perl is completely fucking DEAD.

No it's not. It's a ZOMBIE. The thing with dead things is that they're in the ground and can't hurt you. Zombies on the other hand...

[Picuino]

https://www.tiobe.com/tiobe-index/
"""
May Headline: C# gains most ranking points

If we compare the current TIOBE index rankings to 1 year ago (May 2021), C# is gaining most popular of all programming languages by far. Its rankings has increased almost 2% for the last 12 months. C# is one of the most mature programming languages in existence, supporting many modern programming paradigms. Until recently, its only disadvantage was that its Linux support was questionable, but this is changing rapidly the last couple of years. So chances are high that C# might enter the TIOBE index top 3 by replacing C. Another serious contender for this top 3 position is C++. Its long term trend, boosted by C++20, is definitely upward. -- Paul Jansen CEO TIOBE Software
"""

The Times They Are A-Changin'

[bd139]

Perl is completely fucking DEAD.

No it's not. It's a ZOMBIE. The thing with dead things is that they're in the ground and can't hurt you. Zombies on the other hand...

That’s actually a surprisingly fair description 

[bd139]

https://www.tiobe.com/tiobe-index/
"""
May Headline: C# gains most ranking points

If we compare the current TIOBE index rankings to 1 year ago (May 2021), C# is gaining most popular of all programming languages by far. Its rankings has increased almost 2% for the last 12 months. C# is one of the most mature programming languages in existence, supporting many modern programming paradigms. Until recently, its only disadvantage was that its Linux support was questionable, but this is changing rapidly the last couple of years. So chances are high that C# might enter the TIOBE index top 3 by replacing C. Another serious contender for this top 3 position is C++. Its long term trend, boosted by C++20, is definitely upward. -- Paul Jansen CEO TIOBE Software
"""

The Times They Are A-Changin'

I’m not sure this is actually true. Every org I see who have long term c# involvement are exiting the platform at the moment. I’m not even biased here - I’ve been using it since day one and rather like it. But Microsoft’s stewardship of the platform is a schizophrenic rollercoaster of pain and deprecation and everyone is as tired of that as me now.

[Picuino]

I'm not a big fan of Microsoft or the standards it promotes, so I hope it is as you say.

Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.

[Picuino]

Flash Player support has long since been discontinued. Unfortunately I have several tutorials in the web with this technology. They are old, but I didn't want to do without them yet.
Thanks to Ruffle (https://ruffle.rs/) an emulator written in Rust that runs in the browser through the use of WebAssembly, I have been able to keep the Flash Player tutorials active.

Of course the world is moving towards open standards and the move from Flash Player to HTML5 is yet another example.

Although C# is a standard, it is supported by Microsoft, which has a long history of abandoning its technologies (such as VB6, which is still in use).

One of the things I like about Python is precisely that it is a free and open software language.

[PlainName]

Anyway, C seems to be in decline because of the push of other languages.

Might that be because of the high-spec hardware available at cheap prices? C is jolly good where things are a bit resource-constrained. Anything from a PIC32 down would warrant it to get the best, but nowadays people think nothing of shoving a RPi in to flash an LED, so bloaty stuff isn't a problem. For instance, Python and similar are no doubt capable and don't use much memory, but they want an entire proper OS to come along as well. For a Pi that's fine; for an ATTiny not so hot.

Perhaps C will be relegated, as assembler once was, to just doing the really low level libraries, and most code (which would include most libraries too) would be done in the popular stuff.

[coppice]

Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.

C isn't in decline. Its still doing the things it has always done, and to a similar extent. Rust might change that, but we'll have to wait and see, The whole software market is growing, and C is not the ideal tool for a lot of where it is growing.

[PKTKS]

Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.

C isn't in decline. Its still doing the things it has always done, and to a similar extent. Rust might change that, but we'll have to wait and see, The whole software market is growing, and C is not the ideal tool for a lot of where it is growing.

Indeed. 

I doubt RUST will wide replace C  unless the very specific niche (AGENDA) of the sponsors..

The folks living in the systemd wonderland. .. are not used to install software the safe way..

Real life  is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile  a distro without them...

so..  calling that dead is more likely coming from a dead brain...

I will just post a shot of my package manager.. written in PERL::Curses...

It shows how Autoconf and Automake PERL modules are INDISPENSABLE for a safe workstation..
A bunch of folks are insanely eager to push MESON to replace them

Soon or later they will see how hard things can fail because the decades of functionality Autoconf provide just can not be replaced that easy..

It is just impossible to compile a distro without PERL...
a lot of folks are trying to change this .. a decade or so...

Paul

[bd139]

automake and autoconf are a monumental shit show that need to go away.

Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.

To note I have written a lot of Perl. It's horrible and dangerous.

[coppice]

automake and autoconf are a monumental shit show that need to go away.

That was kind of inevitable if you consider the long period over which they evolved. Now the needs are better understood much cleaner schemes are possible.

Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.

That kinda misses the point. How is my project using a dozen languages, including stuff from 30 years ago, going to be able to benefit from that? Something more generic is needed.

[bd139]

automake and autoconf are a monumental shit show that need to go away.

That was kind of inevitable if you consider the long period over which they evolved. Now the needs are better understood much cleaner schemes are possible.

Not really. They originally existed because the compilers and make implementations were different on each platform. So the objective was to glue whatever you could together with Perl and M4 and then leverage the unholy shit crock to puke out builds for your software strewn with ifdefs all over the place. I spent most of 1999 undoing one of these turds...

That problem was mostly resolved, apart from all the infernal GCC extensions out there. At least clang seems to pretend to notice them...

Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.

That kinda misses the point. How is my project using a dozen languages, including stuff from 30 years ago, going to be able to benefit from that? Something more generic is needed.

Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.

COM/DCOM was pretty good at this even if everyone hated it but your resident enterprise architect didn't give a shit because his job was to make everyone equally unhappy

[coppice]

Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.

I don't want to hear your sad story. Anyone who has done enough software development has a catalogue of messy tales to tell.

[bd139]

Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.

I don't want to hear your sad story. Anyone who has done enough software development has a catalogue of messy tales to tell.

Perhaps I could have more elegantly said that the point is you solve language and integration problems through composition, not through consolidation. Thus autoconf and automake are creating a problem not solving it.

[Nominal Animal]

the point is you solve language and integration problems through composition, not through consolidation.

Modularity, not frameworks.
Composability, not monolithic integrated designs.
You design and specify the interfaces, and allow any implementation that implements the agreed upon interfaces and behaviour.

Yes.  But that's not how software is developed nowadays.  Most projects aggregate into something that can be shipped, that's all.

In modular designs, correctly tracking and fulfilling dependencies is key.  Interpreted languages like Python can do much more logic when choosing which dynamic library to load, than lower-level systems programming languages like C that rely on the system dynamic loader.

If we consider portable binaries say across x86-64 ELF systems using SYSV ABI (Linux, BSDs, etc.), the optimum case would be if we could provide a dynamic linking 'hint' or 'script' file, a sort of a shell script type of thing, that could specify the paths/files to the dynamic libraries based on the current run-time environment, mixing both system-provided and application-provided libraries as needed.  This has been tried many times before, of course –– one I don't really like is GNU libtool ––, but the one approach that seems to work best is to use a launcher script to set up environment variables defining those paths.  The downside with the script approach is that it cannot really deal with individual libraries, unless you use a dedicated library directory you populate with symlinks.  Checking and populating that in a script or loader program does incur a bit of a startup latency, though.

These are the kinds of problems that are more important to me than which language does a trivial loop the fastest.  I can implement whatever I need in whatever language I have available, but I'd like it to be modular and maintainable: reinventing the wheel again and again is dull, and only good for those who like the job security as wheel reinventors.

[Cerebus]

Real life  is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile  a distro without them...

100%? Except for the bits that rely on m4, bash and awk. Heck, you even have a screenshot of your 1980's style package manager showing scads of m4 files. If you're going to pontificate, try to get your facts straight.

Anyway I'm with BD, Autoconf and Automake are horrible. Better than having nothing, but sorely in need of consigning to the shitcan. Cmake can do anything Autoconf and Automake can do and does it better (I have to confess to personally not liking Cmake, but that is pure arbitrary personal taste and doesn't detract from the fact that it is a massive improvement over Autoconf and friends.)

[mansaxel]

Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.

Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems. People love C so much there is focus in rewriting core system utilities in other languages now.

The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on .

Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...

I make a point of writing the very few utilities that are interactive web sites I make in Perl, simply because it's "mature". No kiddiez will ever understand it.   Also, and more importantly, my brain stopped understanding web programming circa 1999. Everything after that is just incomprehensible and bizarre reinventions of GUI's that would have been better as thick desktop apps...  Or done in something like curses.

I did, once, include a 3-line snippet of js in a CGI page I built, to get a "print this page" function. I admit that. Took a lot of googling.

Also, I need Perl because my music player, a Squeezebox, requires it if I'm not to turn it into a tool of the music industry that can't play my local music collection.

Fortran is happily trudging along in HPC, but I suppose you're right about C++.

My colleagues are all over Python so I suppose I'll have to learn it to fix their programs.

[coppice]

Fortran is mostly DEAD.

Fortran is happily trudging along in HPC, but I suppose you're right about C++.

Yep. I think bd139 is being a bit blinkered. It amazes me to see how much Fortran is still relevant if you look at the right areas to see it. They are still updating the spec.

[bd139]

Fortran is mostly DEAD.

Fortran is happily trudging along in HPC, but I suppose you're right about C++.

Yep. I think bd139 is being a bit blinkered. It amazes me to see how much Fortran is still relevant if you look at the right areas to see it. They are still updating the spec.

I'm certainly not saying that Fortran is not used at all. If we look at the 99.9% of computational requirements, it doesn't factor in and there isn't exactly a massive queue of people waiting to write it now which is a commercial risk. Much like COBOL and JCL for example, they are being replaced because maintenance is the largest operational expenditure of a technical decision over a decade cycle.

Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.

Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems. People love C so much there is focus in rewriting core system utilities in other languages now.

The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on .

Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...

I make a point of writing the very few utilities that are interactive web sites I make in Perl, simply because it's "mature". No kiddiez will ever understand it.   Also, and more importantly, my brain stopped understanding web programming circa 1999. Everything after that is just incomprehensible and bizarre reinventions of GUI's that would have been better as thick desktop apps...  Or done in something like curses.

I did, once, include a 3-line snippet of js in a CGI page I built, to get a "print this page" function. I admit that. Took a lot of googling.

Also, I need Perl because my music player, a Squeezebox, requires it if I'm not to turn it into a tool of the music industry that can't play my local music collection.

Fortran is happily trudging along in HPC, but I suppose you're right about C++.

My colleagues are all over Python so I suppose I'll have to learn it to fix their programs.

I will admit that I am no fan of the world-wide web. I've done my time writing complex UIs in HTML/CSS/JS and it's quite frankly horrible. I do understand it fairly well (to the point of being fairly competent with React) but yes, I'm with you there.

Apple get GUI implementation fairly correct with Swift/SwiftUI I found. That's bearable and worth investing in if you are a Mac and iOS user. XAML/WPF and C# was also fairly nice although it was like pissing on an ant out of a moving train with the platform churn. I still have a fairly large WPF app out there in the wild at the moment.

Python will take you a few hours to learn. It's worth it. Some of the things other languages do feel horrible fairly quickly.

Stuff like this is fun, with a semi functional nature...

Code: [Select]

import math

def gen():
  for x in range(1, 10):
    yield x * x

a = gen()
b = list(map(lambda x: math.sqrt(x), a))

print(b)


[coppice]

I'm certainly not saying that Fortran is not used at all. If we look at the 99.9% of computational requirements, it doesn't factor in and there isn't exactly a massive queue of people waiting to write it now which is a commercial risk. Much like COBOL and JCL for example, they are being replaced because maintenance is the largest operational expenditure of a technical decision over a decade cycle.

JCL and COBOL are only being maintained. Lots of new HPC code is being written right now in Fortran. It feels like a step into history when you come across this.

[PKTKS]

Real life  is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile  a distro without them...

100%? Except for the bits that rely on m4, bash and awk. Heck, you even have a screenshot of your 1980's style package manager showing scads of m4 files. If you're going to pontificate, try to get your facts straight.

100%.. That is correct - reason being is that you can not remove these modules. The functionality will be compromised and you have a broken system.

If you ever compile your own distro you will see that some nasty problems arise from circular dependency In other words.. You need a full working console before widget gizmos..

Reason that my package manager was designed smart enough to live with that odds.
It is a system wide daemon. It works very light on any workstation here..

I am free to use any interface I want..  I have a half dozen..
The daemon is written in PERL as well and can bind socks or direct INET
- Console is used as far as the build has Curses interface
- PERL::Curses is used from this point up to having full GTK support
- then PERL::GTK  is used - they are independent but require the build steps..

It has a builtin HTML browser (GTK based) and POD Viewer (native) with full PERL site log...
by this way I can manage package downloads and repos just fine inside the package build system

I am considering writing a full TVIsion/SQLite interface for that..
Just like my BENCH  INVENTORY .. I  like TVision simple fast and functional

so i am free to deploy a light 32 bit or dedicated 64bit server with proper package management..
so far so good it works for my needs

Shots attached

Paul