Every single annoyance you can find with Python seems thoroughly addressed. Try it and see. Let someone know if there's still major pain points and the #perl6 community would love to hear it.
I wouldn't consider that a good thing. No language is perfect, so if you have no annoyances with a language, you either don't know the language well enough, aren't doing anything interesting enough to run into the annoyances, or lack enough experience in other languages to know what could be better.
Admins were a bandaid for the period where insufficiently advanced software existed. The generally obstructionist principles of the profession combined with the complete lack of discipline in constructing those aforementioned Perl scripts spells doom that we (as an industry) are busily automating out of existence.
Basically, fun was had, but fun was not what anyone needed.
>The generally obstructionist principles of the profession combined with the complete lack of discipline in constructing those aforementioned Perl scripts spells doom that we (as an industry) are busily automating out of existence.
This is probably the most arrogant statement I've heard on Hacker News as somebody who has worn both the software engineer and sysadmin hat.
"Obstructionism" is what engineers, decoupled as they are from the realities of the hardware by their VMs and containers call "due diligence". As a sysadmin, I need to be assured and ensure what you want from the software ecosystem around the ball of lint you pushed onto me will not affect other line of business applications that make the company money. That is what I am hired to do, along with fixing the whole mess when it breaks. So a little due diligence and research is necessary to make sure that everything still runs.
The reason that many of the Perl scripts a sysadmin writes show "complete lack of discipline" is also a testament to the "ooh, shiny!" mentality of many engineers. We already have a database system for reporting, so why are you scribbling out report files? We have an automated system for dealing with system restarts and service restarts, so why are you doing it in the non-standard way? Remember, by the time I see your code it's too late - it's already written and has been approved by management, and rewriting it or changing it is too expensive at this point so I have to work around your complete lack of regard for the standards that keep things running.
Just something to keep in mind next time you complain about "obstruction" and "inconsistency". I only put into place what you make, so perhaps you should spend some time looking in the mirror.
I assume the parent is flame-bait... but figured I'd bite.
Your comment is akin to saying "now that we have biologist/geneticist/etc, we no longer need doctors". Admins/Systems engineers are closer to a "true" engineer, than a developer. Developers are closer to a researcher/scientist in some respect.
Most developers ( specially app developers ), have a VERY limited scope/domain of skillsets. Your average web front end developer is great at taking business requirements and making that into a web app, but has usually zero clue of anything beyond that.
"admins" or systems engineers, should be ( and I'd admit, in many places they aren't), just like Systems engineers in any other engineering field. People who hold interdisciplinary skills ( networking and systems knowledge, specific systems knowledge, programming skills, etc ), and are able to manage complex system through their life cycle. They deal with requirements, logistics, coordination, etc, as it applies to the engineering system.
This need will always be there. If anything, more complex software gets rid of the need for different level of app developers. As frameworks become "cookie cutter", business requirements to application may be able to be fully automated. And developers may, in a not so distant future, just be responsible for building such frameworks.
Put it this way, "admins" were thought of by Charles Babbage. There will always be need for them.
note: some companies have just delegated admin and system engineering duties to app developers. That's just an HR system, not a cure as you make it.
Note that the same argument could be applied to developers. We can rewrite your statement as:
Developers were a nadaid for the period where insufficiently advanced software existed. The generally obstructionist principles of the profession combined with the complete lack of discipline in constructing those aforementioned sites and programs spells doom that we (as an industry) are busily automating out of existence.
Whatever your arguments are against that reasoning, it would be interesting to see if they also applied to system administrators.
I don't think so. Companies don't employ sysadmins because they need them to do anything particularly novel that the software engineers couldn't do themselves, they hire them for the liability they provide, and the capability to poke into the running system and figure out what's going on.
I don't see unikernels or docker or whatever sufficiently advanced software you're referring to replacing that.
I think a lot of sysadmins have made their living by writing perl for the majority of their career.
Certainly there are more people writing perl today than lisp, golang, rust, or haskell.