There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.
Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.
Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.
Agreed! My father (RIP) absolutely loved Perl and could do amazing things with it in seemingly impossibly-few characters. I got reasonably proficient w/ regex but never came close to his wizardry. Much respect for those in his rarified company.
Pure perl modules are not, unless they use syntactic features that first appear in the newer versions.
Modules with C extensions have to be recompiled with libperl they run against, as much as CPython extensions link to a particular libpython, and guess Ruby is the same. But they, with very few exceptions, will recompile and run fine. XS is cryptic but its backwards compatibility story is good.
There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
There was strong cultural pressure to be able to write perl in as few bytes as possible, ideally as a CLI one-liner. Books[1] were written on the topic.
> There was strong cultural pressure to be able to write perl in as few bytes as possible
Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.
One-liners is one of the ways you can use perl. You can also use it as the embedded language in some larger project. As perl CGI. As mod_perl. etc. There is no "cultural pressure" to use any of these. You can choose to mess around with one-liners and you can choose to spend time shaving a few characters off your code. Or not. None of this is the one true way. This is not python.
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).
After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.
You apparently saw viciousness in this and that certainly sucks.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
You indeed ran into toxic environments. I don't feel that the common, new perl programmer intake path was anything like that. Not what I ever ran into.
Support in forums and such was needlessly short in using RTFM as an answer. People could have pasted a one paragraph pointer to the documentation intake path and that would have helped.
It was primarily the exhaustion of experts at tireless waves of newbies who hadn’t studied the available materials.
IRC being async if the client is run locally, modem delays made no difference (just as with QWKmail and forum posts). And for remote host IRC, I don’t remember what the IRC line length limit was but at 300bps you could get an entire message and the buffer scroll updates accompanying it in 1 second, which was well-sufficient enough to support peak volume with no relevant latency. And, I can still type a paragraph at clock seconds of input latency and remember where I’m at when backspacing. So, I would definitely not ascribe a desire for brevity as an outcome of modems.
The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.
It's actually pretty amazing that you extracted the very worst, most very destructive practices and ideologies of agile and put it into a package that would allow toxic managements to maximally hurt their developers.
I was actually thinking this is all from the developer point of view (or at the very least mine: a developer). I try to deliver some value every working day, and I have to say I pretty much love it. This principle really pushes me to make sure I understand the problems and engineer solutions to them appropriately. And from feedback I get, I am, apparently, very productive doing this. And I do encourage others to work this way (as I was myself encouraged), but I do emphasise the point made repeatedly in the manifesto: the increments can _really_ be extremely small. And to also emphasise another point in the manifesto here - it's not a concern if the aim isn't fulfilled every day. If most developers currently aim for value every 2 weeks say, and that's what they're used to, then of course every day won't always happen, certainly in the beginning of working this way. Or yes, there may be unexpected things along the way. And this is all completely fine.
(This last point was a late addition to the manifesto: but I _think_ made before your comment)
Can you give a bit more detail on the destructive aspects though? If you mean if an organisation follows this, then it ends up as a stick to beat developers with if they don't deliver value every day? I guess my counter to that is, if management is toxic, they will always find a stick to beat developers with, no matter what.
What the manifesto does, or at least tries to do, is encourage developers to think about how larger pieces of work are tackled - so they end up really understanding what the problems are, and so engineer solutions to them appropriately. Wherever possible getting feedback, and if possible on a cadence of at least daily, to me seems such a good way of doing this - but do you have a better suggestion?
Edit: I see https://github.com/rayfrankenstein/AITOW and have started to give it a read… and… wow. I certainly understand where you’re coming from, and I would hate to see “Deliver value daily” make all these situations worse.
I think I’ve been really lucky - only maybe experienced light versions of the worlds described, and in the past few years have worked in a very supportive environment and had a lot of autonomy. In this environment I/my team decide on a lot, including ways of working like how to tackle bigger pieces of work. And in such an environment, “Deliver value daily” I think can really work, and essentially has.
But I think I am sticking with my point - I suspect toxic management will find any excuse, and the three words “Deliver value daily”, will do little to change that.
Although - I am tempted to make it clearer up front that autonomy and a supportive environment (and maybe other things?) are crucial, to try to at least limit how it could be “misused”
Although a follow up… could “Deliver value daily” actually help push _away_ from toxic behaviours like micromanagement?
As long as there is some sort of visible/tangible progress most days, and in a justifiable direction, there could be less of a desire for tight control for example?
I've now added a section to https://delivervaluedaily.dev/ that is at least a starting point of trying to make sure it doesn't make bad environments worse.
This has been helpful - thank you.
@RayFrankenstein if you would like a small acknowledgement at the bottom of https://delivervaluedaily.dev/, let me know
Here's what I've learned from maintaing this compendium about why Lean manufacturing doesn't translate.
1. Japanese car companies companies were focused on long-term growth. Software companies, on the other hand, are extremely short-termist.
2. In Japanese car companies, anyone can stop the assembly line by yanking a cord and there is no dishonor in that. Try stopping working on a feature for half a day to refactor some code.
3. In Japanese manufacturing's golden age, workers had lifetime employment and there was a mutual concern by the company and workers for each other; a Japanese worker might be at a company for thirty years. In the software industry, the average tenure of a software company employee is, like, two years or something. And the environment is often very adversarial. You can't ahve
4. Japanese manufacturing focused very heavily on having very high quality vendors that make stuff that didn't require a lot of debugging. There was a heavy focus on part re-use in other designs; the same engines would be used in different generations of different models for years. The software equivalent of this would having a fully fleshed out, batteries included stack where little custom-invention would be required because the API's are just so damned good and comprehensive. How many times have you gotten a Not Invented Here or "that's too opinionated for my taste" approach from leads?
I worked on a mobile app dev team that tried to Ui logic with the backend. With many of the justifications you mentioned being justifications for doing it that way. White labelling, A/B testing, avoiding redeploying, etc.
The result was a mess, with many of the possible concerns and drawbacks you’ve cited ending up manifesting themselves. It was an unmaintainable mess that tried to re-invent the web browser wheel badly, except using json instead of HTML. Maintaining the abstraction framework became a full-time job for people already just trying to barely deliver features on time.
And with the backend people already being busy and tied up with other stuff, the mobile app developers ended up having to become impromptu full stack developers, have to code PHP on backend to complete features in addition to the code they had to write in Objective-C/Java for their native app level portion of the feature.
The backend approach was so resented and hated by the mobile app devs that the business eventually got rid of it.
There are no agile trainings, only agile indoctrinations. Not that you can't have a bit of fun with them (at your own risk).
1. Ask if they've worked as a professional software developer? If not, enjoy them squirming as you subtle question why they're trying to train in things they don't understand.
2. If they do the penny flipping excerise, when it's your turn sweep all the pennys into a book, close the book, and flip it over and sweep the coins back out. You'll do the exercise 10 times faster than your coworkers and show them innovation is more important than agile.
3. When the agile training talks about splitting work down into small bits, as them what happens if there's a large chunk of work that can't be split down and has to be done in a large serial chunk. Think of as many examples as you can of this in the real world, and generally be a skeptical jerk when they tell you that any task can be broken down into tiny bits. If they're not technical, make sure you pick the most technical examples as possible, to further erode their credibility.
4. Bring a tub of single cell legos with you, and if they do the Lego excerise, ask them what to do if your team is given a tub of these and the other team (or your competition) is allowed to have broad-stretching legos.
Ideally you should use types, but if you have to use any because of some complicated situation where the compiler’s bitching, it’s no big deal. Anyone who tells you otherwise is a shamey OCD a-hole.
