Key Perl Core developer quits, says he was bullied for daring to suggest programming language contained 'cruft' On Monday, the Perl Core developer known as Sawyer X announced his intention to leave the three-person Perl Steering Committee, or Council, and the Perl Core group because of what he described as community hostility. Sawyer X, who became "pumpking" – manager of the core Perl 5 language – in 2016 when he took over that role …
If there is an inadequate test suite, or even the suspicion of inadequacy, then changes must be justified by validated bug reports. It is suicidal to make changes when you don't know how many people - or how far away in space and time - you will be negatively affecting.
And a huge open source project that grew organically over a long time is very unlikely to test everything depended on.
Heck, there's a duplicated line of code in a data table in a widely used Python library that I've come across repeatedly over several years. *I'm* sure that removing it won't break anything. How do I convince the maintainers? There are no tests expressly for that area, and it is symptomless present or absent.
I ache to submit a PR. Tough for me, but why be a pain about it?
You're not being a pain... you're helping to improve the code. That's the basis of open source.
You "convince" the maintainers of an issue by showing them code to fix it and the rationale behind it. They have the option of accepting the PR or not.
In my experience most maintainers welcome reasonable and thoughtful PRs. And, in the odd case where they're rejected, the discussion is usually informative for all concerned.
That said, dupicate lines should be picked up by static code analysis. That said, I rarely run that myself as the output is often too verbose…
One man's cruft is another mans livelihood (or Friday evening rewriting code).
One of the powerful things about Perl is that it doesn't change too much. Yes, it has warts but a language that changes and always breaking code is useless.
So I imagine there was a backlash against those who always want to "modernize" everything needlessly.
Obviously I don't believe he should have been bullied however...
Yeah, DIDN'T change much might be more accurate, as 6 & 7 both had issues in back compatibility as the article mentioned.
That said they were generously supporting the earlier releases, so if you don't want up update your scripts to the new version, you could drag your heels for years, and older/slower releases and distros that had perl scripts wouldn't fall down overnight.
Perl was always more dynamic then the fossilized shell scripts like awk and sed, so I am pro-innovation as we have other legacy scripts to work with if your afraid of change.
As to the toxic environment, it really a surprise that Perl coders aren't in their hearts predisposed to being team players? When the languages reputation was that no two people are able to even tell what a given script does, they didn't change the language, they made it a contest. Between that and the subtle and dark arts of implied syntax, it's antisocial coding by design. If I build a birdhouse, I don't wonder why there aren't more dogs in it.
I would suggest that Perl still DOESN'T change. Perl 6 was outright rejected (and forked to become Raku) and 7 is much more similar to Perl 5 than many would like to admit. It is mostly just different defaults in the boiler plate at the top.
I would also argue that Perl is a tool that doesn't need to see innovation. It needs to be concrete and get things done (Like C). If you want to innovate, then Rust or Go are much more receptive places to go.
I am all for innovation and change (otherwise I would not be on a tech forum ;). But there is a place for new and there is a place for consistency (Perl is neither haha).
A big issue I have always found in Open Source is people spend long hours often unpaid on a project because they care. This emotional investment leads to emotional language and strong feelings. I have upset people in the past by writing long posts criticising things in detail in a project I maintain. I was not attempting to bully, I was trying to robustly explain my opinion in enough detail to show I had given the topic due attention before savaging someone else's work. Turned out major changes combine with what was described as "a Manifesto of what I did wrong" was counter productive.
Robust debate is useful to find the best ideas, but facilitated it can feel toxic. I am not sure I want to advocate for specific facilitators. But attending a professionally facilitated event to draft an open standard was eye opening. Heated discussions were very effectively resolved by understanding when people not prepared to agree, but were happy to disagree yet commit to continuing anyway.
Do what they want to do and bugger things up. That’s what I learnt for the past 4-5 years, as I’ve seen bad idea after bad idea take off in the industry. Means more money for me in the future, as people make things progressively worse by “learning from past mistakes” even when they’re clearly wrong!
There’s nothing more refreshing than telling customers “that’s the way things are” and “that’s what the industry decided” as a response to their very valid complaints about the unscrupulous business models and poor quality code many developers have unleashed upon the world.
Anyways, have a nice, cool Sunday beer my friend!
Of course it contains cruft. Have you seen how many date and time modules there are which all do the same thing? And who'd want to change any of those.
Every language which is used a lot gathers cruft, perhaps the leading lights of the Perl community should stop being a bit too precious about it. If they're not connected to reality then it doesn't bode well for their stewardship of the language.
A few times over the years I've had interaction with the devs of open source s/w. I assumed they were volunteers and tried to be as polite, positive and grateful as I can. I was trying to make a positive contribution, to improve the uptake of the s/w among ordinary users.
In each case I was making a case about usability of some aspect of the s/w, based on my work with supporting some very intelligent and proactive users, some at least quite technically aware. In each case my comments were couched quite gently, even tentatively. ("It might be easier for users if.." that sort of thing.)
I'm not a developer, but I am a very technically aware user, and was the technical support for a lot of ordinary users. So my feedback ought to have been useful, and welcome. I tried always to be positive.
In each case the response was, at best unresponsive, at worst quite negative and even abrasive in tone.
I was not insulting their mothers or promoting a heretical view of their religion - but you'd be surprised to hear that if you were to judge by the responses.
In most of the cases my suggestion was (IMAO) perfectly logical and reasonable, based upon my experience actually using the s/w and the comments of others who'd tried it - often at my suggestion.
In most of the cases the responses made little sense - not being about actual use, nor about (which would be understandable) some extra complexity in the coding. But rather along the lines of "We want it this way" or "We don't want to".
In one fairly recent (and trivial) such case, it's impossible to tell if there have been any recent new add-ons for the application, which means users have no way to know that some new functionality has become available. A rather unusual state of affairs. The devs response was that they wouldn't identify these because they "wanted all add-ons treated equally". I tried to point out that leaving a new add-on unknown about wasn't treating it equally. But, well....
The concept of open source is that if you want something done, you're expected to do it yourself. They don't want suggestions, they want you to fork it, make the changes and then they'll consider it. It's not a customer-based system.
Does that suck for everyone who isn't a developer? Heck yes, but the devs don't care because they're not being paid to take requests. It's a fundamentally unfriendly system.
To me, the concept of open source is more about giving what you can for the common good. Fixing it yourself is certainly encouraged, but I don't think it's essential. I don't know the details of the incident above, but if your project has non-developer users and some sort of feedback mechanism then I think you should expect feature or usability requests. Especially if your project has a GUI.
If you're just writing code for yourself you can do what you like, but as soon as someone else uses it or looks at it, they may have suggestions or requests. I don't contribute to any open source projects but I am a professional developer and I have learned a lot from code reviews and user feedback. You have to be able to open your mind a bit and see it from someone else's point of view, which may be difficult for the stereotypical lone coder.
"if your project has non-developer users and some sort of feedback mechanism then I think you should expect feature or usability requests."
You should, and you should take some of them. I do wonder if some of the negativity with which feature requests are received is due to users who ask for the impractical all the time. I'm on a couple of mailing lists for open source projects, some of which have quite a few non-developer users. I've seen plenty of normal feature requests which should get real consideration. Sadly, I've also seen people asking ridiculous things and not stopping when it's explained why that's not feasible.
One person wanted us (well, in that case I was not a core contributor, so them) to add a proprietary component because they preferred it. We pointed out that A) the software was GPL and the component wasn't, B) the component wasn't free, so in addition to changing the license we'd have to buy licenses for it, C) the software we produced was free to users so we'd just be losing our own money trying to do it, and D) nobody but this guy seemed to think this component was any good anyway. This was not the end of the bombardment with emails asking why we weren't going to do it. For another example, there was one person who wanted the project's resources translated into Slovenian. That's fine; the work had already been done to make things localizable and there are existing translations. No, that's not what the user wanted. They wanted us to find Slovenian translators and have them translate the resources even though none of us spoke it. I volunteered to simplify the process of creating the localization files so they could produce a translation. This was not the right move. This particular episode included some angry missives from the requester.
I wonder if the treatment afforded proper feature requests is due to things like this. If I as a developer think people will ignore me when I state reasons why I can't or won't implement something, I might be more likely just to ignore most people and only pick those feature requests which struck me as the most interesting. That doesn't make that the right approach, but it might go some way to explaining it.
The developers could be doing that, but they could also have a point. UI is very subjective. There are lots of UI changes that some people think are better. Others will hate them vociferously. Also, changing the UI is a guarantee of annoying most people. So it does to some extent depend on what change was suggested and how many people were familiar with the previous one. After all, if you maintained an office program and someone suggested you throw out all your menus for an ribbon of buttons which always seem to move when you're not looking, would you do so immediately?
In my experience, I try to minimize UI changes after the first non-beta release. Suggestions for redesigns only get through if the change is small (and I think it makes sense) or they've written a long, detailed description of why this improves the system and how users can be made familiar with the change. Improving the UI because "I know more about usability than you do and this approach is superior to yours" won't happen; both of those points may be true, but that's not enough for me to start from scratch with no support. Fortunately, I rarely have to deal with this because I don't like working on UI stuff and try to either stay to the backend or keep it simple.
I take that point. UI is very subjective. But usability may not be. And from that POV it's not uncommon for FOSS to have idiosyncratic layout etc. Sometimes with a very steep learning curve for no apparent reason. I never try to influence that. I might not try too hard to use it, but I don't try to change it.
My rule of thumb there is if it's a Windows programme that doesn't behave like other Windows programmes it has to be for a very good reason or worth the effort to learn. A key is it should be either familiar or intuitive. If I click on a button that seems to be needed to do something and something unexpected happens instead I'm going to be very cautious about it. Or if it has some strange default setting (like saving in an unexpected location) that also requires a complex procedure to get back to how I need it. I have one freeware (with paid pro version) graphics type programme, for example, that does a very simple job very well, but has numerous layout settings that don't readily translate to how it will appear on the page. But it does do that one job well, so I've worked out how to get a good approximation of what I need. I don't use it often. I sometimes use it, I don't recommend it to anyone else.
Usually though it's some simple thing, like a horizontal scroll bar that won't allow you scroll past a certain point until after you've tried to drag content into an inadequate space at the end of a row.
UI is not subjective. It is contentious.
It is possible to quantify how well a UI performs:
How fast can a user perform the key tasks?
How long does it take a new user to figure out and perform the key tasks?
How many mistakes or wrong turns does a new user take when performing a key task for the first time?
They can also be surveyed subjectively on how frustrated they got, and how well this preformed compared to other software they have used.
A bad UI will score low all of the above. 0% subjective.
What usually happens is that nobody bothers to do the above because of cost, time, don't know how, don't value it. In the absence of data, UIs are subjective, everyone has an opinion, and most people's guesses of UI quality are way off-base.
The exception is that experienced designers accurately predict software usability. However I have seen people argue with them until the above tests provide the concrete evidence, and even after the tests are done that they were 'rigged' LOL. It's a wasted opportunity to get an experienced designer in and then argue with them and accuse them of falsifying data.
Best case scenario is: Experienced designer. No expensive testing. Key design recommendations. Implement all except the most costly. Better product from the user perspective.
I agree with Terry's point on this topic.
That's fine, but not really complete. There are lots of subjective elements. What should the assumed environment be? Does the user use a single laptop screen or two large desktop screens? If there is a possibility of a mobile user, two interfaces or one interface? Should the desktop interface look like the mobile interface with additions so users who use both are familiar with it or should they be made to look like the interfaces of the devices they're running on so that actions are fast on each one? What are the key actions to be taken? Should the action be made fast or have lots of options? Should there be two choices for the same action just so one is fast? What about aesthetics?
As I've stated, I am not an expert on this and I don't want to be one. Still, there is a lot of subjective stuff when designing UIs. I subjectively think the Office ribbon is bad. I know a lot of others who also think the Office ribbon is bad. Microsoft stated at the time that it was better for feature discoverability. I'm sure they've done some tests on it. I've also heard people who don't think it's a problem. Similarly, I've seen such discussions about the window systems on Windows, Mac OS, and various desktop environments for Linux/BSD. Each group has some statistic they'll bring out for why their desktop is better. Each looks nice and numbery, and probably has some validity to it. Yet there is no agreement about which is best. Because it's subjective. That doesn't stop a bad interface from being bad for pretty much everybody, but it does eliminate the ability to find the epitome of excellence in UI design.
Ego. It does that to you. Or, to be more specific, to the developers who think they are something (special). Been there, done that, and also the other side. Tiring, and fact of life. Afraid this does only change with the age of the person in question, but not generally.
I know well what you went through.
User experience design is time-consuming expensive and there is a shortage of people who can do it well. It can make a piece of software superior to it's competitors just because it is easier to use, without having more features.
There is also a cost to implementation of the design changes, but it's rarely high.
The problem is the psychology. The developers think that they are smarter than the average user, and know more about the software because they built it. So they take the view that they can anticipate what users want better than you or I or a designer can.
This is a fallacy, because everyone knows less about the software than they do, so they can make things too complicated or hard to figure out or time-consuming to use, and are not capable of noticing (unless it is also too complicated for themselves). This psychology explains the arrogance of "who are designers to tell me how to build a better software product".
Luckily I am usually in the position of managing the developers, so I insist that they implement the designs. Once this is grudgingly completed, they are happy to share in the credit and accolades for the success of the product.
Letting the developers do it their way, and learn the hard way is too slow and expensive, and there is the principle of paying them to redo something that they refused to do in the first place.
The impression I've had, from reading devs' comments and descriptions etc. and from one or two conversations, is that the devs want often want to produce a programme that's better than those around ( Or that's missing). But better is a YMMV sort of thing. Better to a software developer often seems to mean; faster, more efficient, more functions and so on. It seldom means; more intuitive, easier to remember, more obvious what to do next.
By the way
I hate the Ribbon. Not because of its intrinsic design ( I hate that too, to be fair) but because they made creating user menus that worked for a specific user/team much harder to do. I used to customise WORD to make finding the stuff they needed easier to find and move between for teams I managed so that items would be in the menus with items they'd use at the same time for the same job. And stuff in those menus that they'd never use in their job would be banished so that hey didn't have to waste time hunting for stuff.. i.e. a custom "edit" menu that contained what they needed to develop the particular observational reports we wrote all the time, so that they could amend the template accordingly.
In most of the cases the responses made little sense - not being about actual use, nor about (which would be understandable) some extra complexity in the coding. But rather along the lines of "We want it this way" or "We don't want to".
Without in any way commenting upon your approach or suggestions, because all developers love good users, I'd just like to note that there is also a culture of entitlement in some users who expect this feature or that API. And pronto. Yesterday would be better.
It depends a lot on the project but personally I won't accept anything other than a PR. With tests and documentation because the overhead is simply too great otherwise.
There have been at least a few longitudinal studies of interactions among contributors to large open-source projects, typically by doing things like discourse analysis of public mailing lists. (There have also been some studies of such interactions in large proprietary-software projects, but those often have the luxury of direct access to developers, so they can use additional methods such as ethnography.)
The politics of those groups are complicated and tend to lean very heavily on in-group recognition and reputation. In-group-ness is often signaled by references to shibboleths which are not apparent to outsiders – usually the result of historical feuds or the whims of project heroes.
Developers and project maintainers are indeed human and have the ability and the right to be upset. And some FOSS communities can certainly be toxic - just look at the WordPress plugins repository reviews and support sections.
When I was harassed in that particular forum I decided (much like Sawyer X) to remove my plugins and exit, deleting my account on the way out.
And that is definitely the right thing to do if that's how you feel about things.
Communication based on respect is a lost art, having been replaced by instant outrage by the Internet. People no longer think about what they type, they take it personally and just want to retaliate. And people who are capable of taking an argument at face value are very rare indeed.
The end result will obviously be communities who dwindle in size and either never say anything or never stop complaining and insulting each other.
Not anything I would want to be a part of, for sure.
"Communication based on respect is a lost art"
I think it's always been a little dodgy on the Internet, tbh. I recall highly contentious flamewars on Usenet back in the day. Possibly there is a difference between greybeards who perceive that style of communication as being natural and normal and a younger generation who don't. Even on this comment board, you can see a schism between people who think that civil communication is valuable and the people who think those people are a bunch of fucking pussy snowflakes.
I recall highly contentious flamewars on Usenet back in the day
Definitely. This was true even pre-Usenet, in the era when listservs stalked the plains of BITNET and the IBM HONE network was larger than the Internet.
It's endemic to the nature of online written communication, which has nearly the immediacy of speech (because it's so easy to dash off a reply, compared to hand-writing a message; and even with email, delivery is much faster than the post or any other print transport), but lacks the additional channels of gesture, facial expression, prosody, etc. And it has the authority and durability of print.
'94 was also the year of the Flame Wars special issue of SCR, edited by Mark Dery, and if memory serves at least a couple of the pieces in that collection touch on the phenomenon too. I imagine Dery himself, a longtime observer of online discourse, could have discussed the question at length even some years before that.
It's not a matter of having "forgotten" how to discuss with respect. It's a frame that's strongly conditioned by the medium. We've known for decades in Composition Studies that media have a powerful influence on rhetoric and discursive pragmatics; methodologically-sound studies drawing on large corpora have shown that consistently. Similarly for work in sociolinguistics and probably in other fields. You can see that as confirming the theories of the Frankfurt School, or Marshall McLuhan, or Hayden White, etc, if you wish. (Personally I like the Frankfurt, find McLuhan rather lacking in rigor, and think White's Content of the Form is interesting but not particularly surprising.)
I touched on this topic in an article I published in Works and Days in 1994, and it was widely recognized then by people using online forums of various sorts.
The main issue with Perl is that it's at least 80% cruft by this point. But it's moved into more of a legacy role these days so it doesn't really matter. Because if they get rid of any cruft, they'll begin losing developer base because they're all just maintaining the same old systems that rely on that cruft.
It’s not that Perl programmers are idiots, it’s that the language rewards idiotic behavior in a way that no other language or tool has ever done - Erik Naggum, comp.lang.lisp about 30 years ago.
This is normal, we've seen these arguments and comments for years, I can remember thinking that FORTRAN sucked ... because I was happier writing 8080 assembler but when I started to work with people writing FORTRAN instead of being taught it, I changed my view but wrote everything in Pascal and Modula-2 - but these days people say they are all old and retired ... yes let's rewrite everything in Java ... no that's too old, lets move to Rust this week. And in a few years we'll hear all these comments about all the languages we use today.
The "Best Language" is just the one you are good at.
I've come to see the language as largely irrelevant. Python, C, Ruby, Java, Perl -- in the end the syntax hardly matters.
What's so much more important is the set of libraries that is available. Need to talk to a REST API? Interface with an SQLite database? What you need is the right library for the job, and then you suffer the language that it is written in.
All right, this is a bit of an oversimplification. Still, there's a grain of truth in there.
Version 1.0 Said>> The "Best Language" is just the one you are good at.
Not sure I necessarily agree. I don't have any special skill in Haskell, but I still feel it is the best language ever invented primarily because of its purity. It's also a lot easier for people to learn than they think. It's just a bit "odd" for people that are used to imperative programming. Of course, some of the skilled developers in the Haskell community tend to be a bit "rude" an that doesn't help language adoption...
There's certainly something to be said for familiarity. I still write a fair number of ad hoc analysis scripts in awk (or gawk, really). I wouldn't argue awk is good in any objective sense – though when its three famous authors created it, it was a terrific tool that didn't have any rivals, at least on UNIX. But I know it, and the scripts I'm writing don't need to be maintained (they're one-offs, even if I put them in source control just like everything else), so it's useful for me.
I do not like Perl, but I respect it, because the things I don't like about it are mostly explicit design decisions by Larry Wall, and I respect Larry and his rationale. Contrast that with PHP, which seems to be awful mostly because there's no design at all.
By the same token, I don't actually like traditional COBOL – I don't really care to write or maintain code in it – but I respect it because it was designed, and designed according to the principles that were understood at the time. And it's evolved; the 1985 standard helped a lot, and the 2002 standard helped somewhat more, and the major implementations offer extensions and relaxations which help more. (And managed COBOL is a modern OO language with access to major frameworks. Aside from a few historical infelicities, managed COBOL is quite nice.)
" cannibalization from PHP and Python, incompatibility between Perl 5 and Perl 6" certainly sounds suggestive of cruft(s) to me.
However it's well known that partisanship for specific languages is very strong - I'm waiting to hear about the first GBH attack (did I miss something?)
"TIOBE Index July 2019: Perl hits its lowest popularity"
Of that ~1% standing, what is the balance between PERL5 and PERL6?
A pack of polar bears on a shrinking iceberg means some unhappy quarrelsome polar bears. I don't think it is as much about the personalities as the stress inducing circumstances - from a macro perspective.
Flaming people is as old as the Internet. Its just that as the community got larger the margins went from ALL CAPITALS TO MAKE THEIR VOICES HEARD through abusive language to death threats (and for all I know, actual physical attacks). Its just a problem with people thinking they can (literally) get away with murder -- there's no consequences so expect Lord of the Flies rules to apply.
I quite like Perl. There's types of tasks that its really good at, for me these being shuffling files around directories for production code builds that can't simply be handled by a complex makefile. I'm not an enthusiast, though, and I can't claim to be an expert. Its just a tool. I'm not a great fan of terse programming -- others need to read that code -- but some shortcuts make sense. The bit that fools most people in my experience isn't the language and its shortcuts but regular expressions. This isn't a problem for a language, it is its own language and it appears in numerous programming environments (I suspect the same module gets used -- its one of those 'orginal author got retired to a sanatarium and nobody's yet been able to figure out how his code works' jobs). There may be other obscure compoents that I'm unaware of (and, of course, everything has to be expressed in objects these days whether they're actual objects or not) but I'm not aware of them.
Honestly, I've used PERL and prefer it over Python. I've actually gotten a few emails back from what appeared to be Larry Wall's email address. I suppose Python is "reasonable", but I wish Guido had picked a better name for his language. I also wish people would stop calling GNU\Linux background drivers daemons. That REALLY bothers me. Please stop it. In terms of the ultimate "scripting" language, I actually prefer Haskell but I thing PERL is cool. Not sure we should attack the language PERL because I liked it just fine. It's just that I like Haskell more than any language ever invented. If only my bosses and coworkers could understand that... Maybe the new language Nim will be okay, but I doubt it will be better than Haskell.
"I also wish people would stop calling GNU\Linux background drivers daemons. That REALLY bothers me. Please stop it."
Why? Daemon is a term that's been used to describe exactly that sort of thing for a while. In fact, not only do I have no problem with daemon, I wouldn't like to call them "background drivers". I view drivers as controlling something else, especially hardware, for a separate process or the OS as a whole. Lots of daemons or whatever they are don't do that. So I'm going to prefer daemon for that type of program unless you have an argument for it.
Also, what's wrong with Python as a name for a language? Language names are pretty much all arbitrary words or letters. You don't seem to have a problem with Perl as the name of a language, and that's not even spelled right (it was going to be named Pearl, but there already was something called that, so they just chopped out the A and went with it). Why is Perl fine and Python not?
Verily, the day will come when the final 'one true language' will appear and it will be good and it will be called "new machine code" for it shall be so that only evolved machines can write it and only evolved machines can understand it and only evolved machines can run it and it will be a hundred times faster to execute than all other crude interpreted and compiled languages and take up a hundred times less storage space than all other languages and all other languages will look like Basic running on a ZX81 in comparison and the meatbags will be finally redundant and will be swept from the face of the earth..
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
