Programmer Humor

Have enough monkeys on a keyboard and eventually they'll write a working program

If it's adding that many lines, it's not refactoring. It's just adding slop.

I've never seen a "refactor" create substantially more lines of code.

+55653

Says everything I need to know about the change.

It is wild that Anthropic decided to go with “Claude”, as in “Claude Shannon”, as in the guy who formally proved that information degrades every time it passes through a channel that can’t represent it in a mathematically reversible way.

If you can’t theoretically produce the original code, given the “refactored” code… congratulations, you have lost information.

Are we going to repeat the same joke for each new model released....

I don’t recall this spell proc-ing while in Albion.

Perfection is achieved, not when there is nothing more to add, but when there is nothing more to take away. — Antoine de Saint-Exupére

+55653, -937? That is not beauty, even if it all "worked".

"What did it cost?"

"The yearly energy consumption of a median household and $1,000"

If the movie Tron were true, or The Matrix, and code was alive and sentient, things like this would be horror on the level of the Star Trek: TMP transporter accident.

Maybe you (the Claude porter) should have written a few requirements and specifications to test to first?

1998 a company bought our software that had been developed (part time, by a single programmer) since 1991, first in C/DOS, then refactored into Borland VCL/C++ in 1997. Buyers declared they would refactor it into MFC/Win 32 because it was "easier to hire good MFC/Win 32 programmers than VCL programmers." So, they went and found two "good MFC programmers." They assessed the job carefully and declared that it should be about 6 weeks to do the port - just a straight copy of the existing funcfionality into the new API - no need to add features or change anything.

3 months later, they hired 2 additional MFC programmers. The new assessment was that they had made "good progress" and would be done in another 2-4 weeks.

3 months after that, they declared that they had big plans for future development of the software, and they were "90% done with the port" but they're going to "build up the team" and they hired another 3 programmers with a position open for what would be the 8th member of the team, but they were "looking for just the right candidate" for that spot.

9 months after starting, I casually asked one of the programmers how the port was going and he said: "we've got about 80% of the original functionality working in the new system, and most of the development is starting to turn toward newly identified business needs." "So, you don't need the other 20% of the original feature set?" "Oh, no, we need that, it's core to the business case, it's just taking time to make it happen in MFC." These were "good programmers" - no turnover, management happy with their efforts.

The original programmer was me, straight out of school, no management or mentor. The spec came from the company owner one feature at a time as ideas hit him I'd basically write them down on an electronic "sticky note" and when it was working to his satisfaction we'd throw that sticky note away, the code was the documentation. Eventually, the industry started requiring documented testing, so we hired an intern from the local college and she made some documents recording her ad-hoc testing of what the owner verbally described to her as the things the software should be doing, but mostly she read the code as her specifications. This was actually state of the art in the 1990s in most places I interacted with.

About 18 months before the 1998 buyers came around, we had another company try to reproduce about 10% of the original program functionality independently as a module in their existing software; this was agreed (insisted by the buyers, actually) to be done without our code to model from - just using our front-end hardware to collect the data. Instead of building a team, they hired a series of programmers, usually in 2s, and they'd usually quit after about 6 months. I think it was the 5th set of 2 programmers there that finally got that feature working.

So, 320 minutes would have been a pretty impressive port effort, but did you really expect the chainsaw to cut the whole forest down and load it onto logging trucks for you?

I wonder, in the "none of it works" area, how many days it would take to write requirements / specifications for what is expected and how long it would take Fable to fix the port to meet all those expectations? Probably quite a bit less than a year for one or two "good developers," I would guess.