HN user

leejo

2,278 karma

https://leejo.github.io/

Posts97
Comments220
View on HN
leejo.github.io 1mo ago

A World of First Drafts

leejo
18pts2
leejo.github.io 3mo ago

A Survey of the Ticket (Re)Selling Landscape

leejo
3pts1
old.reddit.com 7mo ago

Perl articles are being memory wiped from Wikipedia

leejo
43pts51
leejo.github.io 7mo ago

Saffron Walden 2007 – 2013

leejo
1pts0
www.theguardian.com 8mo ago

A350-1000ULR – Airbus that will fly non-stop from Sydney to London and New York

leejo
4pts1
leejo.github.io 8mo ago

Print Sales, Costs, and Profit: 2025

leejo
2pts0
leejo.github.io 9mo ago

A Survey of the Ticket (Re)Selling Landscape

leejo
1pts0
leejo.github.io 10mo ago

Musings on Generative AI

leejo
14pts1
leejo.github.io 10mo ago

Backgrounds Are Important

leejo
2pts1
leejo.github.io 10mo ago

Google Merchant Center Is a Whiny Pain in the Arse

leejo
4pts0
www.wired.com 11mo ago

Programmers Aren't So Humble Anymore–Maybe Because Nobody Codes in Perl

leejo
5pts0
leejo.github.io 1y ago

Always On, Always Connected, Always Searching, Always Distracted

leejo
61pts6
leejo.github.io 1y ago

A Thousand Tiny Optimisations

leejo
57pts10
leejo.github.io 1y ago

Snowsports and the Normalisation of Deviance

leejo
2pts0
leejo.github.io 1y ago

Limited Editions and Ticket Demand

leejo
1pts0
leejo.github.io 1y ago

Milton Keynes, Saffron Walden, Plan B

leejo
1pts0
leejo.github.io 1y ago

Smashed TVs, Broken Windows, and Cracked Plates

leejo
3pts0
leejo.github.io 1y ago

Stop Using Generative AI for Hero Images

leejo
17pts5
act.yapc.eu 1y ago

London Perl and Raku Workshop 2024 Schedule Now Available

leejo
1pts0
leejo.github.io 1y ago

A Real Life Off-by-One Error

leejo
318pts118
leejo.github.io 2y ago

I Went to FOSDEM

leejo
72pts38
leejo.github.io 2y ago

Print Sales, Costs, and Profit: 2023

leejo
1pts0
leejo.github.io 2y ago

Load Shedding

leejo
2pts1
leejo.github.io 3y ago

I Finally Bought a Scanner

leejo
3pts0
www.lightbluetouchpaper.org 3y ago

The Pre-Play Attack in Real Life (Chip and Pin MIM Fraud)

leejo
2pts0
cphmag.com 3y ago

Thoughts on AI Images: Art, Convincing Nonsense, and Visual Literacy

leejo
1pts0
leejo.github.io 3y ago

Responses to “I Almost Bought a Scanner”

leejo
92pts49
leejo.github.io 3y ago

I almost bought a scanner

leejo
440pts320
leejo.github.io 3y ago

I Bought a Printer

leejo
4pts0
leejo.github.io 3y ago

Starting a New Instagram Account in 2023?

leejo
3pts0

OP could have made this point in a better way without expressing it in a way that isn't true or implying that nationality is by birth. Let's do that having looked at https://www.bfs.admin.ch/bfs/en/home/statistics/population/m...

  * 41% of the permanent resident population aged 15 and over has a migration background
  * 27% of the permanent resident population is not Swiss
  * 22% of the permanent resident population was born outside of Switzerland
Notice the subtle distinction in the phrasing of the second point above and OP's phrasing? OP chose to phrase in a way that was a) wrong, and b) misleading. This has been classic tactics around this vote and others over the years.

Here's some more countries by immigrant background: https://en.wikipedia.org/wiki/List_of_sovereign_states_by_im... # Switzerland is on a par with Austria, Australia, and New Zealand, and way below many other countries that have > 50%.

27% of Swiss residents were born outside the country.

Swiss nationality is not linked to your birth country, it is linked to lineage. There are second, third, (fourth, fifth, sixth?) generation immigrants in Switzerland that are not Swiss. Conversly, there are Swiss nationals that have never set foot in Switzerland.

I've read the issue is that some countries require you to renounce your previous nationality to get citizenship, and people have taken advantage of not needing a British passport by lying about renouncing their British citizenship.

Oh that's an interesting little loophole that might be a[nother] reason. A handful of EU member states disallow dual citizenship, so those taking advantage of "EU and British" might be impacted by this.

There it is, right? Seven days and twenty years, gone. To quote, it is "the slow decline, the emptying out, and the long, long process of forgetting".

Wikipedia's deletion proposals are the online equivalent of putting a small poster on a village noticeboard and being surprised that the entire world doesn't see it.

It's disgraceful.

You're basically reinforcing my arguments - these are the policies, deal with it.

I believe the 7 day deadline to avoid the deletion of 20+ years of history is destructive because most of the people that would be notified of this have long since moved on, no longer care, or are off Wikipedia.

The cursory Googling by those who have the power to delete is also concerning. As stated elsewhere in this discussion, Google hasn't been great for search for a long time.

I'm sorry, but I just don't believe that. As stated below in several other comments, none of this makes sense and the Wikipedia editors hiding behind "this is the policy, you do not get to question it" stinks.

The original user withdrew their deletion suggestion and added the "This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources." banner, sure. Why didn't they just do that in the first place?

Instead they looked at an article that had existed for twenty years, with a comprehensive history of changes, had lots of information, links, and [albeit primary] sources; they did some cursory Googling, then suggested it for deletion - with a deadline of 7 days: https://en.wikipedia.org/w/index.php?title=CPAN&diff=1327587...

Wikipedia literally has its own page to suggest that you don't do that: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence...

Wikipedia's own policies around deletion mean it's easy to delete articles you don't particularly like - if they are old enough they probably lack secondary sources. You can't inform users who would be able to contribute off-Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Canvassing#Stealth_c... which means it's unlikely they will be updated before the deadline passes. Many of these articles were contributed by people who have long moved on, and few of us are paying attention to every possible thing on Wikipedia. Twenty years of history deleted in a week. That's wrong.

This feels like the actions of a newly promoted editor, inexperienced, and eager to start "cleaning up" Wikipedia, which it is damaging. It also feels like the actions of an editor who, when editing another article, saw that the thing they were adding didn't point to what they expected on Wikipedia: https://en.wikipedia.org/w/index.php?title=White_Camel_award... # instead of adding a page to disambiguate, they decided to go on a crusade to purge articles that had existed for twenty years. And because these were mostly articles that predate Wikipedia's sourcing policies, they knew it was likely they would succeed.

As I've stated in one of the talk threads: https://en.wikipedia.org/wiki/User_talk:Left_guide#c-Leejeba... # I'm not particularly concerned about the restoration of some of the articles, instead I'm more concerned about the blunt application of policies that means important reference, history, and culture are being deleted.

The sources is the only part that matters. And they sufficed to keep the CPAN article on site, so the system works.

The system works if the sources remain available, and in an environment predisposed to link rot that can be a problem. Imagine the hypothetical situation of archive.org disappearing overnight? Should we then delete all pages with it as their sole source if they're not updated within a week?

And the system works if intentions are pure - it seems here the user that suggested the deletion of several Perl related pages is a fan of film festivals[1] and clearly wasn't happy that the "White Camel Award" is a Perl award, since the late 90s, and not a film festival award (since the early 00s). At least according to Google. So they went on a bit of a rampage against Perl articles on Wikipedia.

You could argue "editor doing their job", but I would argue "conflict of interest".

[1] https://en.wikipedia.org/w/index.php?title=Sahara_Internatio... # amongst many in their edit history

Why is the deletion (or even deletion proposal) regarded as such a heinous act that people feel the need to attack and bully others?

FWIW I don't see this as an attack (with, perhaps, the exception of a couple of comments in the linked thread) and posted the link to the reddit thread as I see it more as an interesting observation around the myriad issues facing "legacy" languages and communities. To wit:

* Google appears to be canon for finding secondary sources, according to the various arguments in the deletion proposals, yet we're all aware of how abysmal Google's search has been for a while now.

* What's the future of this policy given the fractured nature of the web these days, walled gardens, and now LLMs?

* An article's history appears to be irrelevant in the deletion discussion: the CPAN page (now kept) had 24 years of history on Wikipedia, with dozens of sources, yet was nominated for deletion.

* Link rot is pervasive, we all knew this, but just how much of Wikipedia is being held up by the waybackmachine?

* Doesn't this become a negative feedback cycle? Few sources exist, therefore we remove sources, therefore fewer sources exist.

My Xpan is now over 25 years old, and I've been doing stuff like this with it for over a decade: https://www.youtube.com/watch?v=SIy2_IpEw8c # electronics are still holding strong... for now. They tend to have more mechanical problems than electrical problems in my experience. But yes, I certainly wouldn't spend anything like what they are going for these days.

Albert (the subject of the original article here) is a former colleague and I recently visited him at home where he showed me his studio and the cameras he'd been creating. All very cool stuff.

What Killed Perl? 8 months ago

I may blog about this next year, again[^1], as I'm working on a project that sort of covers it - not in a way that will answer the question but more observational.

Anyway, I feel Perl's popularity was hugely exaggerated in the mid to late 90s and early 00s. The alternatives were either not there in terms of language and toolchain features, ease of use, "whipuptitude" or whatever, or library support (CPAN was a killer app), or they were too old school or enterprisey. Sysadmins were using it everywhere so it got into all sorts of systems that other languages couldn't without much more faff.

Its back compatibility meant it stayed in those places for a long time. It's still in a lot of those places.

The fall in popularity the last decade or two was more of a regression to the mean, or perhaps below the mean. Many other languages have come along, which have contributed even more to the fall in share.

Yes, yes, Raku (né Perl 6) but I'd argue that also contributed to a lot of really good stuff on CPAN. The Perl 5 core did get neglected for a number of years, as @autarch says, which may have been a factor.

[^1] previously: https://leejo.github.io/2017/12/17/tpc_and_the_end_of_langua...

Thats a good question. I wonder if the "virtual drum" was there to get over film holding issues (as in it physically bends the film) or that its a line scanner

Both.

personally I think that technology has come on enough to move on from the imacon/hasselblad: https://emulsive.org/articles/opinion/scanning-film-the-20k-...

It's not - the issue that still remains is keeping the film flat, and this is especially problematic with smaller formats. With current solutions you can get the resolution but not the flatness, or you sacrifice something to get the flatness (e.g. ANR glass holders). It's the old glass vs glassless carrier debate, applied to a modern workflow.

I repeat myself: focus, DPI / resolution, dynamic range - these are the solved problems. In fact, modern medium format digital cameras are superior on all these factor. Keeping the film flat, however? Only drum scans and the Imacon "Flextight" solution do this well.

Of course, it depends on what you plan to do with the scans and for 99% of people the solution in the link above is more than good enough.

I've written about this previously https://leejo.github.io/tags/scanning/ # I'm going to add the fourth, and hopefully final, part in a couple of months time.

Chargebacks are extra work for the consumer too you know.

It's not about work it's about the burden of cost due to fraud not being passed on to a consumer such that it could put them in financial difficulty. Chargebacks are there to protect the consumer and not the merchant - The 3d Secure "liability shift" (they literally call it this in the spec) flips that arrangement. Merchants are compelled to reduce their chargeback levels as they have to pay for each chargeback case, and should it become frequent their ability to process payments will be revoked.

Just turn on 3d Secure and your merchant chargeback costs reduce significantly. Nice? Not for the consumer. But I repeat myself.

If we're philosophising, wouldn't it be better to have a honest system where the user authorizes all charges and the merchant doesn't get to auto renew subscriptions without user input just because they feel like it?

Merchants probably should notify their users with subscriptions, sure - I got one a couple of months ago from F1TV that my subscription will renew and maybe I don't want that subscription any more, or perhaps I want to change the level of my subscription. Other merchants won't be as nice, and dark patterns will creep in. Some companies have business models built on these recurring subscriptions.

I can't recall the rules around these, but I can recall that there are (were, we're going back 12 years here) systems in place to reduce issues for recurring payments. Even when a cardholder's details are updated, including replacement of a card and its PAN[1]. Any subscriptions would be retained to avoid interruption to the consumer's subscription, which might be critical for them (the consumer).

[1] https://en.wikipedia.org/wiki/Payment_card_number

Opting out is still customer hostile if you ask me.

That's debatable - I really dislike my own card issuer's implementation as they will ring me, rather than prompt for a OTP, which is a long process and not always convenient. Other card issuers have other implementations. That's one of the, er, issues with the protocol - a lack of consistency. There are many other problems with it.

I'm using this with a credit card, and that already has strong consumer protections if fraud should happen. I, as the consumer, do not get to opt-out of this poorly implemented protocol.

Merchants are sold the protocol with the argument that it reduces chargebacks, i.e. reduces their costs, not that it is good for their consumers. If I (or someone else) makes a payment with my card, and it passes the 3d Secure process, then the chargeback option is a liability that it taken by the issuing bank - and they shift that liability further by passing it on to the card holder: "This transaction when through 3d Secure, your charge back option for it is revoked".

That's hostile to the customer.

Like I said, I have a tonne of material for a blog post. I just need to be bothered to write it.

The "d" in 3d means "domain", so three domains: the merchant, the card issuing bank, and the card scheme(s). The first two have to opt-in to the process for it to be enabled, and most (all?) card issuing banks already have so it's down to the merchant.

Not all merchants will opt-in to 3d Secure as they might see a greater loss in revenue due to the friction it creates versus the risk. They might be taking payments in a low risk sector and use other fraud checking factors, or it might not make sense for them - examples where you end up having to produce the same card in person anyway so "card not present" fraud doesn't factor in so much.

Some merchants don't opt-in as it would lose them millions of dollars of payments an hour due to the friction: Amazon for example.

I worked on the 3d Secure (and, formally, "Verified by Visa") integration at my previous job, and for a long time I was thinking I should write a blog post on what a complete mess of a protocol and implementation it [still] is. Haven't ever gotten around to that though.

My experience with Perl is that often the batteries are rotting.

I think the batteries metaphor was meant to refer to the std lib, or (for Perl) the "CPAN" modules that are part of the core. The Perl core always keeps those batteries charged because they can't do a release if any of those are dead. They even ejected problematic modules, or those that were long since defunct, from the core so they don't have to deal with them. Python went through this exercise as well: https://peps.python.org/pep-0594/

The core Perl devs will also go to great effort to test against the entirety of CPAN ("blead breaks CPAN" testing), but some of those distributions haven't been maintained in decades so they have to draw the line somewhere. Fortunately if it's on CPAN then it's forkable (for the most part) so someone can take up maintenance.

Why not?

I don't know. I could speculate:

  * 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 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).

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.

I'm of the generation that were forced to write with the right even though I was a natural lefty. I also broke my left arm when I was 2, which may have made things even more messed up. These days I:

  * Write with my right, my left is not quite as quick/tidy as my right
  * Swing/grip with my left (cricket / golf / etc)
  * Use my phone with my left
  * Mouse with my right
  * Cut (scissors) with my right (but we don't have any lefty scissors so...)
  * Drink a pint with my left
  * Play guitar with my right (but i learnt with a RH acoustic, so...)