I use ETL::Yertl a lot. Despite its present unpolished state, it contains some important, easy-to-use tools that I need to get my work done. For example, this week I got an e-mail from Slaven (a CPAN tester and a tireless reporter of CPAN issues found by testing) saying that some records were missing from one the APIs on CPAN Testers: The fast-matrix had 3300 records for the "forks" distribution version 0.36, but the matrix had only 300 records. The utilities in ETL::Yertl made it easy to find and manipulate the data I needed to diagnose this problem.
List of things unpopular with programmers that I enjoy and have produced valuable solutions with:— Presistance (@preaction) November 30, 2017
Give it a month and I'll have another one for the list... Popularity contests are for small-minded people.
This tweet got a lot of likes and replies, so I should expand on it a bit. Most of the replies were additions to the list: Visual Basic (tool for automating and scripting Windows), Microsoft Access (great for small databases), PHP (which unseated Perl as the powerhouse of the web). But some of the replies were the things I deal with a lot: Explanations why my choices suck and I should choose other things.
I'm mature, experienced, and confident enough so that now those comments don't bother me, but it's a problem for novices in the tech community. Learning is difficult and frustrating, and hearing that the effort taken to learn a technology is worthless because that technology is "bad" is demoralizing and can lead to people leaving tech altogether.
So, let me help you cut off some of these discussions:
X is Dead
- X is obsolete
- X is outdated
- X is dying
- X is dead
No, it isn't. Technologies don't die easily, and I can assure you that once a technology has left the technology journalism circuit it will continue still for quite some time.
- FORTRAN, one of the oldest computer languages, still has new projects being written in it, and indeed had a new specification come out in 2008 which adds concurrency and a new spec being planned for 2018.
- New games are being written for the NES, Commodore 64, and Atari 2600.
- Flash is still ubiquitous, despite being declared dead in 2007.
- Operating systems abandoned by their parent companies (or whose parent companies are dead) still have devoted communities, and even active development (BeOS is now Haiku, Solaris has Illumos, and even Windows XP has ReactOS).
What they might mean is "X is no longer a way to be successful", which is also mostly false depending on how you measure success: If you want to make VC money, that is probably true. If you want to learn about technology or solve problems using technology, it is entirely false. If you want to make a career in technology, it's certainly false: Even old technology needs support, maintenance, and development.
What they might also mean is "X is no longer the only technology that can solve its specific problem", and that's a good thing. Technology evolves when it is exposed to new ideas, and there's no better way to get exposed to new ideas than to compete with other technology. This is why FORTRAN has a new spec coming out, as well as languages like Ada and COBOL.
"X is dead" is anti-marketing. Don't be taken in.
X is Bad
- X is ugly
- X is unmaintainable
- X is terrible
- X considered harmful
- X is bad
Technology is invented at a specific time for a specific purpose. There aren't many technologies that gain widespread acceptance while being unsuitable for their purposes. So, how can that surviving technology be entirely bad?
What they almost always mean is "X is bad to use now", and that's also often false: While there may be more and better solutions to the particular problem (which, as explained above, is a good thing), a surviving technology often still has niches where it fits better than any other. This does mean that you need to do your research: Look at the problem domain, find the solutions, and if you have time, try them out to see which one you like better. Don't let "X is bad" stop you from trying X out to see if it solves your problem.
What they may also mean is "X teaches bad things", which is vehemently false: Learning about the history of a technology is important. Learning about historical problems and solutions is important. Technology is built for a reason. Learning those reasons will explain the design decisions made. Learning about design decisions and tradeoffs can teach you how to proceed when nothing is a good option. No technology is built to be deliberately terrible (though some technologies are certainly satirical or farcical, they are excellent satire/farce and should be evaluated as such, like INTERCAL).
I have, in fact, learned the most from learning other languages designs. Java taught me a lot about OO, which I brought in to all my programs. Using pthreads in C++ taught me a lot about process safety and message-passing, which I then started using Zeromq to solve for me (when I can, but I still know how to solve that problem without if needed). The more shell scripting I learn, the less work I end up having to do (fact). Shell taught me fantastic lessons about composability of programs that I never thought possible, and I’ve got some projects that take full advantage of that.
"X is bad" is almost always a disingenuous attempt to get you to use their favorite technology. Don't be fooled!
Technology is not a popularity contest. Technology is not good because it's popular, and it's not bad because it is unpopular. Technology is not good because its unique, and it's not bad because it exists in a crowded maze of solutions, all alike. We need to evaluate technology objectively and critically, whether popular or unpopular. And we must always remember to be kind to people using technology.
Two weeks ago, I was invited to meta::hack v2, the second annual MetaCPAN hackathon. As the primary maintainer of CPAN Testers, I went to continue improving the integration of CPAN Testers data with MetaCPAN and generally improve the performance of CPAN Testers to the benefit of the entire Perl ecosystem.
Would you like to help CPAN Testers during meta::hack v2? Join us on IRC in #cpantesters-discuss on irc.perl.org, join our mailing list on lists.perl.org, or e-mail me directly at firstname.lastname@example.org.
With meta::hack v2 only two weeks away, I’ve written down my todo list for the hackathon. With another brand-new machine graciously provided by ByteMark, who have been hosting CPAN Testers for years, this year’s hackathon will involve more devops tasks to improve reliability and stability of the various parts of the project.
The new server will be the host for CPAN Testers backend processes, the processes that turn the raw incoming data into the various reports used by the websites and downstream systems. It will also be the new home for the CPAN and BackPAN mirrors that CPAN Testers uses for data, and provides to external users as part of CPAN’s mirrors list.
I said "I believe men can be better" last week regarding a job ad I was reading, and I've been thinking that this is a thing I've rarely heard from anyone. I hear, all the time, aphorisms disparaging men and removing all agency and blame for bad behavior:
- "Boys will be boys"
- "That's just how guys are"
- "You should have known that would happen -- he's a guy"
Growing up, I expected to be a terrible person. I expected to be uncontrollable. I expected to want to hurt people. And I didn't want to be that person. When I didn't become that person, I still knew that was what people expected of me.
So, through the power of stereotype threat, a shy, sensitive boy turns into a sullen, introverted man who struggles with depression. Because nobody ever told him that men could be better.
And, through the magic of stereotype excuses, sexual predators occupy our highest offices and control our most powerful institutions. Because nobody ever told them that men had to be better.