Notices by Jean-Baptiste "JBQ" Quéru (jbqueru@floss.social)

@skinnylatte I don't know whether France has a policy to fight brain drain, but, I have to say, a few weeks eating French food while on vacation in France makes me miss it as I'm back home in Greece.

@RobotDiver @skinnylatte At least I get to live in a place where groceries and restaurants are cheaper than in France, so there's that.

@jonny So, somewhere between "we help," "we advise," and "we watch?"

@foone Amusingly, the same would also happen in C.

First, let's look for bugs:

-ChatGPT picked the wrong start address
-It forgot a parameter to a syscall
-It forgot to clean up the stack after a syscall
-It wrote 16-bit data to some 8-bit hardware registers
-It wrote to 2 registers that don't exist
-It wrote to a ROM address
-It clobbered system variables
-It overwrote its own code
-It stored a variable in a read-only section

Right off the bat, 9 bugs in 16 lines of code, probably 6 of which are crashing.

Now, let's read the comments it put in that code:

-Bogus claim about the TOS start address
-Wrong name for the syscall it used
-Confused between user and supervisor stack (2x)
-Got the meaning of hardware registers wrong (4x)

(3/n)

Finally, let's check for optimization issues, part 1:

-Stores a value that it never uses back.
-Uses CLR to clear a data register when MOVEQ is faster
-Uses long addressing for hardware registers addresses when short addressing is available
-Uses long addressing for low addresses (68k equivalent of the zeropage) when short addressing is available
-Loads an immediate zero into an address register when another register is already zero

(4/n)

And more optimization issues:

-Uses CLR to clear RAM when MOVE is faster, especially in a code location where a register is guaranteed already to contain zero.
-Clears RAM with 16-bit instructions when 32-bit would have been faster and perfectly appropriate (I'm not necessarily expecting MOVEM here or loop unrolling, that's a bit more advanced).

(5/n)

Final score:

16 lines of code (13 net instructions), 9 bugs, 8 inaccurate comments (when I count duplicates), 7 missed optimizations, i.e. 24 total problems.

We're talking about assembly here, which is not a language that is famous for being expressive. It's hard even to comprehend how it is possible to average almost 2 issues per instruction. That's a level of incompetence that's hard to fathom from a human, and that would certainly not pass any interview.

(6/6)

Hahaha, I asked ChatGPT to write a tiny piece of code for me. I had written that code by hand a few days ago, in a few minutes, and it worked the first time I ran it. The ChatGPT version has 13 instructions and 3 directives, i.e. 16 lines of code.

I have to say, the ChatGPT code look credible at first glance, if you don't think about the details involved. The kind that would get a CEO to say "that can replace my coders."

So, let's look at the code. A thread.

(1/6)

Recent discussions about libxml2, and the maintainer's decision to make all bug reports public, remind me of a sitaution I've been in.

For 4 years, 2009-2013, I was the Google Tech Lead for the Open Source aspects of Android.

One of the discussions that came back often was whether Android was truly Open given that its development happened primarily between closed doors.

Back then already, we thought we didn't have good words to talk about that development model.

(1/n)

I don't want to go (yet) into a lengthy discussion about Open Source and Free Software, this'll be for another time.

Here's the deal: by requesting embargoes, reporters of those bugs are requesting that development of libxml2 happen behind closed doors. The exact model that Google used 15 years ago for its Android contributions, that the enthusiast community didn't like (to say the least).

I've been looking for words to define such practices, trying to avoid overloading existing words.

(2/n)

I was about to settle on "secretive" and "transparent" development, wanting to say that libxml2 bug reporters are requesting a secretive development model, while the maintainer instead explicitly chose a transparent development model.

But, then, it hit me: we already have words for those models, and we have had them for decades. We even have a long writing, almost historical at this point, that documents the point.

(3/n)

The Cathedral and the Bazaar.

Yup, we've had those words since 1997.

Essentially, proprietary development is a cathedral model by nature. Therefore, that's what all non-FLOSS corporate development looks like, even when such development relies of Open Source code.

What we're seeing is an attempt by such corporate developers to force a cathedral model onto Open Source maintainers, when we now have long documented evidence that the bazaar model is very credible.

(4/n)

Specifically, Eric Raymond formulates Linus' law "given enough eyeballs, all bugs are shallow."

By trying to lock maintainers into a cathedral, the proprietary industry is depriving those maintainers from the benefits of the bazaar.

How about we use those words again? Let's clarify that some Open Source projects are explicitly part of the Bazaar, and that proprietary developers shouldn't expect to trap maintainers into their Cathedral.

(5/5)

Google AI inventing new physics, where a system using 2500W would consume about 3.5kWh/h.

@Flux I tend to think it's more like "What output would best fool this human into thinking I understood the question and know the answer?"

Fun thing, this is exactly how an incompetent human would behave in a job interview, so I call LLMs "Artificial Incompetence."

Decades ago, I wrote an interpreter for an esoteric programming language, let's call it "bf" (if you know, you know).

At the time, a lot of new programming languages were popping up, and it was very common to compare those languages by comparing the number of lines of code necessary to code a "Hello, World!".

So, I invented bf++ as an extension to bf, where an empty source file would print "Hello, World!" and exit. 0 lines of code. Absolute winner.

(1/2)

As a mentor, a theme I commonly discuss is about goals at work. I summarize my philosophy as "earn or learn" (not my wording). Your job needs to be either making you money from skills you acquired before, or teaching you skills that will make you money in the future. If you can have both at the same time, that's great, but it's not common. If you have neither, look for another job.

(Yes, it's oversimplified, all catchphrases are).