Peter Duffy said on Wed, 01 Apr 2026 21:01:31 +0100

>Sorry for the delay in following this up. Comments inline below. I've
>tried to prune down to shorten, and hope I haven't messed up contexts.

Pretty cool post. For brevity I've snipped most of it and given generic
responses. Above all, you post made something click in my mind, namely,
what we have here is a documentation problem.

1. I think from Niklaus Wirth on down to my Santa Monica Community
College (SMC) instructors, to some enlightened people on LinkedIn
and various mailing lists, comes the true and tested idea of small
modules, to do a specific task, with very simple interfaces. These
can be tested absent the rest of the code, and can also be replaced
by test jigs or better modules.

This is relevant in code formed by functional composition, and OOP,
and Functional programs. For some reasons OOP fans seem to screw up
the worst in this regard, but it can be screwed up in any language
and it can be done wonderfully in any language with Jump To
Subroutine and Return From Subroutine commands.

2. Memory mismanagement must be avoided one way or another. Rust and
Ada make memory mismanagement very difficult to do. GNU gcc (as
opposed to 1980's Turbo C, for instance) give enough warnings that
if you solve all the errors and warnings, you've gone a long way
toward preventing memory mismanagement. Setting every variable to
zero or NULL goes a long way in C too. I'm not knowledgeable enough
in functional languages to give suggestions there.

3. Input coming into the program must be sanitized, and output must be
prevented from unintentional leaks of secret or non-need-to-know
data.

4. Error conditions must be handled immediately, but not necessarily
immediately in the correct manner, because when you're in the zone,
the last thing you want to do is stop and write error code,
forgetting your train of thought while you do so. In C assert() is
perfect for this. In some languages you can write a simple "try:" or
equivalent to just abort on exception, and worry about complete
handling later.

Programmers of any level must be tasked with very easy asks to do these
preceding four things. The goal is to build good habits and grab low
hanging fruit, because a lot of code is written stupidly. Anyone using
strcpy() in the 21st century is a clown.

Subdocuments can be written to tell how to achieve these four
preventions in a specific language. This isn't a guild, but it gives us
all a common knowledge set.

If any of us write this, we must warn the reader about the
carpetbaggers who will surely follow us, selling their six sigma black
belt ai-enabled blockchain scrumlet techniques because they can't sell
common sense. This warning helps prevent formation of supply-choking
certs having little correlation to on the job success.



>
[snip the web of trust guild idea]

LinkedIn started as a web of trust, and we all saw how that turned out.

[snip the discussion of certs]

I think every intelligent person knows that certs correlate poorly with
on the job performance, and you and I both said so.

[snip the discussion of management listening to Guild members]

I fear the guilds would be controlled by billionaires, venture
capitalists and private equity bros, which means ordinary excellent
programmers like you and I would pay a fortune to get into the game.
Have you noticed that these days you can't just become a cook, you need
to go through culinary arts school?

>
>>
>> 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.
>>
>
>I got to like perl a lot. For at least 20 years of my IT career, I
>wrote perl code on a daily basis - including some fairly large-scale
>projects (by which I mean upwards of about 5000 lines of code.

[snip]

>IMHO, perl is a great language - provided that one only uses a subset
>of its capabilities.

Ah, but *which* subset? Everyone uses their own. And if one starts
using OOP, doesn't it seem like it invariably turns into volleyball
code, where every class knows details of every other class? This isn't
just Perl OOP, it's a lot of OOP including Javascript. And don't get me
started on the undefined, undefinable "MVC architecture".


> In my case, I aim at writing perl which looks as
>much like C as possible, which means avoiding a lot of the shortcuts
>and "syntactic sugar" which were built into it. By personal preference,
>I avoid the "(statement) if (condition)" syntax - I stick with "if
>(condition) { (statement) }" (I've had too much experience of reading
>perl code written by others, and finding conditions at the end of long
>lines, which totally screwed up my understanding of what the code did).

Sounds so far like you do Perl like I did Perl in the 5 to 8 years I
used Perl.

>I also avoid "unless" like the plague. One of the features which I
>**do** use and love is the ability to construct complex data structures
>of nested anonymous hashes and arrays.

This is wonderful in any language with loosely defined variables. It's
the main way of doing things in Lua.


>I'm also very fond of the way
>that perl does object-orientation.

As you've already written, I'm leery of object orientation. I've found
that it starts out with good intentions, but it's just too easy to
become a zoo. I can't easily read my OOP code in either Perl or Python.
I like your idea of data structures much better.

>One of my criteria has always been
>to write programs which, if I read them several years later, I can
>still understand what they do. The other day, I was reading and (more
>or less) understanding a perl module I wrote about 10 years ago - so
>that box seems to have been ticked.

The preceding paragraph is the gold standard. If you can read it years
later, so can your successor when you move on to a better position.

>
>I came across two books by Damian Conway which I found very useful:
>"Object-Oriented Perl" (also a wonderful introduction to basic perl,
>clarifying many things which seem to be obfuscated in the early
>O'Reilly perl books), and "Perl best practices". Highly recommended.
>He's one of the most lucid writers on programming that I've yet come
>across.

[snip the part about the huge system and failure of the first
programmer]

>> 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?
>>
>
>Potentially long story - I'll endeavour to keep it brief. First
>intention (from about 5 years old) was to go into chemistry, but that
>was scuppered by total failure at maths in secondary school. Went into
>music instead (had played the piano since very young) and eventually
>came out of music college with a mediocre degree, and spent about 10
>years trying to scrape a living from music (eventually playing piano in
>restaurants for 7 years).

Yep, I hear this time and time again. Musicians and bicycle riders.
Much more predictive than any cert.

[snip the remainder of both of our discussions]

Thanks for the great insight!

SteveT

Steve Litt

http://444domains.com