Are you a dinosaur? do you feel like one?

Tech related, web and content

[explorador]

Hi everyone, from time to time conversations take place with clients and other developers, I'm at the usual:

- great content
- customer (audience) focused
- add value
- use widely compatible technology (and yes I love Perl)

But people in general talk about TailWind, React, Node, AWS, Azzure, artificial intelligence, Wordpress, full stack developers, backend, front end, escalable webapps, integral strategies, social media, SOAP, REST, APIS, microservices, blah blah blah.

Then I sound like a dinosaur, they think or say "oh, old Perl, DB or flat files databases... writing content, hand made content!, and simple parts: server, code, assets", but to be honest, except from those working at banks or any financial institution, these people products and solutions are garbage, websites nobody visits, domains that must die after one year, absolutely unneeded complex conversations about 4, 5, 10 technologies just to make the ball bounce.

Sound to me like average attorney/lawyers: you need a, b, c, d, e, f.... etc, and all they need in reality is filling a form (that is mostly free) and present it signed at some institution.

Anyway, back to the question: do you feel or appear at times like a dinosaur?

* Yeah, sometimes they ask me how I manage to make my websites so far but they can't understand the answers.

[engine]

Oh, this made me smile.

I've seen this so many times, and yes, the "kids" are really on it from the point of view of TikTok, and recognition through "likes", etc. It's often about content, and I can't see myself doing TikTok videos. Does that make me a dinosaur?
I just don't go there, and yes, I do feel like a dinosaur in those meetings when that's being discussed. However, dinosaurs no longer exist, and your skills and experience can't be matched.

What many youngsters don't get is that those that have been around the block have wisdom and experience which can't be matched. I see the same mistakes being made over and over again, just I did way back starting a business. If i could go back and tell myself what i know now...!

[lucy24]

those that have been around the block have wisdom and experience which can't be matched

“When I was your age--”
“When you was my age-- when my old man was my age-- when my brother was my age! You was never my age, none of you. And the sooner you get hip to that, the sooner you’ll dig us.”
“I’ll dig your early graves, that’s what I’ll dig.”

Sorry. I’ll leave quietly.

[tangor]

Dinosaur? Not so much, though by age I qualify. Consider myself a Master Hand Craftsman (or Craftsperson if you prefer).

CNC is great if one is going industrial scale, but for point projects and prototypes, nothing can replace hands on with the basic crafting tools---and commonsense and an eye for purpose, precision, and perfection.

[graeme_p]

Tried and tested mature technology is a good thing.

This is a field where people have no idea of the history of the field and keep inventing the same stuff.

[youtube.com...]

Even worse with web stuff. Severless? CGI version 2. Web assembly? Java applets 2.

[graeme_p]

Also, dinosaurs dominated the Earth for about a 180 million years. You could do worse than be one.

Not as up to date as mammals, but a lot more reliable.

There is a lot of BS in the terms you give as examples. Scalable? Not a problem unless you are huge. Microservices? useful if you have a large team, maybe. Social media? Just because people are accustomed to using it does not mean they understand it, and its uses and how it work.

A lot of the time I see people just layering pointless complexity on things that should be simple.

[explorador]

graeme_p: Just because people are accustomed to using it does not mean they understand it, and its uses and how it work.

Many times I got people telling me the solution is an API, or microservices, or just a set of rest implementations... I'm usually not afraid to ask them details from a "I have no idea what you are saying", and then they prove to be absolutely ignorant about what an API is, or microservices.

Hey, let's try a simple "hello world", yeah, we need an API for that ha ha ha, impressive. I remember someone from this forum said... some devs behave like lawyers talking about very simple terms using slang to appear smart, but they actually don't know what they are talking about.

[isitreal]

If by dinosaur you mean, do I prefer to work with good reliable tools that are not subject to random stupid failures and breakages, and where you can generally achieve the same results with 1 to 2 orders of magnitude less code simply by coding it directly, then yes, definitely a dinosour.

I would however make one correction, SOAP and REST don't belong in your list, those are just secure data transfer protocols, that are actually a royal pain to use and setup. SOAP Is one of the hardest things I encountered to get working properly, so doesn't belong with the list of fad toys you gave.

We still use a super light layer of some of the most stable and reliable libraries, but only to sort of polish stuff up, never to rely on for any core functionality. Sometimes a client would email concerned about our site's page load times, page generation data sizes, etc, and I'd dutifully study our competitors,l who often required much more than 1 MiB of raw js just to start running their page, let alone show it. Not to mention those seo black holes of endlessly scrolling js generated page content, etc. Those tests were so consistently and radically in our site's favor we don't even bother doing them anymore. And that's a bloated slow cms run site, lol. If it were a handcoded lean one, you'd have difficulty even measuring the page generation time without using a very accurate timer since new cpu/servers are so fast, and network connections are so fast.

The formula near as I can tell has never really changed, a workable way to manage your content, constant updates and additions, valuable features for your users that give them a reason to return etc, it's actually so simple that all it really takes is time, as in years, avoiding fads, making sure a site you make today can be run tomorrow, aka, not a wordpress site packed with extensions that are sure to break one upgrade.

The old advice webmasterworld people used to give, the good ones anyway, as I was just commenting to an old client, really was the best when it came to content management, roll your own, then run it forever, and just update your code base as features and language changes dictate. I actually regret not having rolled our own and then developed it over years because now we are locked into a rapidly worsening cms whose developer base has gone way downhill, part of the generation of kids the thread starter is referring to, bad at testing, bad at coding, and not trustworthy. But it takes too much time and energy to roll your own, unless you start at the beginning, and evolve it over years, otherwise it's not really practical.

I even do one specialized technical site that I did for one of my projects which I did as a present to myself, it's actually pure html/css with only a page or two that are dynamic, that was such a joy to make, but not practical for most purposes, but so fast, so lean, if I remember right, when I made that site responsive, I think it took maybe 10 lines max of new CSS @media rules, since it was all super clean to start with, and minimal.

I was just doing this on one old, my oldest actually, personal site, and I was really surprised how easy it was to extend core functionality, it did require a lot of refactoring, but it was totally doable, and not a real issue in any sense of being hard or anything. Then when testing it it was/is so absurdly fast that I thought I was accidentally testing my local dev version of the site because there was almost no visible lag between clicking a new page and the page loading. Zero css libraries, zero js libraries, all hand coded backend and front end. No databases, though it could use them but I prefer to keep it clean since it's not a commercial item.

node.js to me is one of the most absurd things I'd ever seen, the notion of the entire package system breaking because one single function library was withdrawn by an irate developer was all I needed to see, that's just dumb, even requiring a file to do a basic function like that in the first place was dumb, top to bottom.

If I were to do it all again, knowing what I know now, particularly that perl 5 was never going to die, I would have learned perl 5 much sooner than I did, and had shockingly fast yet lean sites running that would never break . But Perl does have the issue with multithreading really not working without a lot of cludges and it's certainly not native, so there is that issue, but otherwise, I'd do it all in Perl if I could, all my new stuff uses Perl now, and it's rock solid, the main problem is it is' too easy to add features so I tend to do that, which leads to a lot of features.

And I'm not some old Perl hacker graybeard, I really dived into perl 5 only maybe 5ish years ago, and started using it seriously at that time, then started replacing stupid shell scripts with Perl so they could actually be powerful and useful over time. things like shell script triggered php with various hacks to let that awful mixture work. My new rule which I roughly try to follow if the shell script is going to hit > 40ish lines long, or is going to be extended possibly, start it in perl, and never look back. For backend web stuff, Perl works way better long term too, so I tend to do that now when it's called for.

But Perl was written for an era when Unix people were really good computer people, they understood the systems, and it shows. I supect Perl is too hard for today's script kiddies, python types to actually learn since it's a bit too close to bare metal, even as a scripting language, but to understand it and use it well, you have to get some core concepts that really relate to how computers work in the first place.

[tangor]

Perl is like the shark: evolved before dinosaurs, refined while dinosaurs lived, and outlived the dinosaurs to the present day. Some things are just perfect. :)

[isitreal]

tangor, while I don't criticize myself for failing to see 10 years into the future when perl 6 was in perpetual 'this is the next perl' making the move to perl a poor choice, I am glad I now use it heavily. My main issue was learning it quite late, and fighting against its nature, but I actually in part blame perlmonks and their mantra: tmtowtdi or whatever that is, because what I discovered over many painful refactors was that no, really, there's a set of good ways to do stuff, and many bad ways to do it. It's taken me many massive refactors, still ongoing, to fix this error.

My initial decision to use Perl came when a Python module another guy had made to do something suddenly died on a python minor version update, I think 2.24 to 2.26, I forget, and I decided to never use pythoin again, and wrote the logic in a relatively few lines of amateur perl, and it ran easily 10x faster than the python. That sold me.

But Larry really screwed up with his Perl 6 > Raku debacle, that basically killed perl, and it was his fault totally. I know I did not switch to it around 2006 because Perl 6 was 'just around the bend', it was only in 2018 that I realized Perl 5 was active alive, and developed, that I decided to commit to Perl. Should be used in classes as an example of the importance of release early, release often, and the perfect is the enemy of the good, and whatever other programming cliches you want to toss out there.

Problem with Perl is you have to know how to program to use it well, very steep learning curve, and not for newbies. I think that's where the 'read only' snarky comment came from, plus allowing people to create unreadable code as a feature, not a negative. But I suspect that was mostly people who don't know how to program, and who now use python.

My real problem with Perl is that I cannot find anything, no matter how complex or involved or convoluted, that Perl can't do, the research, study, etc, is always 95-98% of the job, and the code is just a thing that will always work if I do it right, making it annoyingly easy to add features etc.

[explorador]

isitreal: I would however make one correction, SOAP and REST don't belong in your list, those are just secure data transfer protocols, that are actually a royal pain to use and setup. SOAP Is one of the hardest things I encountered to get working properly, so doesn't belong with the list of fad toys you gave.

I agree with everything you said. Regarding this specifically, it's part of the picture I wanted to paint regarding the topic and why sometimes I feel like a dinosaur. Example ahead...

I'm part of a FB group for coders in my country, and sometimes I just don't understand them!, some guy needs to retrieve some data, parse it, sort it and display it? ok, Perl can do that fast, PHP? sure, easy. But no... they say they need some expert because their routine reading in C# and then passing the data to JS and Node is having some glitches to communicate with some API before printing the html after the soap whatever... what the hell? it's like many programmers today feel the NEED to build something simple using 5 diff languages and unneeded processes just to tell someone "I know 5 diff languages", when in fact, this paints a picture that they don't know how to use ONE properly. I perfectly understand how a company might impose those needs "hey, we made this using C++ and we need to pass data to Java, etc", but when coders build their own nightmares? that's plain silly.

Talking with some coders today, locally, where I live... usually means "I need A->B->C", and I can say "hey, I can do that with Perl, or C# if you want to (and I would also do it with PHP, or... even Visual Basic), but it's so simple I only need one language, but no... other coders say "yeah we need first some AWS and then micro services blah blah" What?, and they are actually serious! no, most times they don't finish the projects.

@tangor, that shark bit was reaaaally clever.

[isitreal]

I don't think it's a need to use 5 languages, I think it's simple total incompetence.

I have been subject to this myself unfortunately, and did some really convoluted language mix hacks because I didn't know Perl well enough to realize it was the actual solution that was designed to solve the literal problem I had. Now I use it and replace all my cludges when they get in the way of progress or development. But I know that error well, and the high cost it has over time, and it's lack of competence, I include myself in that comment since I know the hacks I used over the years, which always involved mixing languages etc to achieve something Perl does natively.

But I would reiterate, Perl is too hard for today's script kiddies, pure and simple. It was made for a different generation, who were extreme experts in Unix and servers and hardware, and who understood what they were doing.

I started seeing this library nonsense years ago, while I use some basic stuff because it makes it a lot easier to do tricky eye candy stuff, I also never use it as a crutch, and I never used css libraries, which are to me about the dumbest thing I've ever come across, bloated, massive, many many KIB to achieve a simple result a few lines of clean CSS can achieve. On a recent personal project, for example, I almost succumbed to "laziness", and used a js library, but then I came to my senses, googled it a bit, and had the result running with maybe 20 lines of straight js.

But stuff like node.js is just a joke, to me, using js as an actual language with packages and modules is really absurd, totally unclear on the concept. I think a lot of the problem now comes from kids not knowing how to do server side programming, relying on prepackaged libraries for everything, then trying to cram it all together.

Python is also a contender for making people far worse programmers, as are JS libraries and frameworks etc, though maybe also it's worth adding in IDEs to that. I can't say, don't use that stuff, the old formula I have painfully proven to myself that a programmer does on average 10 lines of logic a day, year in and year out, which I scoffed at, until enough years had passed to make me realize I was in fact very roughly generating that many lines of logic a day on average, which makes the entire saving code and time thing somewhat nonsensical, like python believing that removing brackets or semicolons somehow makes you faster as a developer, when all it means is you should learn to touch type before you start learning to code....

The reality is, when you are doing anything non trivial, the coding is the smallest part of the job, with a few exceptions where the logic is very very difficult, then it might hit 10% of the project time. But when I read people talking about saving time typing, I know they aren't doing serious programming because the typing part is by far the smallest part of any non trivial programming project in my experience. Finding bugs, yes, that can eat up a lot of time, particularly if subtle, but writing or creating the code, no. Creating the logic itself, research, data collection, etc, that's most of the time.

Re SOAP, to me, that's more similar to SSH'ing into a bare metal server, and manually configuring the HTTP server configuration files or even worse, configuring IP Tables manually, than it is to using any type of library or high level thing. That was the only reason I objected to including core protocols in your list of fad toolkits libraries and other crutches.

[isitreal]

There's another issue, regular expressions, which I actually learned here, from the WebmasterWorld apache forum mod, I apologize for forgetting his name, but learning how to do regex via htaccess and httpd.conf, without having a debugger, just the dreaded server 500 response, that was hard, but the right way to learn. If I remember, I think I also learned js that way, it was before the js debuggers shipped.

So far Perl is the only language I have found (except for stuff like awk) that has fully native regular expressions, which are so powerful that to not have that makes me feel totally crippled, but learning regex is hard, and is one of the most terse and difficult things to learn I experienced when learning to program, but the payoff is massive, impossible things become easy often through that. There's no faking regex, you either learn it, or you create massive cludge workarounds to get around the fact you can't actually solve the problem the way it's intended to be solved. Takes a lot of work though.

I always wince when I see the crude hacks other languages use to emulate regex execution, to me, that might be the single thing that makes Perl totally irreplaceable to me. I think python requires a library to be loaded just to run regex, and it's not native then, nothing like $foo =~ s/(\d+)[a-z]?/$1/ is available.

[lucy24]

I apologize for forgetting his name

Ian, alias g1smd, would be my guess.

[explorador]

isitreal: I don't think it's a need to use 5 languages, I think it's simple total incompetence + But I would reiterate, Perl is too hard for today's script kiddies

I often get this perception, that today... lots of people do this because to them... it's a manifestation of skills (multiple skills) and much needed to impress others in the same world (knowing as little as they do, or ignoring as much as they do). It's like "I made this using just PHP, or just Perl, etc" doesn't seem to sound as powerful to them just like saying "I punched the guy so hard once, just once... he collapsed on the floor", but no, it seems they prefer "I hit him hard 20 times, then 20 kicks, you know, tae kwon do, and then 2 mortal jumps backwards landing on his belly, and finally finished him with a flying kick" <-- while this might look cool on films, such excess means the guy can barely punch, or does so like a weak kid.

regular expressions

I'm no expert, yes, I have used them, many times I need help with that, and sure find them incredibly useful in Perl. Tried REGEX using other languages and yes, it works, but naturally it's not the same, yet one can improve. Anyway, it's really something when you notice the difference in speed (using REGEX on other languages), and that brings lots of love back to Perl.

[isitreal]

explorador, I agree there's a certain amount of CV/resume packing going on, for example, there was a local sys admin job for government a friend who worked there told me about, so I checked out it since it was sure to be cushy and easy compared to the real world, but their listing said AWS top to bottom, and I have never dealt with AWS so I could not fake it or pretend. If I'd played around with even a little bit, I could have easily faked it, it's a low bar given organizations like the NSA have exposed entire datasets with an incorrectly configured AWS storage instance.

I view it more as failing to learn the basics at all, and relying on frameworks, toolkits, libraries, etc, all of which lock you into doing things the way they force you to do them, not the best way to do them.

There's also some other facts that I think have changed quite a bit, one is IT mobility, from what I understand, it's considered now very old fashioned to stay with the same company or employer for decades, which leads to very fast exits and rehires to new places, which leads to a few key things, one being not designing systems as if you were going to be the one to maintain it in 10 to 20 years, or more.

Throwaway code, that is, that will be someone eelse's problem when you leave. I had a friend who was a senior admin at a conglomeration of website properties, most of which you have heard of, and his last job was to dismantle this and sell off each property as a virtual machine, keys included. He was given a bonus to make him stay until the end, since most peoplel rushed out the doors. One thing that really struck me talking to him before this was his observationi that there were really only two people there who were competent, him and another senior dev, everyoene else was these weird types of largely useless corporate IT drones who don't know how to do anything but fake it enough to get hired.

And, again, this was a bunch of large sites we all know by name at least.

But the fundamental lack of skill in his coworkers is what really struck me, we talked a fair bit about it before the end, and it really struck me that there's a definite pattern of 'getting along with the team' over skill, something I've seen confirmed in various talks about what matters in these large organizations.

I had a similar aha moment when I was trying to figure out what 'parameters' in machine learning were actually referring to, I watched hours of expert discussions on machine learning, searched endlessly, and started to realize that most people who are doing machine learning have basically no idea of what they are actually doing, because they are all using something like tensorflow via python, and don't actually know what the module does behind the scenes. So all these people are doing this hip fad thing, billions poured into it, and the number of people who actually understand what the tools actually do appears to be extremely limited, which is probably one big reason all the big companies have the same technical issues, hit the same basic brick walls, etc.

But unless you are working at the cutting edge, the best most hip places, which is not google anymore, they have apparently fallen into IT middle age, and that's now considered a good place to have a secure IT career, like IBM or Microsoft used to be when google was coming up, it doesn't look like the actual skill levels are that great anymore. In advanced chip design, yes, but coding, I question it. Corporations do not like to depend on skill and talent, they want plug in workers who can be replaced, from what I have seen, there's almost a taboo against hiring the best and brightest in the corporate sector, except, again, for the leading/cutting edge places that siphon up all the best, currently places like spacex, tesla, maybe openAI and some other smaller startups. Google came right out and said that they had 'no moat' against the FOSS Llama, which is not technically free totally, but it is open source, which meant that their internal engineer memos considered that google has no actual real edge, or moat, against people running a few pcs in their garages, despite spending 10s of billions of dollars, and making their own dedicated machine learning processing units from scratch.

To me it's starting to look like we are ripe for the 'next big thing' because the big corporate compute companies all seem to be following the same broken models, relying on brute force and massively bad design to force out somewhat acceptable results.

But it may simply be a matter of lack of perspective, that is, maybe there were a few thousand really great engineers 25 years ago, and maybe there are a few thousand really great engineers today, and that it actually hasn't changed at all, it's just more diluted so it appears from a superficial perspective to be a decline in skill and ability.

I think you can roughly estimate how many really great ones there are by picking some percentage of hires for the top firms for engineering graduates, currently tesla and spacex, though Elon is doing his level best to destroy that mystique, along with the better startups, and it would not surprise me at all that the numbers of really good hackers is fairly constant. They will by definition be going to the most interesting problem that pays well, or in some cases, just to the most interesting problem which pays anything for the best ones I would guess.

The set you are describing I think just are not in that game at all, it's almost by definition, if you don't learn and master the core fundamentals, you certainly cannot be excellent at what you do, so those package/framework assemlbers are much closer to assembly line workers than hackers. I always like the Paul Graham essay 'Great Hackers' [paulgraham.com...] - it never gets old, and I don't think this has ever changed. The languages, the problems, etc, change, but the core population available doesn't change.

I think the thing that is much more visible now is that due to the proliferation of toolkits, frameworks, libraries, etc, it's easier for people who would never have made it in IT before to carve out a niche for themselves, like say, someone who learns the basics of setting up wordpress, extensions, then sells that to someone for a few hundred dollars. I used to get, somewhat routinely, through various connections, requests to fix or upgrade such messes, and I always turned them down because you can never fix that type of site, at least not economically, it's far too difficult, too expensive, but those people who toss them together are considered IT workers. Which they are, in the sense that a mcdonald's line worker is a cook.

lucy24, thanks, g1smd is the guy, now it comes back to me. I was curious how many names I'd see here that I recognized, more than I expected actually, which is nice.

[phranque]

until about 12 years ago, Jim (jdmorgan) was also making massive contributions to this forum.

[explorador]

isitreal: explorador, I agree there's a certain amount of CV/resume packing going on

yes, and with your post we get back to the origins of the thread.

Locally, we have discussed this with other "veteran" developers, and it's fun (and tragic) to evidence how many companies seek a DevOps or a Full Stack dev, and they don't know what it is, or the full extent of what it means. Same goes to developers, thinking being one of those means learning kung fu + karate + aikido + wrestling + scuba diving, whatever.

[Kendo]

Perl is like the shark: evolved before dinosaurs, refined while dinosaurs lived, and outlived the dinosaurs to the present day. Some things are just perfect.

The same can be said about Classic ASP.

[graeme_p]

I have never dealt with AWS so I could not fake it or pretend. If I'd played around with even a little bit, I could have easily faked it

Mostly that is what people are doing.

Very few organisations actually use AWS properly. The main reason they do it is 1) management have heard of it and 2) its other people's money and a small part of overall cost - if you spend 10x what you need to, but its still only 1% of the cost of developing and running the system no one cares.

A common pattern for SMEs is to use a single instance, and a single storage volume to essentially mimic a VPS. They could get that a lot cheaper using a VPS provider or AWS lightsail (which is a discounted version of the same). Another is the same but plus S3 (again, multiple cheaper ways of doing it). If they are really sophisticated they might use a hosted database or cloudfront (CDN) too.

Python is also a contender for making people far worse programmers, as are JS libraries and frameworks etc, though maybe also it's worth adding in IDEs to that.

I disagree about Python. I have tried multiple languages and keep coming back to it. I think you have been biased by an experience that involved both bad luck (I have been using Python as my main language for about 18 years and never had anything break on a minor version update that I can recall. If Python runs 10x slower than Perl either it was something Perl is particularly well suited too, or the Python code is bad.

As you like Paul Graham, on the subject of Python, have you read this: [paulgraham.com...] It is not the language that matters, so much as the developer's knowledge and ability.

like python believing that removing brackets or semicolons somehow makes you faster as a developer,

That is not the reasoning. It is that using indentation instead forces people to indent, which makes code more readable. Haskell lets you use either, and its considered good practice to use indentation. Brackets are more error prone than indentation is.

I view it more as failing to learn the basics at all, and relying on frameworks, toolkits, libraries, etc, all of which lock you into doing things the way they force you to do them, not the best way to do them.

I half agree there. I think frameworks and libraries can be great. Django is my bread and butter work. I have used numpy recently. The problems arise when:

1. people do not understand what the frameworks are doing. I once write my own web server in TCL. A huge case of NIH but it did make me understand HTTP a lot better.
2. people pulling in too many libraries, often for trivial things. Then you get things like the leftpad incidence. This is sometimes developer incompetence, sometimes management pushing people to do things too quickly to allow for doing things right.

it's far too difficult, too expensive, but those people who toss them together are considered IT workers. Which they are, in the sense that a mcdonald's line worker is a cook.

Yes, but people outside the industry do not understand. I love the comparison and will use it. People think IT is IT - hardware, software, PC support, whatever. I like comparing it to all the different jobs in healthcare (psychiatrist, surgeon, nurse, equipment maintenance, cleaners etc.).

[isitreal]

Reading a bit more, I will say, yes, I am a dinosaur because I come from the era that thought doing it yourself is a good idea, where you cannot learn something without learning the tools, and you can't learn the tools without getting into the guts. I can tell I have this attitude because every time someone says, oh, x or y is 'easy to learn', when I dig into it, I realize it's not easy, and they have not learned it, which is why they thought it was easy. I think this is symptomatic of today's tech culture, where staying in one job for any length of time is seen as unusual, which then directly maps to almost everything I write under here, particularly in terms of long term endurance of a project or feature or codebase or server or whatever. My time frame on some projects is now extending back to nearly 2005 in terms of support, up to the present. Nothing flaky or fashionable or hip can do that task. But I recognize I am maybe the last generation to feel this way, I see my peers retiring left and right now, and they are not replaced by the same mindset.

The thing that really started hitting me was this incredibly annoying feature of the modern computer world where users all gravitate to a single solution, when that single solution is not an actual panacea. Things like using git to grab a file instead of wget or curl, or using git instead of svn when your development flow is actually best handled by svn, or using python for everything, when really, if your interest is in doing heavy duty practical extraction and reporting, you want Perl, which was made for it. It's the tendency to focus on only one thing I find sad, it's like if you went into a carpenter's tool area and he had only a few tools, and used to them to do everything, like 1 hammer, 1 screwdriver, 1 chisel. Would have been unheard of in the past in any real trade, but seems to be the norm now.

My personal theory on this is that computing has actually grown too complicated for human brains in general, while our cognitive abilities are being degraded by the tech itself, and it's devolving back down to a level that more users can deal with, same as PC vs smart phone, one a very powerful flexible tool, with delicate complex I/O interfaces, and one a cludgy annoying simplified and dumbed down item. I don't think the overall decline we see is unrelated to the prevalence of smartphones growing up, or using the internet to look up stuff, as Nicholas Carr says, this is not an accident.

Again, I'm definitely a dinosaur, but I was honestly a dinosaur before I ever picked up a programming book, my approach to this stuff was always out of date and obsolete, and totally inappropriate for disposable human activities like computing. It's something of a small wonder I managed to even fake my way into making any money at all at this stuff given my attitudes towards craftsmanship etc.

AWS
What you say about AWS is what has struck me as well, also the abuse of containers and microservices when just running a VPS running the processes you need would do the same thing, and be far more controllable. Seems like a lot of effort goes into making systems that have no future beyond solving a problem that will explode some time after you leave for your next job when all those blobs start to fail randomly. In this regard, I'm most certainly a dinosaur, I want a real web hoster, with real support,and high end infrastructure, that is always there, day in and day out. That's who I use, and I honestly think I'd quit doing web work if our hoster went out of business or stopped, I've already been down that road and don't want to be on it again.

Python/Perl and Good Devs
[paulgraham.com...] the Graham article you posted seems to be a subset of this larger argument. Note that the Python one was written in 2004 and was not talking about Python per se being the advantage, it was talking about it being a somewhat hip new language and thus was more likely to attract smart young developers. I think not so much knowledge and ability as best and brightest, those drawn to the new and shiny thing. The goal there being not to use python, but to attract smart young developers.

To me, what Graham is arguing for there in the essay is not Python, it's finding the current hip language or tech so you can hire the best young developers, that's certainly not Python today, but it does have a lot of users so your hiring base is certainly much larger. But he was comparing to Java, which as he noted in Great Hackers, has probably only 1 great hacker using it, it's author, back in Sun Microsystems days. In other words, a language so boring and unfun to use that you have pay someone to do it. That's still the case with Java, like FORTRAN and COBOL, but oddly, doeesn't seem to have ever been the case with C, C++, and now Go and Rust, which seem to have large groups of people doing free software, which often means they are basically doing it for free, or close to free.

Interestingly, in the article I link to, written in 2002, he cites Perl as being the language used by smart young developers, and just starting to see movement on that front from Python. But the core argument, find the bright hip new thing that young devs are into and hire that, to get the devs, is certainly the case still, that's why Tesla and SpaceX are destinations 1 and 2 for young engineers out of college, though Elon is doing his level best to break that with his absurd non engineering views of reality, which are going to start costing those companies in the very near future because it's not really cute anymore. But that cutting edge is fickle, Google used to be it as we all saw back here in the day watching them develop and interact like real engineers. I don't think Microsoft ever was because it was always about corporate computing and monopolistic behavior. But that paid, I met a guy in his 20s who had retired, he had worked on MS Office doing boring garbage, but he got paid enough to retire early. Maybe early 30s, I forget.

To Bracket or to get lost?
The python guy I was collaborating back then worked in industry, some military thing, and what struck me was that his coding standards kind of highlighted how absurd removing brackets is, since he'd use comments to indicate where blocks end, and which block was ending, because it's so hard to actually see that with only tabs. or is it spaces? I forget.

When you do vertical scanning of long code files an empty space does you no good at all, so you have to add in a comment to say: this is where the close is. The bracket is a visual cue that allows you to match the indentation of the start bracket with the indentation of the end. I don't think I could actually program without that since I depend so heavily on it. In fact, my most recent years have seen my increasingly removing things that obstruct clear vision of start/end brackets, like one liners since they always end up making problems for the code maintainability over time. My code is getting more and more 'boring' I find, because clear fast scanning is far more important to me now than it was in the past.

I view things like brackets and ; line enders as things that give me flexibility as a developer. For example, if I have a long string and want it to extend to the next line, I want that to be governed by my stating: the ; ends this, not the linebreak or indentation. In text, it's like saying you don't need punctuation to end sentences, or commas to separate clauses, etc.

In other words, while I know what you are talking about re brackets being more 'error prone', I don't agree that is a bad thing, it's like a language that does not crash on compile when you make a mistake, making the error harder to find. I tend towards using a lot of indentation levels, and I can think of nothing harder to debug than if I messed up an indentation level in python, since there would be no visual cues at all to help pinpoint the error. But that's what makes a language a good or bad choice I think for a person, this type of fundamental requirement for how you perceive the code and work with it. Maybe it's like saying a hammer is more prone to bending a nail than an air driven nail gun. But the hammer gives far better control of the action and operation, but takes more skill to use. Which I think is what it roughly boils down to.

The Subjective Element
What I found interesting in the Graham python article is that the person he's talking about cites python's 'look/feel' re the code itself as the reason the person using it preferred it. Which shows how subjective that is, for me, it's the reason I don't use it or like it. I am pretty sure that 'saving keystrokes' was an explicit goal of python. Which was and is silly since you do roughly 10 lines of logic a day, give or take.

But I think Graham nailed it, it comes down to what you want to see on your code editor, which is basically probably a reflection of how your brain basically works, which suggests to me that python attracts a type of brain fundamentally different from what the more classical approaches do, like C, Perl, PHP etc, which all use fairly similar programming syntax. It's like preferring cats or dogs, I think, it reflects something more core about the personality than we might realize. To me, for example, I find python extremely annoying to look at, I find its lack of native regular expressions silly, but if I were doing something requiring multithreading, I'd be unlikely to think perl is a good idea, though I have done it, but it is HARD to do, it's something tacked on via a module, similar to python having regex tacked on via a library.

Practical Extraction And Reporting Language
I agree that the speed comes from something Perl is uniquely designed to do, and which python is poor at, namely being a Practical Extraction And Reporting Language. Thus my dismay at the market deciding that one tool, which is good for some things, but bad at others, is the tool everyone is pointed to.

You can see the speed difference between python and perl in massive looping and reading operations, massive regex use, I don't think we're talking about coding skill, this particular algo I think was something like 50 lines in Perl (basically my first real Perl, so no skill on my part for sure) and about 200 in python (by someone who was doing it for a living at that point, for military applications), but I can't speak to the quality of the python code, but I can to the fact it broke in a minor version update, which is unacceptable to me. That is, a language feature was not only removed, it was changed to be something else, if I remember right. For me, code durability is very very important.

But I think it's mostly because this language was made when to be effective and efficient you had to be closer to bare metal in your understanding, so it's just really fast. It was using C as the standard of speed, and it shows all over. While in a sense, younger me might think it was interesting demonstrating in code speed issues between Python and Perl, older me knows there is no need to do that test since I've seen it my entire computing life. Python dev time, maybe faster, probably, execution, probably slower. Even dev time may depend on the problem, there's not one solution for all problems.

If I remember one of the core things that makes Python slow is that it treats everything as an object. This adds a lot of overhead to the execution because the language has to figure out what everything as it runs. Javascript has has a similar issue as well, for the same reason. While not fully typed, Perl is much more typed, a scalar is a scalar, an array is an array, a hash is a hash (ok ok, it's a special type of list, but it uses % so Perl doesn't have to guess), a function is a function (well, ok, it's a sub), and a class is a class (again, ok ok, it's a package). This means the compiler never has to guess what those things are as it executes and compiles. I don't think this is something you can fix because it's a core language feature, not a bug.

Language Stability vs Rapid Feature Development and Change
I did not have 'bad luck', I had a normal experience with a python version update, directly caused by the attitude of the python project towards code breakage on version upgrades, which has never stopped being an issue. To be fair, python is not the only project to suffer this, GNOME and KDE both have this fatal flaw, which is why I don't use them anymore, I'm not interested in that game. Windows also has suffered that issue massively, and now apparently enjoys only about 65% marketshare, probably as a direct result of their stupid changes version to version.

I view python's number one real world problem as breaking the language interface across versions, I want to say my first personal experience was 2.24 to 2.25. This is always the problem python has had, lack of internal discipline in the project. Or maybe better put, the difference in priorities. Language stability vs adding features and not worrying about breakages. Both have their good and bad sides. For me stability is number 1. I can, and do, run my code on 15 year old operating systems, and in some recent tests, some guys made it run on even older stuff. That's the same code that runs on today's stuff.

I am increasingly a huge fan of incremental development, I do it on all my work stuff, all my own projects, and even when I did massive rewrite of an entire codebase into a new language, I made it be 100% feature complete with the old version before releasing it. Except for the bugs that were fixed, of course, and the new bugs introduced. Kids do not do this, they just break the stuff and go on, because not breaking things is a lot harder, and takes more discipline. I see that type of sloppiness happen all the time, and I'm too old to find that interesting or a useful way to spend my time, so I don't use the stuff that does it. I laugh when they make up BS marketing terms for this style or programming, like Agile or whatever. To me it's just caring for your users, not breaking stuff, adding stuff carefully, and always upgrading.

If you follow FOSS, you know that these breakages are not a minor feature, it's the norm with Python version updates, huge issues, tons of breakages, major PITA for maintainers and packagers, and users, this is if anything a feature, not a bug, of python, directly related to its focus on the present and not on being a stable reliable language, but being something you can whip out solutions today without needing all that much skill, which is why it's so popular with scientists and engineers etc, who aren't necessarily programmers first. This is why I don't consider python for even a second when I'm deciding what to use since that is the opposite of my focus. Since Python showed us long ago what it is good at, and what it does not care about, i respect that. While you may have been spared this in your code, the larger pool of projects has not been so fortunate.

For me, the thing that totally soured me on Python is the ongoing reality you see in GNU/Linux, where there will be programs you grow to rely on, then a python major version upgrade hits, and they break, and nobody feels like fixing them since it's such a royal pain. So the programs go away.

Also, the consistently slow interfaces when they are gui was a real hallmark of python software, in fact, when a program was slow, I was never surprised to find it was python. From using such projects for a long time, I started to realize that many are people learning python, because doing a project is the best way to learn, and thus, they lose interest and don't care about the project. I would say for a serious free software project, python might be one of the very worst choices you can make if you want it be around a long time. For fast moving stuff, like tensorflow and that machine learning stuff, totally does not matter since those things have probably a 6 month or less life in the real world, and should be moving fast. Making python an ideal choice for them since the code is basically throwaway.

I was not surprised at all when Guido quit as leader by the way, the problems with the project were self evident to me as an outsider. To me, python remains best at what it is good at, enabling very quick solutions where the durability of the code does not matter. This is why I am drawn to stuff like PHP and Perl 5, their intense respect for existing codebases, and the glacial pace of change, the heavy community RFC focus, and the lengthy deprecation warning periods which generally give me 5 years or more to update running codebases. Usually more.

If i remember right, Google prototyped in python, then wrote to C (and now Go). I think a lot of machine learning stuff prototypes in python too because its so fast to get something up and running, then when they know what they want, they use a compiled language since it's so much faster, Tesla does that as well I believe.

To Binary or not to Binary
In a sense, to me the real question is much more, compiled into a binary, or compiled at runtime, again, maybe a core feature of the personality, when I do something, I want to test and debug it instantly, and don't care about the performance gain using the compiled to binary language might offer since that gain would be decimated by the increased development time. Python if my fuzzy memory is right has a sort of workaround where something is compiled to a type of binary then run, Perl actually also had that, but it never caught on and was not native.

Sometimes I am tempted to look at compiled stuff, but then I get instantly back to reality, and go, yeah, right, and have to worry about it compiling for any platform, anywhere, at any time, what fun! But I have been tempted to do some tests, but not tempted enough to do them. Takes too much time.

To me, Perl remains the glue between C and core machine code and higher level, something I suspect will never be seen again because the need to optimize and boost performance on super low power hardware is I think only a thing now in the embedded space, where you would use binaries anyway, not scripting language.

So the problem and thinking that created Perl don't exist today, but luckily for some weird or maybe not so weird reason, perl 5 did not die, in fact, it's thriving, and probably doing far better than the much cludgier Raku aka Perl 6, whose code samples I looked at 1x, and whose core logic I looked at a bit more, and said to myself, this does not solve a single problem I have, and it's ugly.

But I think the challenge to learn Perl today is much larger than it was in 2000, since back then, the average 'computer person' was far more tech savvy, particularly when it came to the hardware and underlying stuff, than they are today. But if you start to dip towards the hardware, then the logic of Perl starts to get really understandable, since you are much closer to the bar metal than maybe any other scripting language,and it shows in the speed.

But learning Perl certainly and without any question made me a much better programmer, because to use it effectively you had to start thinking how it thinks, which is far closer to the metal than almost any other scripting language. The more I learned how to think this way, the more my Perl improved. Not that most people would like it, or want to deal with it, but perl forced me to get better because you can't optimize it effectively without getting much better at it, which means, learning to think more like the machine. Which is very unhealthy, but not as unhealthy as writing C or machine code directly.

Frameworks etc
Frameworks, in particular javascript frameworks, to me are one of the very worst things to have happened to the internet, in terms of making pages out of them totally, not using them as useful tools. To me, using something like CSS frameworks or libaries or whatever they call them is really absurd, that's purely someone not wanting to learn CSS, but the javascript stuff can be useful. I thought, and still think, jquery was a nice wrapper for some javascript enhancements, as long as it's not used as a crutch. And it's been stable and reliable.

But again, keeping with the carpenter analogy, frameworks/libraries etc are going to Home Depot and buying prebuilt cabinets. Coding and programming is making them yourself, the two views are not compatible, and the outcomes aren't either. However, the way tech works, almost nobody cares about the actual quality of the stuff anymore, they just want to see the results, for as cheap as possible, then when it breaks, or the AWS bill comes in, they funnel more money out to some corporation that is already far too big for humanity's good. Not a promising future, and I can state with absolute certainty if I had entered the field now, I would not have entered it, and found something else to do.

[isitreal]

By the way, rereading the above, which I actually edited a lot to make it readable, it strikes me it's almost a farewell to this work and career, since what attracted me to this area initially is now largely gone. While I haven't read it, I suspect Yanis Varoufakis new book TechnoFeudalism may cover some of the real problems with today's tech. Kind of the opposite of what I'm looking for. So it's no surprise that the various tech out there is increasingly the opposite of what I want, the motivation behind it is fundamentally different.

Write your own flat file CMS? Make code that endures and is maintainable? Care about performance and code quality at the same time? Spend hours to make code look better, cleaner, easier to read? Who has time for such nonsense!

One of the biggest compliments I ever got was from some guy who emailed me about a small PHP library I had out there, and said it was like poetry. That may have actually been the only meaningful compliment I've ever gotten on my code now that I think about it. What's striking is that I now view that code with a shudder, somewhat horrifying, and don't touch it anymore, yet there had to be something about it that person could see that made it different from other code bits around at the time. Or maybe the people who could see that care were there back then, and now aren't, who knows?

This farewell is probably why I decided to come back and do a few more posts. Maybe there is something I wanted to sort of wrap up before moving on, and what better place than where I basically started, WebmasterWorld.

[graeme_p]

To me, what Graham is arguing for there in the essay is not Python, it's finding the current hip language or tech so you can hire the best young developers, that's certainly not Python today, but it does have a lot of users so your hiring base is certainly much larger.

Yes, but it needs to be a good language to attract good developers.

The python guy I was collaborating back then worked in industry, some military thing, and what struck me was that his coding standards kind of highlighted how absurd removing brackets is, since he'd use comments to indicate where blocks end, and which block was ending, because it's so hard to actually see that with only tabs. or is it spaces? I forget.

Someone who does that has not adjusted to Python. The whole point of using indentation is that it is easy to see where blocks end. It can be tabs or spaces BTW, although the convention is four spaces per level and editors and linters should enforce that or highlight departures from it.

I think was something like 50 lines in Perl (basically my first real Perl, so no skill on my part for sure) and about 200 in python (by someone who was doing it for a living at that point, for military applications), but I can't speak to the quality of the python code, but I can to the fact it broke in a minor version update, which is unacceptable to me.

Definitely very poor quality python code. Assuming lines are roughly equally complex, there is no way Python code should be four times as many lines. The same for breaking on a minor version update , and for being much slower than Perl. As for performance in things like loops Python seems faster: [benchmarksgame-team.pages.debian.net...] and that is using the slowest implementation without any extensions. Pypy or numba make code a LOT faster. (I recently got about a 10x increase in numerical code just by applying numba to it)

If you want to write fast Python code you need to understand the language. When to use a list comprehension of generator expression instead of a loop. When to use C or Cython extension. When to use Pypy or numba.

I am increasingly a huge fan of incremental development, I do it on all my work stuff, all my own projects, and even when I did massive rewrite of an entire codebase into a new language, I made it be 100% feature complete with the old version before releasing it. Except for the bugs that were fixed, of course, and the new bugs introduced. Kids do not do this, they just break the stuff and go on, because not breaking things is a lot harder, and takes more discipline

It is usually the fault of management, not the developers. Some businesses have adopted Facebook's "move fast and break things". Others have too much time pressure, and do not care about code quality.

f you follow FOSS, you know that these breakages are not a minor feature, it's the norm with Python version updates

Only major version updates. And even Python 2 to Python 3 is a far smaller change than perl 5 to perl 6 - most of the changes can be automated. I do follow FOSS, and Python in particular, and things breaking between version updates is rare. perl 5 is stable because it has not had a major version update because development stopped.

To me, Perl remains the glue between C and core machine code and higher level

It exists. it is how the Python machine learning and numerical computing libraries work: the actual base libraries that do the computations are written in C or Fortran.

For me, the thing that totally soured me on Python is the ongoing reality you see in GNU/Linux, where there will be programs you grow to rely on, then a python major version upgrade hits, and they break, and nobody feels like fixing them since it's such a royal pain. So the programs go away.

There was 20 years between the release of Python 2 and its discontinuation. Python 3, the next major version was released in 2008 an there are no plans for another major version yet.

Python if my fuzzy memory is right has a sort of workaround where something is compiled to a type of binary then run, Perl actually also had that, but it never caught on and was not native.

Most languages not compiled to machine code work that way, including PHP, Java, TCL, Raku: [en.wikipedia.org...]

Frameworks, in particular javascript frameworks, to me are one of the very worst things to have happened to the internet, in terms of making pages out of them totally, not using them as useful tools. To me, using something like CSS frameworks or libaries or whatever they call them is really absurd, that's purely someone not wanting to learn CSS, but the javascript stuff can be useful.

I agree somewhat. I use CSS frameworks as shortcut - as a sort of flexible prebuilt theme. I am also a back end developer so like to have a pre-built frontend, as long as it is not bloated.

I do hate seeing huge CSS and JS files generated by frameworks, and think single page web apps are a horror.

While not fully typed, Perl is much more typed, a scalar is a scalar, an array is an array, a hash is a hash (ok ok, it's a special type of list, but it uses % so Perl doesn't have to guess), a function is a function (well, ok, it's a sub), and a class is a class (again, ok ok, it's a package). This means the compiler never has to guess what those things are as it executes and compiles. I don't think this is something you can fix because it's a core language feature, not a bug.

Python is strongly typed. While "everything is an object is true" it has alll the types Perl has and more. Unlike a language like Javascript you cannot do things like "1" + 1. In fact, one of the things I love about Python are the amazing built in types - everything from datetime to sets. This relates to why we do not use regexes so much in Python: we use built in types rather than storing so many things as strings.

it comes down to what you want to see on your code editor, which is basically probably a reflection of how your brain basically works, which suggests to me that python attracts a type of brain fundamentally different from what the more classical approaches do, like C, Perl, PHP etc

I think some people get used to a syntax and cannot get used to a new one. i have used C, PHP (a lot) TCL (also a lot) and other bracket languages. I have also used Python a lot and I found I prefer it.

I can think of nothing harder to debug than if I messed up an indentation level in python, since there would be no visual cues at all to help pinpoint the error.

Bad indentation usually causes an error at the point where it is wrong. Very often a syntax error that shows in the editor. It is a lot easier to spot than a misplaced bracket because the indentation is a cue.

However, the way tech works, almost nobody cares about the actual quality of the stuff anymore, they just want to see the results, for as cheap as possible, then when it breaks, or the AWS bill comes in

I agree. Again this is bad (short termist and CYA) management.

Write your own flat file CMS? Make code that endures and is maintainable? Care about performance and code quality at the same time? Spend hours to make code look better, cleaner, easier to read? Who has time for such nonsense!

I push clients to improve incrementally, put time into code quality etc. The problem is not everyone is willing to do that.

Sometimes I am tempted to look at compiled stuff, but then I get instantly back to reality, and go, yeah, right, and have to worry about it compiling for any platform, anywhere, at any time, what fun!

Not a problem with JIT compiled languages. You get a speed increase without that. Pypy and Numba for Python, Java (the bytecode is compiled on the fly), Erlang in recent versions. PHP 8 can do it too.

Also not a problem for server software where you only usually need to target one platform.

While I haven't read it, I suspect Yanis Varoufakis new book TechnoFeudalism may cover some of the real problems with today's tech.

I think it does. I watched an interview of him recently. I think tech is reflecting AND changing the broader economic and business environment context. Tech moves power from consumers to producers.

By the way, rereading the above, which I actually edited a lot to make it readable, it strikes me it's almost a farewell to this work and career, since what attracted me to this area initially is now largely gone

I agree with you in pessimism. Tech that should have made the world a better place is now making it worse.

[lucy24]

Someone who does that has not adjusted to Python. The whole point of using indentation is that it is easy to see where blocks end.

Doesn't fortran also go by indentation? I'm pretty sure most dialects of basic (aka Fortran For Dummies) did, and it was a jolt when I first met javascript/php and had to remember all those braces { } and parentheses ( ).

[isitreal]

Thanks for the corrections re python internals, but the sad fact it, it bugs me visually and I can't look at it.

I think, and strongly suspect, I code significantly different than you do. There's no 'indent or no indent' issue, I use indenting, and rely on it, and I rely on the brackets to make complex stuff understandable. In fact, I've fixed complex indenting issues by using bracketing, working on a super old library that had worst in class everything but which we depend on, that's how I fixed and debugged it, they had not used consistent bracketing, and the only way I could fix it and debug it was to fix all the indentation and bracketing, it was very complicated to do, and took a while. The two are not mutually exclusive, they enhance each-other.

If I remember right, those comments I mentioned were coding standards at his organization, which is why he used them, and I could totally see why they were needed, you could not read the code without them. I'm not sure we look at the same types of code, or write the same, because this is so obvious to me visually that it can't be something I'm missing. It is almost certain that when you use the language certain things are so difficult to do that you train yourself not to do them, that's my suspicion, and thus have no issues once you've adapted. Perl has similar things I am getting trained by it to do because to not do them causes long term pain, and in particular, hard to resolve optimization and testing issues.

I've seen this self training in Mac users in particular because whenever I've approached a mac I hit the edge of the walled garden usually within a few minutes, if that long, because I'm trained on Linux and have expectations of how much you can toss at a system, how robust it is, etc, and what you can make it do. Part of that training is adapting to not having certain software solutions that you can get on commercial platforms, of course. Mac users tend to simply reduce their expectations because to be happy you have to stay inside that wall. That's why I can't use macs, for example, I can't stay inside those walls.

I also have in the past read that some of the newer python things have finally sped it up, but I have this odd thing where I don't give participation awards for projects that took too long to do something but then finally get it done, I just go, fine, whatever, it took you too long, not interested. I basically just lost interest. I'd have to check into the major version breaks, but it wasn't just 2.x to 3.

I think pypy is what I was thinking about when it came to the speed-ups, but I stopped following this stuff closely years ago, now I only learn what I absolutely need to learn, which can be a lot, but it's not in general related to new programming languages, for me, the language is a very small part of the actual development process, probably less than 2-5% or so. As Linus Thorvalds said, it's 1% inspiration, 99% perspiration, where perspiration is data collection, research, testing, etc. My only requirement is that the language not only not get in the way, but that it actually advanced the project by never getting in the way in any way. Oddly, Perl seems to excel at that, I am certain that for my needs, there is no other language that can do what I require, so I'm glad that's a stable project with high regard for long term stability over anything else.

You see this running say, code written to be compatible with Perl 5.010 or 5.008, which is almost 20 years old now, running perfectly on 5.36, that's kind of next level. Not even PHP can hit that level I think, they changed a few things from 3 to 5 that would break certain things between 3 and 8. Not a lot, but enough. I've upgraded a few libraries over past years for that, and you can't in general run PHP 3 code of any complexity on new PHP, but the fixes are absolutely minor, with one or two exceptions, which are really difficult to fix since the old methods were absolutely insane (mostly around lists) and should never have existed. Which is why they dumped them.

I had grown a bit curious about Go and Rust, but when I realized Go is a language designed explicitly to solve large scale corporate software generation issues, I lost interest, but some features sounded interesting. One smart guy who runs a small company I know rewrote their backend stuff into Go, and he'd really never used it before, so it can't be that difficult. Rust was also sounding interesting until they had some internal blowup I think last year, can't remember.

This type of blowup I've seen firsthand and know how damaging they can be so I lost interest there too. These happen with disturbing regularity in the free software world, for example, Manjaro had one I think a few summers ago, and their best guy left, and the entire internal culture of the distribution fundamentally changed, and not for the better. That was quite striking to watch.

I like the intensely boring nature of Perl 5. Very incremental changes, so much so that while 7 was scheduled, and would have some super minor breaking changes, even those were considered too much so they have delayed Perl 7. I think that was probably a mistake, but I have to assume some significant Perl stakeholder had a say there.I already tested my code and it's fully Perl 7 compatible, I don't think it required any changes.

I think you may have missed what happened re Perl 6, which will never be released, Perl 6 was slated to replace perl 5, but it never did, took forever, was too different, and became a new language, Raku, which now is free to succeed or fail on its own. It's one of those weird Lisp style languages where it can basically be made to do anything, it's confusing to understand, but it can at core be altered to be what you want, so it kind of takes the entire There's More Than One Way To Do It thing and takes it the extreme, it was interesting in theory reading about it, but for practical purposes, had zero solutions to offer me so I just said, good call, glad you aren't new perl, thanks, now let's move on with a stable good language. Raku is also apparently quite slow, or was, because it has not yet been heavily optimized.

I had been looking for a highly stable language to solve some core issues I was having and had ignored Perl 5 since I also kept thinking that it was getting replaced by Perl 6, but it was only when I happened to watch a long talk by the current perl 5 project leader that I realized what had happened, and that in fact, Perl 5 was the exact right language, which is why it has not died, by the way, there's still nothing like it.

But Perl did what PHP did, skipped 6, which will never exist, but unlike PHP, 6 becomes Raku, a full split, and 7 is just 5 with some bad cruft removed. My guess, if it's worth anything, is that Amazon still runs a lot of Perl, and did not want breaking changes, but wanted Perl to be updated. That's just a guess because 7 was scheduled for release, the testers were released, the libraries, etc, so you could check your existing 5.32 code, then it was quietly dropped and I think 5.34 is now current. No, sorry, it's at 5.36, at least in Debian Testing. But this is all good, because it's done to maintain stabilty, and honestly, the breaking changes for 7 only impacted bad code which should be fixed anyway, mine required zero fixes or changes.

Similar to if you had good PHP 5 there were really no changes for 7 beyond maybe mysqli, but I think that was already in 5, can't remember.

One thing that really struck me recently I was doing a big documentation update, and went in and looked at all the google webmaster features, which I don't normally deal with on my end except for documenting the stuff so we have some idea what is going on, and I was truly shocked at how it had gone from being a kind of cool engineer webmaster oriented system to a groteque corporate oriented system, that is barely comprehensible to normal humans. It was clear their interfaces for their tools are now written for full time corporate employees, and not actual developers who might do them among many other things. This made me never want to use that garbage again, and it really drove home that google has gone from being destination one for best engineers to secure corporate job. Total convoluted mess, would naver have been done that way back when google was run by great engineers.

I'm going to read TechnoFeudalism, but I have a strong feeling he's going to exaggerate some features of it because he's an outsider looking in, and probably doesn't understand most of the tech, and almost certainly does not understand how fraudulent a lot of modern AI really is, but that does not diminish the power of monopolies, nor their threat. That's usually what happens when non specialists try to dive into tech. I have it, and will read it, he's a good writer, I've read several of his books. His Adults in the Room was an eye opener into the reality of the Euro state project.

Short termist is I think growing into a significant issue due directly to how people view employment, and how employers view employees. It's a fundamentally different world, you had _careers_ at IBM, Sun, Microsoft (not citing them as paragons), HP, etc, now you have short term rentals as I think the norm, ideally with a stock option cashout as often as possible. I view the use of frameworks and libraries etc as part of that generic approach to the work, the goal of corporate employers is, strongly, to not depend on single points of failure in their development, which shoots it way down in terms of quality.

The ability of talented individuals doesn't seem to be diminished, for example, the comma.ai guy I think wrote a big chunk of their self driving stack by himself, I don't follow them anymore, but he is/was competitive with the billion dollar self driving car players, at least relatively speaking. But the space such individuals can find a place to do that type of thing seems to be shrinking rapidly.

I ended up being a true generalist, and do backend and front end, which makes the onslaught of the zombie sites running wordpress somewhat extra tragic for me to watch.

[isitreal]

lucy24, I don't know re fortran, my dad wrote a lot of it back in the day, millions of lines if I remember right, but I never looked at it. But I think that is right, but it was a super simplistic language, and could not do very much, so I doubt it had very complicated structure, plus you used punch cards initially if I remember right, so there's almost no comparison when it comes to generating code. I think I remember seeing some of his and it just looked like a bunch of lines of words stacked on top of eachother, nothing like modern code.

There's some really silly stuff that carried over from those early days, like the absurd 80 column widths of code in many projects, something that stopped being relevant I think in the 80s or early 90s, but still stubbornly persists. Many virtual terminals still open to the old monochrome CRT tiny screen size of something like 80 columns x 40 rows as default.

I find that the more complex my code gets, the more I rely on such structures and syntax, it's definitely changed for me, but that's because the codebases I'm working on are far larger than in the past. I can always tell when someone doesn't rely on vertical fast scrolling scanning, that will essentially roughly define what their code looks like I suspect. not recommending what I do at all, but it's powerful and effective. But I've seen what restricting styles does to code, it's not a positive in many cases. That's why I don't like python. There are many great reasons to like it, but that's what I don't like about it, they made decisions I don't want made for me,, for reasons I don't agree with, and which I think are not positive for me.

My very very strong suspicion is that ones coding style changes fundamentally to fit in with the most restrictive language one uses in terms of syntax and style. it's probably too difficult to actually change such core things, so one would simply adopt the same style for most of the languages one uses, when it comes to complexity and depth of indentation and so on.

Obviously makes zero difference in the real world, you write some code, it runs a while, then it dies, and nothinig changes at all, it's not like doing real writing or creation. But it is telling to me at certain levels.

I was lucky, I learned initially on I think C style syntax (javascript if I remember right as the very first one, mainly I think it was easy to run it in a browser and you didn't need compilers or anything so ideal for an intro class), and adapted myself to that.

By the way, don't get me wrong, I'm not a Perl graybeard, my first approach to Perl was in the horrible write only days, and I hated it, that's why I went to PHP, I thought for years of PHP as fixed Perl since it didn't allow that write only style at all, it's only in recent years that I actually learned Perl, which probably makes me an outlier in the Perl world, and it was only in very recent years that i started using it for production, after I got good enough at it to understand why I should have used it all along for work for backend server stuff.

I now regret almost every shell script I have running, whenever i try to work with them, they are so absurdly clunky and cludgy, and so utterly lacking in native features, that I now in general dump them and rewrite them into perl as soon as I hit a real issue with updates or new features or fixing broken things.

I suspect this puts me in a very tiny minority of perl users, a 'newbie', but a newbie who uses it really heavily, as my primary language. When I was learning it, I used to tell a friend of mine who had used it a fair amount that I thought it was designed by clinically insane people, but then I started to see what it actually was good for and I slowly started to drop that view, and now my only objection to it is that there is nothing I think of, in a very complicated set of projects, that it can't do, so I generally end up doing whatever I think of.

I think it has literally only been this past year that I find myself getting annoyed that PHP doesn't have @array or %hash types, I think that's the first time ever I wanted something Perl does that PHP does not do, and am finding the absence an annoyance, though I like how loose PHP arrays are.

But one thing I can say for sure, nobody who uses a lot of regex, always, everywhere, would rpefer python, that's for certain, yes, like PHP, you can work around the non native way it uses it, but once you get to a certain point, you just can't do it without having it be part of the core language structure. That's what makes real perl hard to read for people I suspect, that and maybe references, which are hard to grasp.

Not selling it though, just noting that my approach to this was fairly objective, I had no skin in the game, it was really setting some requirements, then looking for what meets them, and realizing only one thing does. Technically two do, but I used the other one for a long time and that is clinically insane to do.

Speed
I don't buy that python is faster, so I googled it, and it's not, nothing has changed, at least not when these people tested it. I know how much regex I use, and there is simply no way something as high level as python can touch the speed of Perl.

This test was done in 2020:

[perlmaven.com...]

Perl Maven is a primary Perl guy, so I tend to trust him:

Comparing the speed
$ time python examples/grep_speed.py a.txt 20

real 0m9.610s
user 0m9.590s
sys 0m0.020s
$ time perl examples/grep_speed.pl a.txt 20

real 0m1.275s
user 0m1.253s
sys 0m0.021s
Perl is about 8 times faster than Python.

Comparing the speed of the more complex examples
$ time python examples/grep_speed_oxo.py a.txt 20

real 0m24.472s
user 0m24.401s
sys 0m0.036s
$ time perl examples/grep_speed.pl a.txt 20

real 0m1.239s
user 0m1.227s
sys 0m0.012s

Version information
$ python -V
Python 3.8.2
$ perl -v
This is perl 5, version 30, subversion 1 (v5.30.1) built for x86_64-linux

This is the exact type of speed difference I expected to see, because I've seen it my entire life. I was absolutely shocked when I first ran Perl on this type of stuff, I could not believe how fast it was, and I still cannot believe it, it's absolutely next level when you get into complex regex, it's so fast that it actually makes me sloppy with regex because no matter how much I use, and I use a LOT, it is simply not even measurable in any real way when compared to the overall excution times of all the features. I mean, yes, it's measurable if you use something like NYTProf, but you can't see it at all without doing that type of advanced optimization testing.

Note also what he is calling 'complex' regex I consider to be largely trivial and simple.

So no, not buying it. For text processing and report generation, use the tool that is designed to do that.

Python didn't take over because it was better, it took over because it's simpler to learn, and makes certain things easier that are hard otherwise. I think what they basically did was something similar to what PHP did, get some addons to speed up its inherent slowness, because that started becoming more and more of an issue as it was used for heavier duty stuff. Python grew because it was user friendly, same as PHP. I agree with this, by the way, I find Perl user unfriendly, precisely because it is so close to bare metal that it makes you learn how the hardware works to do it well.

2023 comparison:
[fiverr.com...]

Perl is the winner for text processing
Perl shines in text processing and report generation. Its speed in this respect is unmatched. Perl performs up to 20 times faster than Python for certain text manipulation actions.

One test shows Perl running eight times faster than Python for a moderately sized data set. Perl is an excellent option for companies that need to crunch gigabytes of text data.

Perl uses regular expressions (regexes) extensively. Regular expressions is a field of programming focused on string and text processing. By using predefined “metacharacters,” regular expression engines can easily extract and modify large amounts of text.

Virtually every major programming language today has support for regular expressions, whether inherently or as part of a regex library. Perl differentiates itself in that regular expressions are deeply integrated into the language itself, not requiring additional libraries.

Python’s regex functionality is also extensive but far more readable. Python is the better choice for small text-file operations from the standpoint of readability.

By the way, I TOTALLY disagree with that last article that non native regex is more readable, to me that only makes sense if you do not know regex at all, I find non native regex like python and php have to be totally unreadable, utter cludges, awkward, and annoying, and as a result, I always use regex far less in PHP for example, which is essentially the same as python in terms of how you use it in the language, whereas in Perl I don't even think when I use it, it's like typing if or else or == or ne, so I use it a lot more.

I definitely made the right choice, and the two languages are not good at the same things, it's a core design issue, you can't work around that fact, one is going to be better than the other depending on the task.

But even this discussion proves that I'm a dinosaur, because only a dinosaur would care to have this power in the language in the first place. I like httpd.conf/.htaccess modrewrite even more since that totally dispenses with the verbosity of Perl's regex,lol. Pain to debug though.

Note again, these examples are fromn 2020, and 2023, and this speed difference as far as I know has never really been different, so if they came up with something in the last few months that speeds it up a bit more, tha doesn't matter since that's like 25 years too late.

[graeme_p]

I've seen this self training in Mac users in particular because whenever I've approached a mac I hit the edge of the walled garden usually within a few minutes, if that long, because I'm trained on Linux and have expectations of how much you can toss at a system, how robust it is, etc, and what you can make it do. Part of that training is adapting to not having certain software solutions that you can get on commercial platforms, of course. Mac

When my kids were little I kept changing the DE on their (Linux) computers so they would not get used to one look and feel. It worked. My older daughter had no problem using Windows at work. This is also why I have learned multiple different languages with different syntax. Not equally good at all of them, but good indented and bracket. I have learned enough Erlang and scheme to follow their very different syntaxes too. Once you get used to it syntax becomes the superficial issue it should be. I use to use PHP and knew some C etc. and once I had spent a few days with Python I realised indented was far better because unfamiliar code was a lot more readable.

To quote from the Fiverr article:

Python’s popularity is fueled by an easy-to-read syntax and its user-friendliness as a web development language.

What I find with Mac users is that they keep telling you some amazing thing they can do with their Macs and it turns out to be stuff I have had on years for Linux (syncing things, copying and pasting between phone and desktop, a decent terminal app....)

I don't buy that python is faster, so I googled it, and it's not, nothing has changed, at least not when these people tested it.

That test is of only regexes. Yes, Python regexes are slow. I agree Python is a bad Perl. The heavy use of regexes is one of the thing that makes Perl a great string processing language, but not so good for anything else. Unless what you are doing is string processing it is just compensating for Perl's limited data types. This explains the problem very well: [regex.info...] "Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems."

That is another reason I learn multiple languages: to learn different ways of doing things.

How does perl do on turning HTML into a tree structure, or multiplying matrices? Even with strings, how well does it do with something like finding where a given substring is in a string without restricting yourself to a substring.

Anything performance critical should be written in a fast language like C, and called from a language like Perl or Python. Python has far more libraries for this than Perl does.

Also, regarding Pypy. it is not an add on. it is a completely separate implementation that is JIT complied to machine code. The trade off is slower startup but faster execution. Numba is an addition which JIT compiles python code in the commonest implementation of Python.

For text processing and report generation, use the tool that is designed to do that.

The problem with that is, that it is only a useful approach if what you are writing is a script that only does text processing. In a larger project you end up with multiple languages each doing what their good at. This mean a project can only be maintained by someone who knows all the languages used. It also means that if you need to provide that processed script from some sources and then pass it on to something else, you end running multiple processes, each written in a different language which is inefficient (especially if you launch the processes each time they are run).

I find Perl user unfriendly, precisely because it is so close to bare metal that it makes you learn how the hardware works to do it well.

I do not understand what you mean by that. What could be further from the bare metal than a regex? Perl is an interpreted language with data structures as abstracted anything else. C is close to the metal, where data types map simply to memory locations and what the CPU supports.

My very very strong suspicion is that ones coding style changes fundamentally to fit in with the most restrictive language one uses in terms of syntax and style

Learning multiple languages improves your code. Learning Haskell greatly improved my Python code.

I don't know re fortran, my dad wrote a lot of it back in the day, millions of lines if I remember right, but I never looked at it. But I think that is right, but it was a super simplistic language, and could not do very much

It has come a long way and has been improved a lot. What it is very, very good at is numerical computing. Often faster than C.

[edited by: graeme_p at 10:49 am (utc) on Nov 9, 2023]

[graeme_p]

Doesn't fortran also go by indentation? I'm pretty sure most dialects of basic (aka Fortran For Dummies) did, and it was a jolt when I first met javascript/php and had to remember all those braces { } and parentheses ( ).

No, it uses keywords like "end" so there are no brackets. the same is true of Basic and Pascal. So there are no parentheses, but indentation does not matter either. [rosettacode.org...]

There is a huge variety of syntax out there. The most natural is the Prolog and Erlang one modelled on sentences, so you end lower level things with commas, and finish something like a function definition with a full stop. If you like parentheses try Lisp! There many different things out there. Forth type languages, APL type languages etc. All entirely different.

[isitreal]

So my rusty memory did not fool me, re FORTRAN, I remembered just a stack of lines of words, very short lines.

Re close to bare metal, this took me a while to actually grasp, since I had learned on higher level languages that hid almost all the stuff the computer is actually doing. This was my number one error in Perl, but as far as I can tell, there's no way around that error unless you started with something like C and were already familiar with that way of looking at things. Kind of the classic chicken/egg problem, you can't get good at Perl without doing a lot of Perl because otherwise all the habits you pull along will make you write what I now think of as 'bad perl', bad in the sense that if you start optimizing, you will have to fix it sooner or later to avoid things like unnecessary copies etc bewteen code areas.

I never really had any interest in being a programmer, so I never really learned a lot of languages, I just learned what I had to learn to do something, and when its limits started getting apparent, I would learn something else that solved the issues better.

The thing however that I like about Perl is that it does no represent itself as something it isn't, it's in the name after all.

Re HTML, I think you're forgetting that Perl was the first real web language, it has tons of modules, CPAN is packed with them, HTML stuff is obviously heavily represented. The main issue CPAN modules have is lack of maintainance due to lack of man-hours, and a I think a poorly designed issue tracker. I know I forked a module I needed and offered the corrected and updated module back to them and never got a response. That module I made sure to offer the same features as the original re input/output etc, even though that was done badly and was kind of dumb. After getting no response, I continued and did the rest of the fixes. This is what hurts Perl however, lack of man hours coupled with a poorly done or non-existent CPAN issue tracker where stuff would not just fall into email oblivian.

Re close to the metal, I'm talking about scripting languages and the way they work. Since I've dealt somewhat too much with the guts of the hardware over the years, as I learned Perl, and got better at it, I started realizing what the difference was, and that was it. It's a sort of intuition more than something I can explain clearly, but it's why modern kids probably will have a lot of difficulty learning a language like that, and gravitates to something that shields them from that more. 'User friendly' is the term that defines this shielding. So python can't have its cake or eat it too, lol. It's one or the other.

I think in a sense you are overthinking that term, Perl was designed when CPU/RAM was at an absolute premium, to work it had to be closer to the metal, by definition, or it would have been slow as molasses.

You are absolutely correct however to point to the main issue of complex perl: you have to run subshells at some point, and subshells are so radically inefficient, for my stuff, the more complicated, they may take up now after many layers of optimizations, maybe 80% of execution time. That forking is EXPENSIVE. But what's astonishing is how extremely fast it is anyway.

This is all a hierarchy, development speed over performance over power. Since I've spent an unhealthy amount of time tracking down bottlenecks using stuff like NYTProf and other Perl optimizers, what always astounds me is that things like regex are astonishingly efficient, because they are a core part of the language, not tacked on. This is the one I am most aware of, but there are others that I don't notice as much, probably because they don't register as time consumers in the data so I don't think of them.

But basically if you need a lot of regex, a language that does not use them natively is going to be slow. The dirtier the data, the more regex you need.

While I'm never going to do it, the only other logical language type for me to learn would be something like C, maybe Go or Rust, but I just never hit a problem that requires that so I can't justify learning those types of things, takes too long, and wouldn't help any of my projects, so I just let it go. I honestly never wanted to learn Perl, I was kind of forced into it by the projects I was doing needing more power.

Part of me has always been curious to test against a compiled language, but the code is so complicated that I'd want to test, and so radically non trivial, and so perfectly solved by Perl, that I simply can't justify the time, it would take over 1 year I believe to actually generate a working equivalent to even one of my more simple projects, since I'd have to learn the language as well, which takes a long time. It would be absolutely comical to then discover that the speed difference was under 2x after all that (which I strongly suspect would be the case because I've seen other tools done in C that do a subset of what mine does that are far slower), so that's an experiment some other me will have to run in another life, well, hopefully that other me will have found better uses for his time, LOL.

I agree learning more languages improves your code, but I think what improves it the most is taking on a problem that is very complicated and requires extensive research. As I noted, I think one reason I don't really get into this type of thinking re learning more languages is that the problems I find to be the real issue are NOT related to the code, they are related to research, learning, data collection, exception finding, bad specs, bad documentation.

i have to be honest and note that I generally scratch my head when it comes to the actual real substance of such discussions, because without fail, without exception, at least 90% of my time for anything is spent on research and data collection, pattern detections, exceptions, etc, and the actual coding is almost nothing, so all I need is that the language is able to do what I need it to do.

As an aside, it's increasingly bummed me out that I find more and more that the ability to do real research is plummeting, I almost never get good research done on issues that are posted on my stuff, and when someone does any at all, I am super happy, until I learn they didn't do enough, and didn't dig in far enough, which is almost always the case.

So what are the problems where this is not the case? I think I have literally never found one, maybe one of the very few coding issues I hit that took actual time to do because it's so difficult was recursive stuff, there the actual code took longer relative to the feature that used it, but I doubt it even hit 5% of the time overall.

Anyway, off I go.

[isitreal]

I think I just answered my own question, I gravitated to problems that use languages to solve them, but where the problem is the actual puzzle to be resolved, which is why I have ended up using a Practical Extraction and Reporting Language, that's the main problem.

Though I do one project that is a more conventional bit of software that actually does something, but Perl works great there too, but maybe what it is is that I am not a programmer, I just use programming to deal with the problems that interest me. This would fit, since that's what my Dad did too, he used programming to do his real stuff, but was not a programmer. Odd given he probably wrote much more code than most programmers ever will in their lives, lol..