Peter Duffy said on Sun, 29 Mar 2026 15:07:21 +0100

>On Sat, 2026-03-28 at 02:41 -0400, Steve Litt wrote:
>> Peter Duffy said on Fri, 27 Mar 2026 12:26:24 +0000
>>
[snip]
>>
>> We could debate the benefits and costs of adherence to this degree of
>> diligence, but the fact is that a lot of bad code gets written,
>> damaging society and the programming profession. 
>
>Absolutely agree. I'd argue that what I'd like to see - a kind of
>"guild" for IT workers, regulating both skills/experience and
>remuneration/working conditions - could potentially raise both the
>general quality of the code, and the status of the programmers.

If such a thing existed in the early/mid 1980's, I'd have never been
able to become a professional programmer. I didn't have an "Uncle
George" in the union (whoops, I mean guild).

Today we have hundreds of "certs". How well do they correlate to
performance? Not well at all. But they sure do make money for the guys
handing out the certs and the guys with the money to buy one.

Hey, I have nothing against unions. During the Great Depression, my
aunts worked in a sweatshop and came home barfing paint every night.
That factory sorely needed a union.

But there has to be something available for us guys who don't have an
"in" with the guild, so we don't need to spend 4 years and six figures
on a college education just to do something most often done well by
musicians and bicycle riders.

>So that
>if they believed that a program or system wasn't yet fit to be rolled
>out and needed further testing, management would respect their views
>and comply with their wishes. (As opposed to: "What part of: 'it's
>going to be rolled out tomorrow' don't you understand?")

Do you REALLY think management would listen more to a guild programmer
than today's regular programmer?

>Anecdote. Round about 1997, I was helping to set up an ISP from
>scratch. I was initially tasked with setting up the authentication
>system. Another guy was given the job of writing the signup system. He
>had joined as a project manager, but had unfortunately let it slip that
>he had some experience in coding in perl, and at that point, the signup
>facility was seen as a trivial challenge.

Perl is the poster child for mistake encouraging languages. I
understand that in 1997 Ruby, Lua and Python were basically unknown, so
for high productivity your choices were Perl, Perl or Perl, but it's a
nasty language for doing anything beyond a little file manipulation. I
know this because I used it professionally around the time you're
discussing.

>The deadline for the rollout
>was approaching, and this guy was under increasing pressure to deliver.
>Finally the day came. The signup system immediately fell over, and the
>author hadn't a clue what was wrong or how to fix it. I can still
>remember his look of petrified panic, as he stared at the code, with
>the MD literally breathing down his neck.

My analysis: The guy was an idiot. Even with Perl, there are ways of
building for modularity, modification and debugging, as your story
reveals later. What kind of fool wouldn't build individually testable
modules?

>Finally, it was acknowledged
>that his code just wasn't going to work, and he was fired. (I'm still
>amazed that he didn't take the company to a tribunal, on the basis that
>his job description didn't include software development.)
>
>Then - given that I was setting up the authentication system, and had
>considerable experience with perl - the entire mess was dropped in my
>lap!

[snip]

>The day came when my signup system was going to be tested. Even now, I
>start to shake when I think about it. One of the defensive things that
>I'd done was to incorporate paranoid error checking

Can I assume that "use strict" was part of that paranoid error
checking? Without "use strict", Perl is a monster.

> and logging, so
>that I could see the progress of the code virtually line by line. We
>fired the starting pistol. The signup system ran for about 5 minutes,
>then something went wrong: because of the logging, I was able to
>diagnose and fix the problem and get the system up again in less than a
>minute. This time it functioned correctly for about 30 minutes - then
>another problem: again fixed in about a minute. (The problems were
>always caused by misunderstandings about the working of the upstream
>subscription system, which was completely undocumented.) The lengths in
>between the glitches gradually increased, until within a couple of
>days, it was working without a hitch: after that, it continued to run
>virtually without changes for the rest of the time that I was with the
>company - about 8 years. (It was a long time before I stopped worrying
>about it . . . )

You were smart about it, which is why you're on DNG: A belief in
modularity, DIY, maintainability, modifiablity and tight error control.
Which is the point you're making.

Let me ask you this, however: How did you break into the programming
profession in the first place, and would you have been able to do it if
you had a guild hurdle to get over?


>
>> And what in the world do you have against Rust? Yeah, it's harder to
>> get it to compile, but once it compiles it's probably going to do
>> exactly what you intended. Safely.
>
>As far as I know, I've not expressed an opinion about rust. If I have
>inadvertently done so, I shouldn't have, and I apologise. I don't know
>enough about it to express an opinion. I've heard and read other
>opinions, but before I commented, I'd want to read up on the language
>and try it for myself (this is high on my to-do list). My only current
>concern is that it's planned for rust code to be included in the linux
>kernel. I'm worried that the language is very new (for a programming
>language) and the compiler and libraries probably still contain
>significant errors and anomalies.

[snip]

Ah, that clarifies things. Daily I run into Rust fanboiz and Rust
haters, and wonder how the hell do they arrive at such extreme opinions.

My understanding, and I hope it's an accurate one, is that any kernel
migration to Rust will be a program at a time, with lots of attention
paid to any bugs or exploits that might pop up.

A wholesale conversion from C to Rust or any other language would be
stupid in 2026, and I hope that's not what happens. As far as the
kernel, I'd hope they start by writing new drivers in Rust, so they're
not fixing what works. I'd hope the transition would be slow, and could
be stopped and backed out of if it turns out to be unduly problematic.

Oh, and Kevin Chadwick: Everything I say about Rust applies to Ada too.
The only place Rust outperforms Ada is in the quality of its error and
warning messages.

SteveT

Steve Litt

http://444domains.com