Craigslist used to donate over $100,000 every single year. Not sure when that stopped. That is really what kept perl going between the years of 2010 and 2016 or so. The board was actually paying a couple of people to do maintenance on the core repository and code. I believe they still do that but obviously due to deficits that is going to get difficult.
It's sad when so many companies are dependent upon perl, but donate nothing. A good case in point is AT&t in the 1980s was broken up into 20 plus different companies. They were then remerged back in the 1990s. But when they merged, they had 20 different computer systems and perl was actually used to glue all those systems together and handle data sanitation and ETL pipelines. Yet AT&t never donated anything to perl.
I still use craigslist and haven't actually done anything with facebook marketplace yet. That makes me want to delete my facebook account (something I've been considering anyway) just to nip that possibility in the bud.
If you’re trying to sell something, you need to be where the customers are. If they’re on Marketplace, that’s where you go. You can easily list in both places.
Marketplace is literally the only reason I still have a facebook account. Unfortunately the alternatives here get nowhere near the same number of buyers.
I think a good chunk of people would be worried to buy/sell from/to an account with little to no activity at all. This is very strong signal of low effort spam already common on FB Marketplace.
Gifts don’t require repayment. Releasing free software is a gift to the world. Corporations don’t owe free software maintainers a cent, because people using your software doesn’t cost you anything.
100%. This new trend of maintaining or starting an open source project and then getting upset when people don't send you money is seriously weird. If you want compensation, start a company, otherwise consider anything you receive a gift.
Yeah, though I have sympathies for single devs or projects like perl that are obviously non profit. Like, I get the frustrations for actual volunteers and people who survive on building OSS at a small scale.
What really annoys me is when someone decides to build a corporation around an open source project, and then you get the usual blog post around users not paying or OSS not being sustainable. Yes, using OSS as your marketing and adoption strategy is probably not very reliable and can cause users to use your OSS as if it was OSS, that is, without giving anything back. But usually those projects succeed because they are OSS, and would've had basically no users otherwise. Who would've used MongoDB, elastic search, or redis if they were proprietary and required a paid license from the get go?
In a way, that's also true in this case (success came from being OSS) but again, I get why it seems unfair for some when it's a non profit not being able to sustain itself or get contributions for corporate users.
The problem is, if their software had cost what it needed to from the start then that would've put it in a totally different competition with other companies. Bypassing that competition doesn't mean they can suddenly start complaining about how many customers they have vs how much they get.
Yeah I completely agree and that's exactly why the most annoying part of the OSS sustainability conversation. Most of the big OSS players (not individual devs, I'm referring more to the open core type of corporations) would just not exist at all, much less make more money, without OSS. No matter how much money elastic search lost to Amazon for example, they would've made basically nothing without OSS.
GPL or Affero GPL plus proprietary license. Of course this puts off outside contributors so not if you want a "bazaar" development mode—but people complaining about this are usually not doing so.
First off, the AGPL license is nonfree (and also nonsensical, it is a EULA pretending to be a license), but more importantly, dual licensing means that you don’t actually believe in software freedoms. If you think users have basic and fundamental rights to the software that they run on their computer, you would never release software under proprietary licenses.
It’s like Microsoft’s VS Code nonsense where all the important bits are non free, or any company with “open core”. They don’t care about software freedoms; it’s just open source cosplay.
> dual licensing means that you don’t actually believe in software freedoms
If both licenses are accepted by essentially everyone as inherently fully free software licenses, and they don't contradict each other, then what's not to like?
Consider the appropriate example here, which isn't anything to do with AGPL (which many people do NOT accept as a free software license), but rather the AL2 / GPL pairing which was the evolution of the original pairing created by the inventor of dual licensing (Larry Wall).
What's your beef with Artistic License 2.0 / GPL dual licensing?
I wonder how it plays out in money that comes in, and money that goes into the authors of the public domain tools that get used, and make this all possible.
Do they owe anything today, in the sense of a legal obligation? No.
But we've regulated the tragedy of the commons in all sorts of other instances. There's no reason, for example, that a small percentage of corporate income tax couldn't be allocated to a grant program for free and open source software projects.
That's a good thought in isolation. The problem however is how are you going to ensure the money collected for that purpose go to the projects that actually need it and there wont be any corruption involved?
It isn't hard to notice, for example, that in EU where gamedev companies often receive grants for various nebulous reasons tend to be companies that do not need the money in the first place (and yes, of course there are devs who received money that needed them, somehow people have to excuse the existence things they benefit from).
I don't think you're going to solve corruption perfectly in any system, but isn't that a bit of a red herring?
We manage to do this within other fields of endeavor, at least in the United States, by using an intermediary. Examples: National Science Foundation, Corporation for Public Broadcasting, National Endowment for the Arts.
Redistributing tax money to economically unproductive (and usually worthless, as evidenced by the fact that people wouldn’t pay for it voluntarily) endeavors is a whole debate that has nothing to do with open source software.
Ultimately if people value things, they will buy them. Forcing people to pay for things they don’t want to buy simply because you think it would be good for them is a special kind of tyranny.
It's definitely not a red herring. Software is there to do something. Art isn't. If you're spending money on software, it's to do something, and if it's the wrong thing it's a waste of people's money.
There definitely is a reason, and it's the same reason this problem exists in the first place: it's hard to measure the value a library or tool generates, whether it's open source or not. How are you going to allocate this tax to projects at scale?
Companies already can barely solve this problem internally, and often fail completely at it. Just imagine how many times you read a comment on HN lamenting the lack of investment in IT infrastructure. The idea that you'll solve it at society scale as a government, for things much more nebulous than even IT infrastructure, is laughable.
Grants don't need to be given on the basis of usage alone. Generally speaking, the people on a grants committee would be knowledgeable industry experts who make allocation based on a number of factors like impact, ability of the organization receiving the funds the utilize them well, the sustainability of the project as a whole, the success of previous grant projects, etc.
This just creates a cottage industry of people who are good at writing OSS grant applications and demonstrating "progress". It also keeps incumbents in place. Central funding is the worst idea unless there really is no alternative.
That's honestly the sneakiest suggestion for implementation of communism I've heard so far in my life. Give away low quality software for free, then later demand that the government force people who want nothing to do with you or your code to pay you for your efforts. It's parasitic on several different levels.
Then all FOSS hackers will be like Khrushchev, wondering why Western industry always outproduced his own, even though the Soviets "where doing everything right".
Open source is a gift within a gift economy. The software may be freely used but the labor needs to come from somewhere, and donations of either direct labor or compensation help ensure that the overall gift economy can continue to function.
The stronger claim is that not giving back is short-sighted rather than unethical: using a volunteer product in your business without doing anything to ensure it's long-term longevity risks regression bugs and dependency hell.
Part of the reasons why developers are so common is because starting is easy thanks to these 'free' tools.
They better pay, or some body 15 years from now will have to spend $10,000 just to being learning how to code.
That not only reduces number of programmers that you can hire, that will create a serious general programmer crunch, that will likely increase the cost of making software 1000x.
I've been an open source maintainer (and still am to a smaller degree) and I think sneak is right. I'm happy for people to use things I create and release, and their use doesn't impose costs on me.
Their use doesn't, but from time to time they send in bug reports and feature requests, don't they?
Where do you draw the line between extending your project and providing free labor to a for-profit company?
Fixing bugs is less controversial, while finding solutions to issues arising in bespoke production environments, with short deadlines, is grueling work for which companies are usually gladly purchasing support contract. Where is the line past which you ask for money, and are you really fine helping a company avoid lawsuits and brand damage after they neglect updates for years, with no gratitude from their side? Case in point: log4shell in late 2021
> Where do you draw the line between extending your project and providing free labor to a for-profit company?
I work on my various projects to the extent that it is fun. If it stops being fun, I don't do it. Making something broadly useful is generally more fun than helping someone with a one-off thing, though that is not my decision criteria.
If someone wants me to do something that isn't fun, they can offer me money, though they will generally need to offer me enough more money than it isn't worth it.
If you put in work only to the extend that it's fun, then it is probably something with very clearly delineated scope (kudos for sticking to that!) or not really one of the projects that are so critical that companies should be expected to chip in money for support.
Bug reports are other people doing work for me. I’m fine with that. These are free interactions between people. If you want to charge for bug reports then you can put that in your repo text and just auto-close any issue from non-approved authors.
If you want to bountysource a solution do that. If you don’t want to fix an issue don’t.
Filing a bug report is only half of the work. The bug then has to be reproduced, fixed, tested, documented, and rolled out. Sometimes with a deadline.
If that sounds fun to you, I really cannot argue against it. Usually, that is part of a support contract, and therefore hobbyist open source developers basically supply free labor to for-profit companies.
Just seeing the issue submissions can have a cost in terms of emotional impact. Of course, you can shield yourself from any feedback, but that has its costs as well (e.g. not getting genuine high-quality error reports). One has to live with those trade-offs.
It’s being phased out quite aggressively there. Turned out they had such a bad reputation for tech debt thru couldn’t hire people despite paying +50% median Amsterdam developer salaries.
I interviewed with them once. The worst ever interview with incapable rude interviewers, who didn't even know the answer to their questions. They came p with some bizarre offer which I'm glad I declined.
I knew someone whose company put out $$$ senior job ads when they had a problem they couldn’t solve in house, then picked interviewees’ brains without hiring them.
I would gladly take that experience over "yet another minesweeper something" or its more evil friend "reimplement some esoteric algorithm no one uses in their day job". I mean, sure, fake jobs are always evil but if you're gonna have a fake job at least make it produce something for humanity
The back side of that coin is: how catastrophically dumb must they be to have a problem that a stranger can solve on a whiteboard in an hour but your whole organization can't in a sprint?
I think a lot of companies are kind of realising the tech stack they use has a bigger impact on hiring than salaries. I believe banks are encountering this issue with no one wanting to do C++ anymore.
I am not sure you understand the problem. Your first sentence hints that you know that there needs to be other things than tech stack and salary to find talented C++ programmers. But the second sentence pretends like you didn't write the first sentence.
I said tech stack affects hiring more than salary. I didn't say there is a lack of C++ programmers. I was very explicit about my statement.
OP was ignoring the point and basically implied the reason banks have issues hiring these days is because they're banks. While in the past they didn't have these issues. Why? Because tech stack matters for a lot of people.
They always had these issues, I barely know anyone that freely replied to job interviews for a bank, given the work environment, as I am approaching 50y, have already seen quite a lot in consulting projects.
They had the same problems everyone had. There are more jobs than programmers to do the jobs. But now they've got the added problem of Rust, Go, etc taking over.
You weren't all that explicit, and GP responded to your comment as written. There really is no call for being this rude just because you think you were misunderstood.
1. I explicitly wrote that people care more about tech stack than salary. Then gave an example where an industry has that problem. The response was about if you have other attributes you can find someone. Fundamentally ignoring the point.
2. Rude? The person who replied did what was said. The first sentence implied that my point was indeed correct. Then the second sentence just ignored what the first sentence implied and ignored the point. They seemed to think the problem is a long-standing problem that banks have. Instead of a problem that has been growing for years because the supply of people who know the tech stack is decreasing. It's fair to point out to people you don't think they understand the problem.
3. Misunderstood? I believe they implied in their first sentence I was correct and that they understood the point. They just didn't like the point.
It'd probably require expensive on-the-job training, which is well out of fashion. Sure, folks could teach themselves COBOL in the hopes they might maybe get hired by a bank, but they'd be better off spending that time learning a language with broader industry interest.
Better pay sure, less stressful, not the ones I had as customers.
And you better like to come in a proper suit to work, and talk to your work colleges in formal language, regardless of how many years you happen to have worked together.
Or you move over to Go or Rust. Just like Perl programmers moved over to PHP, Python, and Ruby.
It seems crazy that in a community like this, people seem to ignore the fact that people move on to the shiny new tech. And those aren't even that new anymore. It feels like same as how Perl programmers acted in 15 years ago when PHP and Python were eating up all the new projects.
They used to donate something like 100k/year, had a handful of core and library developers on payroll, and hundreds of devs occasionally contributing code.
And that's the flaw of the open source business model.
You develop something for free, make it available to everyone for free, allow them to modify use and misuse as they wish. Every single step is your conscious decision.
And then, you beg for donations, and complain that people are not donating?
Doesn't make sense. If you don't want to work for free, just charge for it.
If it was a business model then people would charge, but it’s not a business model it’s an ideal that leads to a common good.
There are parallels to funding education and scholarship programs in public universities. Corporations often rely on human resources around office locations and they spend in order to ensure a steady flow of talent development. Funding open source is not that different of an issue. One challenge here is IT/Tech departments are often cost centers that are strictly budget controlled and it’s harder to make a case for non-essential costs like funding open source.
Perl was created by someone in their spare time away from their day job.
When he needed money he just wrote books and charged for those. Ironically the publisher of those books hired him to continue working on the _language_, and of course, write more books.
I meant the company did not participate in it's creation nor did they fund it in any way. If they had they certainly would not have approved of it being released under an open source license. Also Perl 1.0 was released using Larry's NASA email address and not any other corporate one.
I believe it was NSA not NASA - in his hubristic style larry wall described perl as being born from "a secret project in a secret laboratory".
I'd say the biggest influence on my programming work is recognising how to use that style of humour can help deal with situations that can sometimes get to quite high pressure - e.g. "please rescue this failing 9 month long $x^e6 project before it goes live in the next fortnight"
Cygnus, Red Hat, MySQL, JBoss etc. all had successful business models.
Android, React and other projects come from companies with mixed business models, but they have had success as well - there are billions of active Android phones, and many web sites running React.
Some open source companies did not do well, but lots of closed source companies do not do well either.
Also, open source is not just a business model - sometimes people just give software they wrote away.
I think it's fair to point out that there are two distinct open source models in play here;
There's the "old school" open source, which releases product for the common good. Think Linux, Gnu, Emacs etc. This group would object to the term "business model" since they are explicitly not "businesses".
The second group are commercial products, from commercial companies who wish to leverage some aspect of Open Source to further their commercial ambitions. Think (pretty much) any VC funded "Open source" product. I 100% agree with you in this context.
The latter group (sooner or later) discover that cloud providers will happily offer their product as a service, exactly how their OSS license permits. They are well positioned to extract value from the offering, and thus charge for it.
So yeah, you'll see these companies pivot to a proprietary license - but honestly I don't mind when they do - for them, being OSS was transactional in the first place do it was never going to last forever.
Yeah, I've never thought it compulsory to reimburse for any open source software. Some projects are "lucky" enough to have large corporate contributors/stewards, and others are projects of passion.
Maintenance activities (bug reports, feature additions, participation in community discussions, etc.) should be considered a form of "paying" for OSS - you're giving back and improving the ecosystem. I've done plenty of that for various projects; it's something that I enjoy doing.
It says a lot about how threatened these companies must be: AT&T claims to be profitable, but their infrastructure investment is focused entirely on obstructing competitors. Craigslist used to be a star, but they must be under severe pressure to avoid collapse to have withdrawn ecosystem donations. It says a lot about the fragility of DuckDuckGo that this is all they could commit to Perl, which is really unfortunate; they could have been excellent, but instead their star is apparently diminishing. Oh well.
I am fully with you, although in AT&T's case they already offered UNIX, Plan 9, Inferno, C and C++ to the world, so maybe that excuses them at the FOSS crowd eyes?
Lets forget about that lawsuit, and trying to take a certain book out of print. /s
A: This is great! Perl is much maligned but a fantastic Swiss army chainsaw and still runs so much critical infrastructure.
B: I find it concerning that $25k is a notable donation; is the Foundation doing that poorly? I would have hoped this number to have two more digits in it for it to be a front page worthy item.
I'm surprised to learn that Perl is still used. Obviously there will always be legacy code to maintain but these days I can't even remember the last time Perl was mentioned in casual conversation amongst my peers unless we're sharing war stories from the 90s.
These days when we find ourselves needing to write a script our first go-to would be bash, and if we need more features or if it's going to be complex enough to have to worry about maintenance costs we'd probably reach for python.
TIL that there is a non-profit foundation that focuses, in part, on supporting Perl. That surprises me to the same extent that I would be surprised to learn that there is a foundation aimed at supporting VB6 (though now watch someone is going to share that there is).
For this year's London Perl & Raku workshop I shortlisted 70 companies to look for sponsorship. That was with minimal research and effort. These ranged from long term ("legacy") users of Perl to startups. From small companies to very large and profitable fintechs. I cover this briefly in the talk I gave at the end of the workshop: https://www.youtube.com/watch?v=el7qHRpEDeE
Yes, there is far less Perl than there was 20 years ago. But Perl was everywhere at one point, and the halflife of programming languages is long so it's still in a lot of places. Programming languages don't die, they just stop being talked about in favour of the shiny new ones.
> Programming languages don't die, they just stop being talked about in favour of the shiny new ones.
You're largely preaching to the choir, I don't disagree with anything you said.
As a web application developer who got started professionally in the 1990s, I not only vividly remember Perl being everywhere, I actively wrote a lot of it.
However, in my more recent experience, it is more likely to hear people talk about COBOL, FORTRAN or C++ than it is to discuss Perl. All of those languages predate Perl.
Java also still gets a ton of discussion and it's not shiny and new anymore.
Most of us who spent time writing and maintaining Perl in the 1990s were all too willing to abandon it in favour of other languages with similar features, not because they were shiny and new but because of major pain points with Perl (it earned the meme that it's a write-only language). In my opinion, Perl's greatest contribution and staying power was it's regex engine and syntax which persists.
I don't even like python, for what it's worth, but it's popular for more reasons than it just being "shiny and new" (to the extent that you can even say that about python these days).
My main issue is that "People still use Perl?" has essentially become a meme at this point. I'm relatively sure that any sufficiently commented on or upvoted thread on HN gets that statement in it somewhere.
Yes, Perl is still used. Extensively. People and companies just don't talk about it. That's the problem with Perl these days.
(Personally I think TAP and CPAN were Perl's greatest contributions, as I was never a heavy user of regexp).
* The Perl they have is so low maintenance they don't think about it much
* Or they're planning to rewrite it but haven't yet got around to it... after more than a decade?
* They have nobody working on it that is vocal about it or active in the community/blogsphere/etc
* The company policy is to not talk about it
* Or talk about any tech they use - think: banks, large enterprise, fintech
* Or they're successful enough they don't feel the need to talk about it
* They're open source tools or distros that have a mass of other tech so Perl gets ignored even though its practically embedded - Linux distros, git, etc
* The Perl is on the periphery, or not the core logic - test suites (memcached for example), used in build systems, pipelines, Make, oneliners, etc
There's an argument to be had that Perl's strong backwards compatibility has meant it has sat there working in the background for years (decades in some cases). And, as most of us know, when tech "just works" it doesn't get talked about.
I think that all makes sense. I would perhaps as an outside observer also lay the blame at Perl's feet - with Perl 6 the momentum seemed to crash completely over a decade or so.
Last company used Perl but we didn't talk about it because it was all frozen. If anyone ever considered touching it for more than 2 hours, it was likely to get rewritten into Python/Powershell. Last perl thing I had touched, entire repo hadn't seen a commit for 4 years until mine.
I think the lack of discussion of perl is in part because from a bird's eye view, python and perl do exactly the same stuff in exactly the same way, but python has the mindshare. Because of perl's depth and flexibility, for the average developer team it can be really hard to manage.
There's a similar story around javascript - note how es6(?) introduced `"use strict"`. Old school javascript always struck me as a bit like crippled perl with really good vendor support.
I am constantly parsing reports and then generating commands to run from that. I learned Perl in the 90's and it still works great for that.
I have to code in Tcl for most of our EDA tools (chip design) but I still parse reports in Perl. The younger engineers use Python and I've learned enough but I really don't care. I'm not writing big systems or anything in Perl or Python. It's the Tcl code that has tens of thousands of lines because that is what the tools require.
Curious: do you also do script-writing in other languages? And just pull out perl for a subset of problems? Or are most things at the "bigger than a script" level for you?
I'm not here to judge. I still prefer to write my python scripts like it's the 2.7 days... (more effort goes to python "code")
Generally, if the script is more than a one-off, I will write in Python, since all the young seem to know Python, and very few seem to know Perl. There are two recurring jobs that I have not rewritten from Perl, one because "pack" is so handy.
The only other language I use much for scripting is Javascript, or rather Jscript, for our accounting department sometimes needs files munged for integration into Great Plains, and I can count on cscript being on the machine and running such scripts.
Perl was/is just so powerful, people have used to do all kinds of things that most people probably don't even have idea can be done. Its some what similar to the power of macros in vim/emacs. People(especially young) are often surprised you can just open vim on a ec2 instance and do something in 30 seconds, they were planning to spend hours/days doing using java+bash or something.
I have both seen and done, people build such extreme, big and hard things with Perl and so quickly, that I'm sure somebody without that context would find it hard to imagine. Im sure you can do in Python, anything you can do in Perl. But definitely not in the same time, not the same size and more importantly- not often.
Programming culture has been trading tool power for beginners ease for decades now, and the market is swamped with tools that appeal and work only for beginners not for advanced users.
In its hey days Perl programmers would do things in a weekend, what the neighbouring Java team had 12 people and a year to do. There is a reason so much was built in Perl in those days. But like most things, money increased, people had lots of time and budget to get things done. Beginner tools got used more often. Perl also got its reputation as a hard to use tool around that time.
But honestly I see so much manual drudgery these days. Its irritating to see that as a Perl programmer. There is nothing more sad that watching people do work, that must be done by a program.
I'm not sure how to answer that. Some can write a short, personally useful script. Some can do much more. Which are the crudest parts of Python, and which are less or not at all crude?
Languages have deep features. That's why people create new ones (except for PHP perhaps). You can write BASIC in any language you want, it's still BASIC.
Languages systems or environments have still other deep features themselves. The library or module systems in Python or Perl or Raku do not work the same.
Being able to write "a short, personally useful script.", is a great start. And does not count as "knowing Python" except for the purpose of inflated resumes. The clichés of complaining about "line noise" or WORN (write once read never) - since the fine article was about Perl - counts specifically as "not having learned Perl".
In contrast to other people, I'm fairly young (low 30s) and I use Perl a lot. I've outlined my reasoning before[1] but it boils down to (a) very quick to get going, (b) runs everwhere I care about, (c) great compatibility story, and (d) can scale up to large applications in a pinch.
Practically all Japanese BBS in use today are written in Perl. They are either proprietary CGI scripts or a proprietary fork of an open-source software like WebPatio[0] and Zero-channel Plus[1].
> these days I can't even remember the last time Perl was mentioned in casual conversation amongst my peers
I mean, what's there to talk about? It's there, it works, not an exciting subject. It's like municipal water (if you have it), it's indespensible, but what is there to say about it. (Unless it has stuff in it you don't want)
I did get some flack for writing a perl script for work recently, but I had some rubbish to list, and it does the job quite well.
Regarding B: This tracks with what I've observed in this regard, namely that sponsoring by companies just doesn't work well as business model even for projects where you would assume that it should. The incentives are just not working out, and it seems impossible to mobilize even a fraction of the sums for OSS-donations than what companies burn for much less critical aspects of their operation than OSS tools/libraries/components (or waste outright).
Open source is largely a thing because lots of people voluntarily invest (valuable!) time on their own in my opinion (with corporate sponsorship being almost negligible by comparison).
Most big open-source projects are a thing because a companies invest in it. When we rely on people doing it in their free time what we see is unmaintained software.
The entire idea that open source is volunteer work is largely a myth when it comes to popular open source. Even the ones where you think it's volunteer work they do so much during their working hours that either they're lying to their employer or it's sponsored by their employer.
Isn't it both? In particular dependent on the size of the project?
And it's still easy for individuals to at least contribute detailed problem reports even to very large projects. And these are useful. Even when ignored by the lead mafia.
It is mind boggling how much funding there would be for the Gimp/Krita/Inkscape/Penpot developers if every designer gave them 5% of what they give to Adobe.
We "just" need to flip the narrative. Let's stop talking about "services" that people need to pay for and make FOSS something that people invest so they can (collectively) own later.
People love to shit on crypto, but no other industry got so many small-scale, open source projects that got funded when people have high hopes of making bank from it.
I wonder if we could get people to invest in open source projects that were tied to a short position on the proprietary counterpart.
Indeed. What concerns me is that with the current AI trends, the amount of funding that the Adobes of the world will put into AI for their products will only widen the gap between OSS and proprietary solutions.
I see it as an opportunity. "Libre" models are already matching state-of-the-art models, so it's not like this power will not be available to the OSS developers.
I don't know the dynamics of this board but does anyone else find it strange that the secretary is digging through public documents to generate a post outlining finances? Is that not what the treasurer should be helping with? Then the treasurer makes a public comment to the post? Feels very strange to me.
But to answer the bigger question, yes, I think this was a bit weird. I was also on the board for a while, and I think we did not do a good job of reporting on and monitoring financials. This was one of my frustrations with the organization, and part of the reason I stepped down from the board (though there were other, bigger, reasons not related to the board as well).
In fact, I had made the same points as Makoto does in his blog post maybe 1-2 years earlier in a board meeting. We were running a constant deficit and we didn't seem to have a clear plan for what we would do if that continued.
Not sure what the path out here is? Seems like either finding deep pockets that care about their work or some new revenue stream, but without the cash to fund it I’m not sure how.
Maybe programmers at companies using Perl get together and raise the issue with management? It is a bargain. Imagine the cost of having to rewrite all that Perl.
My sense is that perl deployment is declining as it's replaced with better tools. What infrastructure is perl running?
I started playing with Ubuntu in 2006. Exploring the system, I'd come across system scripts in perl here and there, but Lennart Poettering has gradually displaced these with unit files that are much easier to read.
These days I may invoke perl occasionally. A few years back I used checkconfig.pl to build a slimmed-down kernel config for an embedded board. I expect it will eventually be phased out of these peripheral utilities.
Perl used to, but I'd say not anymore at this point.
Many of the big Perl names long moved on; CPAN is full of abandoned modules. And the world doesn't sit still.
So as time goes by, there's more and more risk of you finding out that some Perl module you're using no longer works. It may not build because of API changes in the C library, or the API of some web service changed, or there isn't an API at all for some pretty big thing that showed up 3 years ago.
> A: This is great! Perl is much maligned but a fantastic Swiss army chainsaw and still runs so much critical infrastructure.
You know, I hear this a lot (especially earlier in my career) but I _never_ ran into any system made in perl, ever. I started my professional career in early ~2010 and have been programming since ~2005.
Maybe they are just very black box-y and I don't even know that the underlying stack is perl?
Given the number of private companies that rely on Perl, $25K is in the ballpark of what _each_ of these companies should contribute to the Perl community.
DDG is not responsible for the greed of companies that contribute zero.
I applaude DDG's decision. Their move is pragmatic and a lot more inspiring to the companies out there than day-dreaming of a single company donating 7- or 8-digit to the Perl community (which, frankly, would not be sane either).
Relevant: Zerodha's Floss.fund is giving $1M this year for FOSS projects, and haven't got enough applications. Please apply and share: https://floss.fund/
> FLOSS/fund is dedicated to supporting critical, impactful, and valuable Free/Libre and Open Source projects globally. We give up to $1 million per year to support developers and communities that create and maintain projects, big and small.
I always forget that DDG is written with Perl, even after I emailed yegg a million years ago asking why they used Perl, and he responded back, which was nice of him.
I hear Raku is fun, I haven't used it, but I sort of swore a soft oath that I would never touch Perl again about a decade ago after having to debug some regex magic someone did. I'm assuming that once you get past the "hump", Perl becomes fun?
Regex and is a separate language used by many tools, Perl just made it nicely integrated into the language, and also made some nice enhancements. Don’t blame issues with regex on Perl.
It s just a lang like any other. Even ASM you can write fairly easily if you do it for years. Raku is quite damn cool, you should check it out a bit. As felix[1] said, it realy is something like bash and python having a cool cousin.
Wasn't the original benefit of Perl that it was fairly close to a standard tool, i.e. it was available on pretty much any server you would be pushing a script to anyways?
Raku doesn't seem to have the same ubiquity, while Python is generally available on any system, or even Perl5 is still widely available on pretty much any system. I'd love to start using Raku more but it seems like a hard sell over Python or Bash
Perl and Raku are grouped together today primarily for historical reasons. Yes, Raku started as Perl 6 and is certainly a Perl-inspired language, but the rename happened precisely because it is so different.
Regarding regexes, Raku introduces a whole new syntax, makes whitespace non-meaningful by default, and allows regexes to be named and then composed/reused. Those three changes, along with helpful modules like Grammar::Tracer, make reading and writing regexes a totally different experience. It's still going to look like noise at first, of course, but even then the syntax parallels normal code far better than PCREs, so you're more likely to make a correct guess about what something means.
raku is amazing. It's perl to the power of perl. Which is why I adopted it. I used perl for its power and expressiveness, and for its layering (never having to learn the entire language at once: one feature at a time is fine). Raku does not disappoint and is a stellar successor (and I'll never know the whole thing :-).
Regarding your oath, it's been 10 years and perhaps you are better now at learning language features. Raku's documentation is very good ... but a very different format that perl. And raku doubled down on regex documentation and structuring ideas (which are completely applicable to refactoring somebody else's regex). And the usual forums are excellent at helping with raku questions.
Hello!
I don't have a lot to say to you, but I just wanted to say that about a month ago, I started the transition away from Google, and the most obvious thing to switch was search.
DuckDuckGo has improved substantially since the last time I used it (around 2012), and it's to a point where the results are comparable, and sometimes even better than Google, so changing was pretty seamless. Now the only Google-thing I need to remove from my life is YouTube.
As a somewhat technical person, I was curious about one thing; I saw that the primary language for DuckDuckGo is Perl. Without making any judgement here, was there a particular reason for that choice? Also, are you planning to move to Perl 6?
Anyway, I appreciate you reading my email. DuckDuckGo is a great service, and I hope you guys keep up the good work!
-Thomas Gebert.
Here was his response:
Yes, though, the primary language is Perl. It was out of convenience and interest since that was my primary language when I started the project. There was/are a lot of libraries useful for text processing / web crawling. Now Python and other libraries have been similarly built up.
Always makes me laugh when I read things like "2018 is still a long time ago" (no offense or downvote). But also the very thing that perl fought against. Your programming is not going to break for a long time (much longer than 6 years) because there is no reason for language features to change that quickly - certainly compsci theory does not change anywhere that fast.
It takes time to build very large projects like a large, layered programming language, and it should be normal to take many years to learn all the features of something like perl or raku. Because there should be no reason to do it all at once rather than be productive in the meantime.
So anyway, 6 years should not be much in the career of a programming language.
This reminds me of Evan Czaplicki's great talk where he basically traces the funding of most modern programming languages to search engine revenues :-) https://youtu.be/XZ3w_jec1v8?si=zdL6v9P8LnT7Cbal
Wonders why raku is not really mentioned in the discussion?
Then I remembered my daily mantra:
- NO_ONE cares about the community
- WHAT_THEY_NEED is UniCode & Rats
- WHAT_THEY_LIKE is poetry (not golfing, but an expressive professional medium not desecrated by ‘public void’ line noise)
- WHAT_THEY_KNOW is CPAN, DWIM and REGEX (the easy is easy and the hard is possible)
- WHAT_THEY_WANT is Grammar, Functional, OO, Declarative, Concurrency, Dynamic Type … oh and Procedural done v clean
- WHAT_THEY_HAVE is PHP, Ruby, Python, C#, Go, Perl5, ECMAScript, Java — demand for raku is pent up.
So, I detect some natural frustration within and without the community. Keep the faith. We have a new audience, they value truth and beauty, and a story of battling the odds. They need this TECHNOLOGY. It is [perl6 | raku] – who cares. It may have to start in academia, it may have to start in the p5 stalwarts. It will ignite. Finish the journey. Do not deny your heritage.
Most of the someone else's I have read has been in stuff from CPAN, and I recall it as pretty good. I have written some pretty bad Perl, and wish that I had encountered the O'Reilly Perl Best Practices long before I did.
Perl's "layering" is one of its most brilliant features. You start learning Perl in layers; achieve some fluency and effectiveness and understanding of the general principles - and will still have many layers and sets of features that you can dig into as you progress. The set of O'Reilly books was amazing for this. Still is. But the documentation itself was amazing also. Still is. That's one problem with Raku: Can raku ever get to this level?
This is important as a powerful tool for a powerful programmer.
I always contrast this to C++ - where you are dangerous, too dangerous, until you have learned a huge amount "of the language" (and good luck understanding it). Or BASIC, where... there isn't much.
As a perl programmer from decades past (I transitioned to Java during the perl 6 winter), I've been finding that groovy and even more recently scala are really nice tools for what I'd have traditionally done in perl.
When doing this year's advent of code, some of the terseness of symbols reminded me of perl.
Perl lost me and I transitioned too far away from its ecosystem professionally to return for more than a dalliance or occasional debugging ( https://news.ycombinator.com/item?id=16219876 ).
One of my impressions as a Scala newbie coming from a perl background years ago was that Scala practitioners' culture in a corporate setting tended to end up with code bases that reminded me of corporate perl code bases - suffering from "theres more than one way to do it" disease. A bit too easy to be obscure for me to use/recommend it since then despite the nice typing, actors, lazy evaluation, etc. Not sure if this TMTOWTDI Scala resonates with others knowing both or not...
> Scala feels like the Perl of the modern era: there is more than one way to do it. There is value in that mode of thinking, and Perl is a better language than people give it credit for.
> This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.
---
The question of company dialects for various languages comes up occasionally. You can see it with people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
I suspect that flexibility is similar to what is seen in perl, ruby, scala, and groovy.
The TMTOWTDI Scala exists... but I want to say that it is more a reflection of the power of the language (drawing from their LISP heritage). It becomes then a question of how much does the company impose a consistent way of doing it within the company (compare the different company dialects).
> people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
Which people, where? Do you have a URL to a discussion?
I've not seen heard or read such talk almost 25 years of being involved in open source Lisp. Needless to say, I've often seen such narrative repeated by programmers not working in Lisp, who heard it from such others.
Someone talking about any industry work in Lisp whatsoever, even just one job, from any angle, is extremely rare.
And that does get into the "25 years ago" area. Really neat place to browse and see as a historical record of discussion from back then.
The issue is that languages that allow/encourage writing domain specific languages within the environment leads to people doing exactly that - writing a DSL that is then used in that company.
These languages (and Scala too) allow for writing a dialect of the language that differs substantially from the main language.
I've seen it in ruby. I've personally done it in groovy (wrote categories to make certain reports easier to write)... twice (also wrote a DSL in groovy that matches the script used as input for powershell doing ftp so that instead of `ftp.ps1 script` it looked like "add this import to the top of the script and do `groovy script`")... for that matter gradle is a groovy script that has gone well beyond groovy as a DSL.
Just as the problem existed with "having to learn a new LISP dialect" 25 years ago, many times going from languages that allow for such flexibility in how its written from one shop to another have the "having to learn a new {language} dialect" today.
For code that I have to work on with someone else, I believe it is better/easier to work in a language that doesn't allow you to rewrite the language so that when I have to work with yet another person, they don't need to learn a completely different way of doing it from what they knew previously.
My impression of Perl, as someone who wrote two scripts in it twenty years ago and has been on the Internet since the middle-old days, is that it is a language suited to being clever.
This observation is spot on and 100% of the reason why dealing with other people's code is insufferable. After 20 years of coding I can confidently say I'd rather clean out crawlspaces for a living than deal with another "clever" codebase.
Programming is an individual activity; developing software is a social activity. Current tools and teaching are still biased in favor of the former, resulting in most of our troubles in the latter.
It's more of a technical liability to write anything new in Python. All of my old perl code still runs fine, all of my python code went unusable since. It's also extremely bloated.
I upgraded to Debian 12 and all of a sudden my Python 3 code is destroyed and I have to jump through hoops to make pip work correctly again for libraries that were already on my machine. I'm leaving for greener pastures as the webdevs have ruined another good scripting language.
Another post in the thread mentions ATT; I can confirm that at another large telecom, Perl is still used in quite a few places, and is still being used for some new projects as well.
Good for them. They don't have to but they chose to.
What they have done (perform around 100M searches a day) is phenomenal. Testament to their marketing.
Unfortunately as a search engine, it's still just a skin of another one, with some additional small scale projects attached.
It's slightly surprising that DDG hasn't attempted to become a 'real' search engine, rather than being a meta. At the moment they make a subset of Bing's revenue per search, never mind what Google make.
Craigslist used to donate over $100,000 every single year. Not sure when that stopped. That is really what kept perl going between the years of 2010 and 2016 or so. The board was actually paying a couple of people to do maintenance on the core repository and code. I believe they still do that but obviously due to deficits that is going to get difficult.
It's sad when so many companies are dependent upon perl, but donate nothing. A good case in point is AT&t in the 1980s was broken up into 20 plus different companies. They were then remerged back in the 1990s. But when they merged, they had 20 different computer systems and perl was actually used to glue all those systems together and handle data sanitation and ETL pipelines. Yet AT&t never donated anything to perl.
I miss Craigslist, seems like everyone moved over to Facebook Marketplace a few years ago.
Anecdata but as a buyer and seller I consistently have had a much better experience on CL. It might be region-specific.
I still use craigslist and haven't actually done anything with facebook marketplace yet. That makes me want to delete my facebook account (something I've been considering anyway) just to nip that possibility in the bud.
If you’re trying to sell something, you need to be where the customers are. If they’re on Marketplace, that’s where you go. You can easily list in both places.
Marketplace is literally the only reason I still have a facebook account. Unfortunately the alternatives here get nowhere near the same number of buyers.
Not a good enough reason for me to go back to using Facebook regularly. For others, sure.
There’s no requirement to be actively reading and posting to Facebook in order to use Marketplace.
I think a good chunk of people would be worried to buy/sell from/to an account with little to no activity at all. This is very strong signal of low effort spam already common on FB Marketplace.
[dead]
Gifts don’t require repayment. Releasing free software is a gift to the world. Corporations don’t owe free software maintainers a cent, because people using your software doesn’t cost you anything.
100%. This new trend of maintaining or starting an open source project and then getting upset when people don't send you money is seriously weird. If you want compensation, start a company, otherwise consider anything you receive a gift.
Yeah, though I have sympathies for single devs or projects like perl that are obviously non profit. Like, I get the frustrations for actual volunteers and people who survive on building OSS at a small scale.
What really annoys me is when someone decides to build a corporation around an open source project, and then you get the usual blog post around users not paying or OSS not being sustainable. Yes, using OSS as your marketing and adoption strategy is probably not very reliable and can cause users to use your OSS as if it was OSS, that is, without giving anything back. But usually those projects succeed because they are OSS, and would've had basically no users otherwise. Who would've used MongoDB, elastic search, or redis if they were proprietary and required a paid license from the get go?
In a way, that's also true in this case (success came from being OSS) but again, I get why it seems unfair for some when it's a non profit not being able to sustain itself or get contributions for corporate users.
The problem is, if their software had cost what it needed to from the start then that would've put it in a totally different competition with other companies. Bypassing that competition doesn't mean they can suddenly start complaining about how many customers they have vs how much they get.
Yeah I completely agree and that's exactly why the most annoying part of the OSS sustainability conversation. Most of the big OSS players (not individual devs, I'm referring more to the open core type of corporations) would just not exist at all, much less make more money, without OSS. No matter how much money elastic search lost to Amazon for example, they would've made basically nothing without OSS.
You can also do things like dual licensing.
GPL or Affero GPL plus proprietary license. Of course this puts off outside contributors so not if you want a "bazaar" development mode—but people complaining about this are usually not doing so.
Perl might have been the original dual license. GPL or Perl Artistic license.
I remember learning about Affero at a Perl Conference in the late 90's or so.
First off, the AGPL license is nonfree (and also nonsensical, it is a EULA pretending to be a license), but more importantly, dual licensing means that you don’t actually believe in software freedoms. If you think users have basic and fundamental rights to the software that they run on their computer, you would never release software under proprietary licenses.
It’s like Microsoft’s VS Code nonsense where all the important bits are non free, or any company with “open core”. They don’t care about software freedoms; it’s just open source cosplay.
> dual licensing means that you don’t actually believe in software freedoms
If both licenses are accepted by essentially everyone as inherently fully free software licenses, and they don't contradict each other, then what's not to like?
Consider the appropriate example here, which isn't anything to do with AGPL (which many people do NOT accept as a free software license), but rather the AL2 / GPL pairing which was the evolution of the original pairing created by the inventor of dual licensing (Larry Wall).
What's your beef with Artistic License 2.0 / GPL dual licensing?
The problem, for some, is that they believed the dream it is possible to make a living out of free software.
They forgot to read the footnote on how it actually works in capitalist and money driven societies.
I make a good living only writing public domain software. Most of it is never published to the web.
I wonder how it plays out in money that comes in, and money that goes into the authors of the public domain tools that get used, and make this all possible.
What do you mean? Would you please elaborate on that?
Do they owe anything today, in the sense of a legal obligation? No.
But we've regulated the tragedy of the commons in all sorts of other instances. There's no reason, for example, that a small percentage of corporate income tax couldn't be allocated to a grant program for free and open source software projects.
That's a good thought in isolation. The problem however is how are you going to ensure the money collected for that purpose go to the projects that actually need it and there wont be any corruption involved?
It isn't hard to notice, for example, that in EU where gamedev companies often receive grants for various nebulous reasons tend to be companies that do not need the money in the first place (and yes, of course there are devs who received money that needed them, somehow people have to excuse the existence things they benefit from).
I don't think you're going to solve corruption perfectly in any system, but isn't that a bit of a red herring?
We manage to do this within other fields of endeavor, at least in the United States, by using an intermediary. Examples: National Science Foundation, Corporation for Public Broadcasting, National Endowment for the Arts.
Redistributing tax money to economically unproductive (and usually worthless, as evidenced by the fact that people wouldn’t pay for it voluntarily) endeavors is a whole debate that has nothing to do with open source software.
Ultimately if people value things, they will buy them. Forcing people to pay for things they don’t want to buy simply because you think it would be good for them is a special kind of tyranny.
> Forcing people to pay for things they don’t want to buy simply because you think it would be good for them is a special kind of tyranny.
Wait until you learn where the rest of your tax dollars get spent.
It's definitely not a red herring. Software is there to do something. Art isn't. If you're spending money on software, it's to do something, and if it's the wrong thing it's a waste of people's money.
> There's no reason
There definitely is a reason, and it's the same reason this problem exists in the first place: it's hard to measure the value a library or tool generates, whether it's open source or not. How are you going to allocate this tax to projects at scale?
Companies already can barely solve this problem internally, and often fail completely at it. Just imagine how many times you read a comment on HN lamenting the lack of investment in IT infrastructure. The idea that you'll solve it at society scale as a government, for things much more nebulous than even IT infrastructure, is laughable.
Grants don't need to be given on the basis of usage alone. Generally speaking, the people on a grants committee would be knowledgeable industry experts who make allocation based on a number of factors like impact, ability of the organization receiving the funds the utilize them well, the sustainability of the project as a whole, the success of previous grant projects, etc.
This just creates a cottage industry of people who are good at writing OSS grant applications and demonstrating "progress". It also keeps incumbents in place. Central funding is the worst idea unless there really is no alternative.
That's honestly the sneakiest suggestion for implementation of communism I've heard so far in my life. Give away low quality software for free, then later demand that the government force people who want nothing to do with you or your code to pay you for your efforts. It's parasitic on several different levels.
Then all FOSS hackers will be like Khrushchev, wondering why Western industry always outproduced his own, even though the Soviets "where doing everything right".
Open source is a gift within a gift economy. The software may be freely used but the labor needs to come from somewhere, and donations of either direct labor or compensation help ensure that the overall gift economy can continue to function.
The stronger claim is that not giving back is short-sighted rather than unethical: using a volunteer product in your business without doing anything to ensure it's long-term longevity risks regression bugs and dependency hell.
Part of the reasons why developers are so common is because starting is easy thanks to these 'free' tools.
They better pay, or some body 15 years from now will have to spend $10,000 just to being learning how to code.
That not only reduces number of programmers that you can hire, that will create a serious general programmer crunch, that will likely increase the cost of making software 1000x.
> because people using your software doesn’t cost you anything.
Tell me you've never been an open source maintainer without telling me you've never been an open source maintainer. :)
I've been an open source maintainer (and still am to a smaller degree) and I think sneak is right. I'm happy for people to use things I create and release, and their use doesn't impose costs on me.
Their use doesn't, but from time to time they send in bug reports and feature requests, don't they?
Where do you draw the line between extending your project and providing free labor to a for-profit company?
Fixing bugs is less controversial, while finding solutions to issues arising in bespoke production environments, with short deadlines, is grueling work for which companies are usually gladly purchasing support contract. Where is the line past which you ask for money, and are you really fine helping a company avoid lawsuits and brand damage after they neglect updates for years, with no gratitude from their side? Case in point: log4shell in late 2021
> Where do you draw the line between extending your project and providing free labor to a for-profit company?
I work on my various projects to the extent that it is fun. If it stops being fun, I don't do it. Making something broadly useful is generally more fun than helping someone with a one-off thing, though that is not my decision criteria.
If someone wants me to do something that isn't fun, they can offer me money, though they will generally need to offer me enough more money than it isn't worth it.
If you put in work only to the extend that it's fun, then it is probably something with very clearly delineated scope (kudos for sticking to that!) or not really one of the projects that are so critical that companies should be expected to chip in money for support.
Bug reports are other people doing work for me. I’m fine with that. These are free interactions between people. If you want to charge for bug reports then you can put that in your repo text and just auto-close any issue from non-approved authors.
If you want to bountysource a solution do that. If you don’t want to fix an issue don’t.
Filing a bug report is only half of the work. The bug then has to be reproduced, fixed, tested, documented, and rolled out. Sometimes with a deadline.
If that sounds fun to you, I really cannot argue against it. Usually, that is part of a support contract, and therefore hobbyist open source developers basically supply free labor to for-profit companies.
You don't have to fix bugs. They can remain bugs. Deadlines are other people's problems.
Tech support still takes time.
When you release an open source project you are not obligated to provide tech support.
My project might be given to you for free but if you want my time you'll have to pay for it - and i get to decide if i'll sell it to you.
Just seeing the issue submissions can have a cost in terms of emotional impact. Of course, you can shield yourself from any feedback, but that has its costs as well (e.g. not getting genuine high-quality error reports). One has to live with those trade-offs.
I have 37k unread messages in my in email inbox. I can ignore issues on github that don't interest me, too. :p
Or, as the case may be, claim that I'll look at them soon, and never make it back.
Tech support is entirely optional, and I only do it to the extent that I enjoy it.
(Or, when at one point I had a job as an open source developer, to the extent that I thought it would improve our software.)
> Releasing free software is a gift to the world.
definite maybe, but it is not only that.
booking.com is, I think, still a heavy Perl user. I don't know to what degree they give back.
It’s being phased out quite aggressively there. Turned out they had such a bad reputation for tech debt thru couldn’t hire people despite paying +50% median Amsterdam developer salaries.
I interviewed with them once. The worst ever interview with incapable rude interviewers, who didn't even know the answer to their questions. They came p with some bizarre offer which I'm glad I declined.
Haha well I use to interview people while working there, I hope it wasn't for a mobile position?
No, just web stuff, not mobile. That’s sort of 2015 timeline, ancient history now :)
I knew someone whose company put out $$$ senior job ads when they had a problem they couldn’t solve in house, then picked interviewees’ brains without hiring them.
I would gladly take that experience over "yet another minesweeper something" or its more evil friend "reimplement some esoteric algorithm no one uses in their day job". I mean, sure, fake jobs are always evil but if you're gonna have a fake job at least make it produce something for humanity
The back side of that coin is: how catastrophically dumb must they be to have a problem that a stranger can solve on a whiteboard in an hour but your whole organization can't in a sprint?
I think a lot of companies are kind of realising the tech stack they use has a bigger impact on hiring than salaries. I believe banks are encountering this issue with no one wanting to do C++ anymore.
You'd find a lot of talented C++ engineers for the right mission and culture.
The problem you describe has little to do with C++ and a lot to do with banking.
The banks just don't pay enough. Quant finance firms in Chicago and wall street don't have this problem.
I am not sure you understand the problem. Your first sentence hints that you know that there needs to be other things than tech stack and salary to find talented C++ programmers. But the second sentence pretends like you didn't write the first sentence.
I said tech stack affects hiring more than salary. I didn't say there is a lack of C++ programmers. I was very explicit about my statement.
Have done consulting with banks as customers, I definitly wouldn't want to work for one, regardless of the tech stack, and money being offered.
This is what OP was hinting at.
OP was ignoring the point and basically implied the reason banks have issues hiring these days is because they're banks. While in the past they didn't have these issues. Why? Because tech stack matters for a lot of people.
They always had these issues, I barely know anyone that freely replied to job interviews for a bank, given the work environment, as I am approaching 50y, have already seen quite a lot in consulting projects.
They had the same problems everyone had. There are more jobs than programmers to do the jobs. But now they've got the added problem of Rust, Go, etc taking over.
You weren't all that explicit, and GP responded to your comment as written. There really is no call for being this rude just because you think you were misunderstood.
1. I explicitly wrote that people care more about tech stack than salary. Then gave an example where an industry has that problem. The response was about if you have other attributes you can find someone. Fundamentally ignoring the point.
2. Rude? The person who replied did what was said. The first sentence implied that my point was indeed correct. Then the second sentence just ignored what the first sentence implied and ignored the point. They seemed to think the problem is a long-standing problem that banks have. Instead of a problem that has been growing for years because the supply of people who know the tech stack is decreasing. It's fair to point out to people you don't think they understand the problem.
3. Misunderstood? I believe they implied in their first sentence I was correct and that they understood the point. They just didn't like the point.
The next 15-20 years are going to be entertaining as the world finally runs out of COBOL developers.
It’s not really that hard to make new ones.
It'd probably require expensive on-the-job training, which is well out of fashion. Sure, folks could teach themselves COBOL in the hopes they might maybe get hired by a bank, but they'd be better off spending that time learning a language with broader industry interest.
AI I will probably help in transitioning developers from other languages into understanding cobol code bases.
I guess with C++ you either work for a bank or you do video games. Guess which one people prefer?
Definitely banks! Much better pay (at least in investment banks) and way less stressful.
Better pay sure, less stressful, not the ones I had as customers.
And you better like to come in a proper suit to work, and talk to your work colleges in formal language, regardless of how many years you happen to have worked together.
Or you move over to Go or Rust. Just like Perl programmers moved over to PHP, Python, and Ruby.
It seems crazy that in a community like this, people seem to ignore the fact that people move on to the shiny new tech. And those aren't even that new anymore. It feels like same as how Perl programmers acted in 15 years ago when PHP and Python were eating up all the new projects.
Banks of course.
Game dev dont pay.
They don't pay very well. I can't imagine the median in amsterdam is very good if that really was 50% higher
Maybe I just negotiated well in a good time to negotiate? But my teammates salaries were sometimes even better
90k top Amsterdam, 135k top at booking, and saw even higher than that for the same position
Were you a contractor or did you have an actual employment contract?
The founder of Fastly was a Perl release maintainer and core author as well iirc.
At least for a while they had quite a bunch of core perl people on their payroll
They used to donate something like 100k/year, had a handful of core and library developers on payroll, and hundreds of devs occasionally contributing code.
https://hakai.org uses quite a bit of perl in its various projects! The CTO is very adept with it (really nice guy, too).
And that's the flaw of the open source business model.
You develop something for free, make it available to everyone for free, allow them to modify use and misuse as they wish. Every single step is your conscious decision.
And then, you beg for donations, and complain that people are not donating?
Doesn't make sense. If you don't want to work for free, just charge for it.
If it was a business model then people would charge, but it’s not a business model it’s an ideal that leads to a common good.
There are parallels to funding education and scholarship programs in public universities. Corporations often rely on human resources around office locations and they spend in order to ensure a steady flow of talent development. Funding open source is not that different of an issue. One challenge here is IT/Tech departments are often cost centers that are strictly budget controlled and it’s harder to make a case for non-essential costs like funding open source.
Open source is not a business model.
Perl was created by someone in their spare time away from their day job.
When he needed money he just wrote books and charged for those. Ironically the publisher of those books hired him to continue working on the _language_, and of course, write more books.
Makes total sense.
nah, it was created for their day job in order to provide reliable quick to write code under difficult conditions
I meant the company did not participate in it's creation nor did they fund it in any way. If they had they certainly would not have approved of it being released under an open source license. Also Perl 1.0 was released using Larry's NASA email address and not any other corporate one.
I believe it was NSA not NASA - in his hubristic style larry wall described perl as being born from "a secret project in a secret laboratory".
I'd say the biggest influence on my programming work is recognising how to use that style of humour can help deal with situations that can sometimes get to quite high pressure - e.g. "please rescue this failing 9 month long $x^e6 project before it goes live in the next fortnight"
Free software is more than just a business model.
Cygnus, Red Hat, MySQL, JBoss etc. all had successful business models.
Android, React and other projects come from companies with mixed business models, but they have had success as well - there are billions of active Android phones, and many web sites running React.
Some open source companies did not do well, but lots of closed source companies do not do well either.
Also, open source is not just a business model - sometimes people just give software they wrote away.
I think it's fair to point out that there are two distinct open source models in play here;
There's the "old school" open source, which releases product for the common good. Think Linux, Gnu, Emacs etc. This group would object to the term "business model" since they are explicitly not "businesses".
The second group are commercial products, from commercial companies who wish to leverage some aspect of Open Source to further their commercial ambitions. Think (pretty much) any VC funded "Open source" product. I 100% agree with you in this context.
The latter group (sooner or later) discover that cloud providers will happily offer their product as a service, exactly how their OSS license permits. They are well positioned to extract value from the offering, and thus charge for it.
So yeah, you'll see these companies pivot to a proprietary license - but honestly I don't mind when they do - for them, being OSS was transactional in the first place do it was never going to last forever.
Yeah, I've never thought it compulsory to reimburse for any open source software. Some projects are "lucky" enough to have large corporate contributors/stewards, and others are projects of passion.
Maintenance activities (bug reports, feature additions, participation in community discussions, etc.) should be considered a form of "paying" for OSS - you're giving back and improving the ecosystem. I've done plenty of that for various projects; it's something that I enjoy doing.
It is not "compulsory", but not doing it is extremely short-sighted, like the equivalent of failing the marshmallow test in a collective scale.
[flagged]
Short "Exactly true", "Yes", "I agree" or "+1" comments add little to a discussion and I see those regularly downvoted.
I was referring to the comment I replied to being downvoted. That being said, I agree with you, my point still stands though.
It says a lot about how threatened these companies must be: AT&T claims to be profitable, but their infrastructure investment is focused entirely on obstructing competitors. Craigslist used to be a star, but they must be under severe pressure to avoid collapse to have withdrawn ecosystem donations. It says a lot about the fragility of DuckDuckGo that this is all they could commit to Perl, which is really unfortunate; they could have been excellent, but instead their star is apparently diminishing. Oh well.
I am fully with you, although in AT&T's case they already offered UNIX, Plan 9, Inferno, C and C++ to the world, so maybe that excuses them at the FOSS crowd eyes?
Lets forget about that lawsuit, and trying to take a certain book out of print. /s
Craigslist was purchased by ebay in 2004, which is what happened.
Ebay bought a 25% stake, which it later sold back to them, so only sort of.
A: This is great! Perl is much maligned but a fantastic Swiss army chainsaw and still runs so much critical infrastructure.
B: I find it concerning that $25k is a notable donation; is the Foundation doing that poorly? I would have hoped this number to have two more digits in it for it to be a front page worthy item.
I'm surprised to learn that Perl is still used. Obviously there will always be legacy code to maintain but these days I can't even remember the last time Perl was mentioned in casual conversation amongst my peers unless we're sharing war stories from the 90s.
These days when we find ourselves needing to write a script our first go-to would be bash, and if we need more features or if it's going to be complex enough to have to worry about maintenance costs we'd probably reach for python.
TIL that there is a non-profit foundation that focuses, in part, on supporting Perl. That surprises me to the same extent that I would be surprised to learn that there is a foundation aimed at supporting VB6 (though now watch someone is going to share that there is).
> I'm surprised to learn that Perl is still used.
For this year's London Perl & Raku workshop I shortlisted 70 companies to look for sponsorship. That was with minimal research and effort. These ranged from long term ("legacy") users of Perl to startups. From small companies to very large and profitable fintechs. I cover this briefly in the talk I gave at the end of the workshop: https://www.youtube.com/watch?v=el7qHRpEDeE
Yes, there is far less Perl than there was 20 years ago. But Perl was everywhere at one point, and the halflife of programming languages is long so it's still in a lot of places. Programming languages don't die, they just stop being talked about in favour of the shiny new ones.
> Programming languages don't die, they just stop being talked about in favour of the shiny new ones.
You're largely preaching to the choir, I don't disagree with anything you said.
As a web application developer who got started professionally in the 1990s, I not only vividly remember Perl being everywhere, I actively wrote a lot of it.
However, in my more recent experience, it is more likely to hear people talk about COBOL, FORTRAN or C++ than it is to discuss Perl. All of those languages predate Perl.
Java also still gets a ton of discussion and it's not shiny and new anymore.
Most of us who spent time writing and maintaining Perl in the 1990s were all too willing to abandon it in favour of other languages with similar features, not because they were shiny and new but because of major pain points with Perl (it earned the meme that it's a write-only language). In my opinion, Perl's greatest contribution and staying power was it's regex engine and syntax which persists.
I don't even like python, for what it's worth, but it's popular for more reasons than it just being "shiny and new" (to the extent that you can even say that about python these days).
I don't disagree with anything you've said either, in fact I've blogged about this at length: http://leejo.github.io/2017/12/17/tpc_and_the_end_of_languag...
My main issue is that "People still use Perl?" has essentially become a meme at this point. I'm relatively sure that any sufficiently commented on or upvoted thread on HN gets that statement in it somewhere.
Yes, Perl is still used. Extensively. People and companies just don't talk about it. That's the problem with Perl these days.
(Personally I think TAP and CPAN were Perl's greatest contributions, as I was never a heavy user of regexp).
> People and companies just don't talk about it.
Why not?
> Why not?
I don't know. I could speculate:
There's an argument to be had that Perl's strong backwards compatibility has meant it has sat there working in the background for years (decades in some cases). And, as most of us know, when tech "just works" it doesn't get talked about.I think that all makes sense. I would perhaps as an outside observer also lay the blame at Perl's feet - with Perl 6 the momentum seemed to crash completely over a decade or so.
Last company used Perl but we didn't talk about it because it was all frozen. If anyone ever considered touching it for more than 2 hours, it was likely to get rewritten into Python/Powershell. Last perl thing I had touched, entire repo hadn't seen a commit for 4 years until mine.
I think the lack of discussion of perl is in part because from a bird's eye view, python and perl do exactly the same stuff in exactly the same way, but python has the mindshare. Because of perl's depth and flexibility, for the average developer team it can be really hard to manage.
There's a similar story around javascript - note how es6(?) introduced `"use strict"`. Old school javascript always struck me as a bit like crippled perl with really good vendor support.
Most of my coworkers above age 45 still use Perl.
I am constantly parsing reports and then generating commands to run from that. I learned Perl in the 90's and it still works great for that.
I have to code in Tcl for most of our EDA tools (chip design) but I still parse reports in Perl. The younger engineers use Python and I've learned enough but I really don't care. I'm not writing big systems or anything in Perl or Python. It's the Tcl code that has tens of thousands of lines because that is what the tools require.
I was about to say, Hey, I use Perl, but then I saw this posting with the over 45 qualification. Yep, that's me (way over).
Honestly, I write about a script a quarter in Perl, but it definitely is handy now and then.
Curious: do you also do script-writing in other languages? And just pull out perl for a subset of problems? Or are most things at the "bigger than a script" level for you?
I'm not here to judge. I still prefer to write my python scripts like it's the 2.7 days... (more effort goes to python "code")
Generally, if the script is more than a one-off, I will write in Python, since all the young seem to know Python, and very few seem to know Perl. There are two recurring jobs that I have not rewritten from Perl, one because "pack" is so handy.
The only other language I use much for scripting is Javascript, or rather Jscript, for our accounting department sometimes needs files munged for integration into Great Plains, and I can count on cscript being on the machine and running such scripts.
>>since all the young seem to know Python
'I know Perl' people != 'I know Python' people
Perl was/is just so powerful, people have used to do all kinds of things that most people probably don't even have idea can be done. Its some what similar to the power of macros in vim/emacs. People(especially young) are often surprised you can just open vim on a ec2 instance and do something in 30 seconds, they were planning to spend hours/days doing using java+bash or something.
I have both seen and done, people build such extreme, big and hard things with Perl and so quickly, that I'm sure somebody without that context would find it hard to imagine. Im sure you can do in Python, anything you can do in Perl. But definitely not in the same time, not the same size and more importantly- not often.
Programming culture has been trading tool power for beginners ease for decades now, and the market is swamped with tools that appeal and work only for beginners not for advanced users.
In its hey days Perl programmers would do things in a weekend, what the neighbouring Java team had 12 people and a year to do. There is a reason so much was built in Perl in those days. But like most things, money increased, people had lots of time and budget to get things done. Beginner tools got used more often. Perl also got its reputation as a hard to use tool around that time.
But honestly I see so much manual drudgery these days. Its irritating to see that as a Perl programmer. There is nothing more sad that watching people do work, that must be done by a program.
You're last line is why Larry Wall made Perl. I feel you!
Do most of them even "know python" or just the crudest parts of python?
I'm not sure how to answer that. Some can write a short, personally useful script. Some can do much more. Which are the crudest parts of Python, and which are less or not at all crude?
Languages have deep features. That's why people create new ones (except for PHP perhaps). You can write BASIC in any language you want, it's still BASIC.
Languages systems or environments have still other deep features themselves. The library or module systems in Python or Perl or Raku do not work the same.
Being able to write "a short, personally useful script.", is a great start. And does not count as "knowing Python" except for the purpose of inflated resumes. The clichés of complaining about "line noise" or WORN (write once read never) - since the fine article was about Perl - counts specifically as "not having learned Perl".
[dead]
In contrast to other people, I'm fairly young (low 30s) and I use Perl a lot. I've outlined my reasoning before[1] but it boils down to (a) very quick to get going, (b) runs everwhere I care about, (c) great compatibility story, and (d) can scale up to large applications in a pinch.
[1]: https://entropicthoughts.com/why-perl
Practically all Japanese BBS in use today are written in Perl. They are either proprietary CGI scripts or a proprietary fork of an open-source software like WebPatio[0] and Zero-channel Plus[1].
[0] https://www.kent-web.com/bbs/patio.html
[1] https://ja.osdn.net/projects/zerochplus/
DuckDuckGo is written in Perl. As a business decision, it's cheaper to keep Perl working then replace it.
> these days I can't even remember the last time Perl was mentioned in casual conversation amongst my peers
You need better peers
> these days I can't even remember the last time Perl was mentioned in casual conversation amongst my peers
I mean, what's there to talk about? It's there, it works, not an exciting subject. It's like municipal water (if you have it), it's indespensible, but what is there to say about it. (Unless it has stuff in it you don't want)
I did get some flack for writing a perl script for work recently, but I had some rubbish to list, and it does the job quite well.
You'd be surprised to see how much COBOL is still used as well then.
Regarding B: This tracks with what I've observed in this regard, namely that sponsoring by companies just doesn't work well as business model even for projects where you would assume that it should. The incentives are just not working out, and it seems impossible to mobilize even a fraction of the sums for OSS-donations than what companies burn for much less critical aspects of their operation than OSS tools/libraries/components (or waste outright).
Open source is largely a thing because lots of people voluntarily invest (valuable!) time on their own in my opinion (with corporate sponsorship being almost negligible by comparison).
Most big open-source projects are a thing because a companies invest in it. When we rely on people doing it in their free time what we see is unmaintained software.
The entire idea that open source is volunteer work is largely a myth when it comes to popular open source. Even the ones where you think it's volunteer work they do so much during their working hours that either they're lying to their employer or it's sponsored by their employer.
Isn't it both? In particular dependent on the size of the project?
And it's still easy for individuals to at least contribute detailed problem reports even to very large projects. And these are useful. Even when ignored by the lead mafia.
It is mind boggling how much funding there would be for the Gimp/Krita/Inkscape/Penpot developers if every designer gave them 5% of what they give to Adobe.
They kind of suck at asking for donations.
Look at Wikipedia. They are grossly OVER-funded, they have more money they could ever need in fact And they run purely on donations.
I always wanted to donate for Firefox but they don't offer me an option to do so.
Or look at Gimp: https://www.gimp.org/donating/
Not clear call to action. Lot's of confusion options. Not the best marketing.
You are welcome to propose more efficient ways of funding OSS.
This is correct and sad.
Open source would be much better with sustainable funding models. But hard to see how this could happen in SaaS dominated modern world.
We "just" need to flip the narrative. Let's stop talking about "services" that people need to pay for and make FOSS something that people invest so they can (collectively) own later.
People love to shit on crypto, but no other industry got so many small-scale, open source projects that got funded when people have high hopes of making bank from it.
I wonder if we could get people to invest in open source projects that were tied to a short position on the proprietary counterpart.
It would be better off if people stopped using cuckold licenses like MIT, instead of GPL and its various strains.
Indeed. What concerns me is that with the current AI trends, the amount of funding that the Adobes of the world will put into AI for their products will only widen the gap between OSS and proprietary solutions.
I see it as an opportunity. "Libre" models are already matching state-of-the-art models, so it's not like this power will not be available to the OSS developers.
Indeed but adapting the open models to the product costs massive amounts in compute and engineering.
Not sure the oss community can keep up.
Same applies to most open source tools, that many devs use while expecting themselves to be paid.
I usually buy books from most projects I use, do occasional donations to projects when they are relevant enough for my work,...
Here's some details about the foundation's financials - https://blogs.perl.org/users/makoto_nozaki/2024/10/understan...
I don't know the dynamics of this board but does anyone else find it strange that the secretary is digging through public documents to generate a post outlining finances? Is that not what the treasurer should be helping with? Then the treasurer makes a public comment to the post? Feels very strange to me.
Just to clarify, Dan Wright is the former treasurer. He retired from the TPRF board back in 2020 (https://news.perlfoundation.org/post/board_update_tpf_treasu...).
But to answer the bigger question, yes, I think this was a bit weird. I was also on the board for a while, and I think we did not do a good job of reporting on and monitoring financials. This was one of my frustrations with the organization, and part of the reason I stepped down from the board (though there were other, bigger, reasons not related to the board as well).
In fact, I had made the same points as Makoto does in his blog post maybe 1-2 years earlier in a board meeting. We were running a constant deficit and we didn't seem to have a clear plan for what we would do if that continued.
I don't understand why grant expenses surged in 2023 if revenue was going down.
I wish the Perl foundation good luck.
So yeah, they’re doing rough…
Not sure what the path out here is? Seems like either finding deep pockets that care about their work or some new revenue stream, but without the cash to fund it I’m not sure how.
Maybe programmers at companies using Perl get together and raise the issue with management? It is a bargain. Imagine the cost of having to rewrite all that Perl.
Stop doing it for free it the only way, OSS projects that rely on donations almost always do badly economically
ok. say they charge every user or business $100 a year. that would certainly kill off Perl
I’m not saying it’s practical right now, but yea the death of Perl is the only thing that can make it profitable.
Perhaps it was not meant to be a flashy donation but a medium-sized one. It is still an act of good.
My sense is that perl deployment is declining as it's replaced with better tools. What infrastructure is perl running?
I started playing with Ubuntu in 2006. Exploring the system, I'd come across system scripts in perl here and there, but Lennart Poettering has gradually displaced these with unit files that are much easier to read.
These days I may invoke perl occasionally. A few years back I used checkconfig.pl to build a slimmed-down kernel config for an embedded board. I expect it will eventually be phased out of these peripheral utilities.
Perl used to, but I'd say not anymore at this point.
Many of the big Perl names long moved on; CPAN is full of abandoned modules. And the world doesn't sit still.
So as time goes by, there's more and more risk of you finding out that some Perl module you're using no longer works. It may not build because of API changes in the C library, or the API of some web service changed, or there isn't an API at all for some pretty big thing that showed up 3 years ago.
That didn't use to be the case.
> A: This is great! Perl is much maligned but a fantastic Swiss army chainsaw and still runs so much critical infrastructure.
You know, I hear this a lot (especially earlier in my career) but I _never_ ran into any system made in perl, ever. I started my professional career in early ~2010 and have been programming since ~2005.
Maybe they are just very black box-y and I don't even know that the underlying stack is perl?
take a look under the hood for any Linux distro
Plenty of talented developers in Eastern Europe who are $25k or cheaper.
Good luck finding just one talented developer in Eastern Europe willing to work for 25k or cheaper.
Thanks to globalisation, those times are long gone. Any mediocre developer can find a local employer that pays at least that much.
Projects don't often demand full time work. A quarter-time work from an effective developper is a lot of work.
Given the number of private companies that rely on Perl, $25K is in the ballpark of what _each_ of these companies should contribute to the Perl community.
DDG is not responsible for the greed of companies that contribute zero.
I applaude DDG's decision. Their move is pragmatic and a lot more inspiring to the companies out there than day-dreaming of a single company donating 7- or 8-digit to the Perl community (which, frankly, would not be sane either).
Relevant: Zerodha's Floss.fund is giving $1M this year for FOSS projects, and haven't got enough applications. Please apply and share: https://floss.fund/
> FLOSS/fund is dedicated to supporting critical, impactful, and valuable Free/Libre and Open Source projects globally. We give up to $1 million per year to support developers and communities that create and maintain projects, big and small.
I always forget that DDG is written with Perl, even after I emailed yegg a million years ago asking why they used Perl, and he responded back, which was nice of him.
I hear Raku is fun, I haven't used it, but I sort of swore a soft oath that I would never touch Perl again about a decade ago after having to debug some regex magic someone did. I'm assuming that once you get past the "hump", Perl becomes fun?
Regex and is a separate language used by many tools, Perl just made it nicely integrated into the language, and also made some nice enhancements. Don’t blame issues with regex on Perl.
It s just a lang like any other. Even ASM you can write fairly easily if you do it for years. Raku is quite damn cool, you should check it out a bit. As felix[1] said, it realy is something like bash and python having a cool cousin.
[1] https://felix-knorr.net/posts/2023-06-24-raku-is-awesome.htm...
Wasn't the original benefit of Perl that it was fairly close to a standard tool, i.e. it was available on pretty much any server you would be pushing a script to anyways?
Raku doesn't seem to have the same ubiquity, while Python is generally available on any system, or even Perl5 is still widely available on pretty much any system. I'd love to start using Raku more but it seems like a hard sell over Python or Bash
Raku is Perl on steroids "basically". It is still pretty slow the last I read something on it. I always enjoyed Perl even as a beginner.
Perl and Raku are grouped together today primarily for historical reasons. Yes, Raku started as Perl 6 and is certainly a Perl-inspired language, but the rename happened precisely because it is so different.
Regarding regexes, Raku introduces a whole new syntax, makes whitespace non-meaningful by default, and allows regexes to be named and then composed/reused. Those three changes, along with helpful modules like Grammar::Tracer, make reading and writing regexes a totally different experience. It's still going to look like noise at first, of course, but even then the syntax parallels normal code far better than PCREs, so you're more likely to make a correct guess about what something means.
raku is amazing. It's perl to the power of perl. Which is why I adopted it. I used perl for its power and expressiveness, and for its layering (never having to learn the entire language at once: one feature at a time is fine). Raku does not disappoint and is a stellar successor (and I'll never know the whole thing :-).
Regarding your oath, it's been 10 years and perhaps you are better now at learning language features. Raku's documentation is very good ... but a very different format that perl. And raku doubled down on regex documentation and structuring ideas (which are completely applicable to refactoring somebody else's regex). And the usual forums are excellent at helping with raku questions.
> [...] asking why they used Perl, and he responded back, which was nice of him.
Do you still know what the reason was?
I actually still have the email.
Here's what I sent:
Here was his response:Amazing, thanks for sharing!
What year was this? (I'm Curious, as you mentioned 2012 was the last year you used at the time of the E-Mail)
It's actually more recent than I thought, looks like it was 2018. I would have sworn it was earlier but I can see the "sent" timestamp on ProtonMail.
2018 is still a long time ago, so that's totally understandable haha
Thank you!
Always makes me laugh when I read things like "2018 is still a long time ago" (no offense or downvote). But also the very thing that perl fought against. Your programming is not going to break for a long time (much longer than 6 years) because there is no reason for language features to change that quickly - certainly compsci theory does not change anywhere that fast.
It takes time to build very large projects like a large, layered programming language, and it should be normal to take many years to learn all the features of something like perl or raku. Because there should be no reason to do it all at once rather than be productive in the meantime.
So anyway, 6 years should not be much in the career of a programming language.
This reminds me of Evan Czaplicki's great talk where he basically traces the funding of most modern programming languages to search engine revenues :-) https://youtu.be/XZ3w_jec1v8?si=zdL6v9P8LnT7Cbal
Wonders why raku is not really mentioned in the discussion?
Then I remembered my daily mantra:
So, I detect some natural frustration within and without the community. Keep the faith. We have a new audience, they value truth and beauty, and a story of battling the odds. They need this TECHNOLOGY. It is [perl6 | raku] – who cares. It may have to start in academia, it may have to start in the p5 stalwarts. It will ignite. Finish the journey. Do not deny your heritage.OT: Craigslist is also built on Perl and hired Larry Wall (creator) years ago.
https://news.ycombinator.com/item?id=14345022
As a duckduckgo user, I think this is great. FWIW, Perl is still on my list to learn :)
edit: fixed spelling
Perl is maybe the most enjoyable language I've ever coded in up until I'm forced to read someone else's code which is always hellish.
Most of the someone else's I have read has been in stuff from CPAN, and I recall it as pretty good. I have written some pretty bad Perl, and wish that I had encountered the O'Reilly Perl Best Practices long before I did.
Perl's "layering" is one of its most brilliant features. You start learning Perl in layers; achieve some fluency and effectiveness and understanding of the general principles - and will still have many layers and sets of features that you can dig into as you progress. The set of O'Reilly books was amazing for this. Still is. But the documentation itself was amazing also. Still is. That's one problem with Raku: Can raku ever get to this level?
This is important as a powerful tool for a powerful programmer.
I always contrast this to C++ - where you are dangerous, too dangerous, until you have learned a huge amount "of the language" (and good luck understanding it). Or BASIC, where... there isn't much.
As a perl programmer from decades past (I transitioned to Java during the perl 6 winter), I've been finding that groovy and even more recently scala are really nice tools for what I'd have traditionally done in perl.
When doing this year's advent of code, some of the terseness of symbols reminded me of perl.
Perl lost me and I transitioned too far away from its ecosystem professionally to return for more than a dalliance or occasional debugging ( https://news.ycombinator.com/item?id=16219876 ).
One of my impressions as a Scala newbie coming from a perl background years ago was that Scala practitioners' culture in a corporate setting tended to end up with code bases that reminded me of corporate perl code bases - suffering from "theres more than one way to do it" disease. A bit too easy to be obscure for me to use/recommend it since then despite the nice typing, actors, lazy evaluation, etc. Not sure if this TMTOWTDI Scala resonates with others knowing both or not...
https://news.ycombinator.com/item?id=6959326
> Scala feels like the Perl of the modern era: there is more than one way to do it. There is value in that mode of thinking, and Perl is a better language than people give it credit for.
https://news.ycombinator.com/item?id=2603425
> This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.
---
The question of company dialects for various languages comes up occasionally. You can see it with people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
I suspect that flexibility is similar to what is seen in perl, ruby, scala, and groovy.
The TMTOWTDI Scala exists... but I want to say that it is more a reflection of the power of the language (drawing from their LISP heritage). It becomes then a question of how much does the company impose a consistent way of doing it within the company (compare the different company dialects).
> people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
Which people, where? Do you have a URL to a discussion?
I've not seen heard or read such talk almost 25 years of being involved in open source Lisp. Needless to say, I've often seen such narrative repeated by programmers not working in Lisp, who heard it from such others.
Someone talking about any industry work in Lisp whatsoever, even just one job, from any angle, is extremely rare.
It's a browsing about https://wiki.c2.com/?WhyWeHateLisp
And that does get into the "25 years ago" area. Really neat place to browse and see as a historical record of discussion from back then.
The issue is that languages that allow/encourage writing domain specific languages within the environment leads to people doing exactly that - writing a DSL that is then used in that company.
Lisp, Ruby, Groovy, Raku (possible in perl 5 as demonstrated by https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L... )...
These languages (and Scala too) allow for writing a dialect of the language that differs substantially from the main language.
I've seen it in ruby. I've personally done it in groovy (wrote categories to make certain reports easier to write)... twice (also wrote a DSL in groovy that matches the script used as input for powershell doing ftp so that instead of `ftp.ps1 script` it looked like "add this import to the top of the script and do `groovy script`")... for that matter gradle is a groovy script that has gone well beyond groovy as a DSL.
Just as the problem existed with "having to learn a new LISP dialect" 25 years ago, many times going from languages that allow for such flexibility in how its written from one shop to another have the "having to learn a new {language} dialect" today.
For code that I have to work on with someone else, I believe it is better/easier to work in a language that doesn't allow you to rewrite the language so that when I have to work with yet another person, they don't need to learn a completely different way of doing it from what they knew previously.
My impression of Perl, as someone who wrote two scripts in it twenty years ago and has been on the Internet since the middle-old days, is that it is a language suited to being clever.
This observation is spot on and 100% of the reason why dealing with other people's code is insufferable. After 20 years of coding I can confidently say I'd rather clean out crawlspaces for a living than deal with another "clever" codebase.
> I'm forced to read someone else's code
Which is 85% of the time my own code!
Programming is an individual activity; developing software is a social activity. Current tools and teaching are still biased in favor of the former, resulting in most of our troubles in the latter.
The legend of the 10x programmer certainly didn't do our industry any favors either.
That's why it is called write-only language. Single job scripts, yes. Team work, no.
It's a write-only language.
Write Once Read Never(WORN)
Regardless of its fame, it is a worthy tool on UNIX environments, even nowadays.
It's an absolute technical liability to build anything new in Perl these days.
It's more of a technical liability to write anything new in Python. All of my old perl code still runs fine, all of my python code went unusable since. It's also extremely bloated.
I upgraded to Debian 12 and all of a sudden my Python 3 code is destroyed and I have to jump through hoops to make pip work correctly again for libraries that were already on my machine. I'm leaving for greener pastures as the webdevs have ruined another good scripting language.
Or not.
I could assert the same about C since Morris Worm, and here we are.
Last I heard, DDG used it in production.
As does Booking.com, and plenty of sysadmins.
Another post in the thread mentions ATT; I can confirm that at another large telecom, Perl is still used in quite a few places, and is still being used for some new projects as well.
If you don't mind sharing this info, I'd love to hear about it. :) I'm olaf@perlfoundation.org
I really wish Raku would pick up some steam. A really cool language.
Genuine question: is someone starting projects in Perl/Raku? If yes, what made you choose it?
Good for them. They don't have to but they chose to.
What they have done (perform around 100M searches a day) is phenomenal. Testament to their marketing.
Unfortunately as a search engine, it's still just a skin of another one, with some additional small scale projects attached.
It's slightly surprising that DDG hasn't attempted to become a 'real' search engine, rather than being a meta. At the moment they make a subset of Bing's revenue per search, never mind what Google make.
[flagged]
[flagged]
Do perl support typescript ?
All TypeScript is valid perl if you apply the right regex.