Dang, forgot how to write php code

I did some php coding for FileMaker and SQL around 2010 or so. One of my projects was to create a php front end for a FileMaker database to use as a message board.

I thought it was a finished, successful project. I was playing with it yesterday and discovered that although the php front end allows for adding a post to an existing thread (including reply with quote to an existing thread post), it fails when creating an entirely new thread. It does create the thread. It does also save the initial post successfully – it just isn’t linked to the damn thread, the thread ID goes missing.

Oughta be simple enough. It’s just that when I open them up in a text editor, I’m staring at stuff and going “Holy fuck, I used to know what this meant? What does this line do? Why is that there?”

Eek.

Makes me wonder what else I used to know and now can’t do?

Keep at it. At least if you’re anything like me, you’ll find that it may take a while to page the old tape drives back into RAM, but once you do you’ll have no problem. It’s not quite like riding a bike, but the skill isn’t gone forever.

That said, please use something other than PHP :slight_smile: .

And comment, comment, comment! Not just lots of comments, but GOOD comments, that a stranger (like future you) will understand.

Don’t feel too bad. PHP is like that.

And it doesn’t help that there’s a new version of PHP every three weeks or so with substantial changes to the language.

I was going through a section of code a couple of months ago. Nothing was commented, and I was like what was this idiot thinking? And who wrote this crap anyway?

Then I looked at the modification log. It was me. I wrote it.

I just tried out my shorthand. Used it for years and couldn’t even remember how to write “Dear Sir”. All muscle memory is gone but I can still kinda remember how the symbols should flow.

Getting old isn’t for wimps.

BTDT. A humbling experience to be sure.

I think that every programmer has been there, done that at some point or another. The good programmers are the ones who learn from the experience.

It’s coming back to me. "Oh, yeah… the way all of this stuff looks like incomprehensible gibberish? It always did. That feeling of ‘Yeesh WTF am I looking at and what’s it for?’? I actually never became a person who could glance at this stuff and make immediate sense of it. It was always necessary to puzzle through it, and I was always amazed afterwards that I actually got it to do stuff.

But some individual techniques and some necessities and a whole lot of “find shit that does work and regard it as a template for what you’re trying to fix” is coming back to me.

I’ve got an alternative method set up for creating the thread. I can now fetch the thread ID to include it in the post record so the post won’t be an orphan and the thread title won’t be isolated from anything useful.

I vividly remember my frustration at forgetting PL1. I used it for all my computer science courses like Data Structures.

I got a job programming COBOL. A few years later I tried to help a friend on a PL1 project and was quite surprised at how foreign it looked.

I’d have to nearly start from scratch now.

" Dang, forgot how to write php code"

You make that sound like a bad thing.
Programming in what we called ‘write only’ languages was sort of a specialty of mine and I’ve dealt with a bunch of odd ones I never wanted to see again. PHP isn’t the worst, but I didn’t have to write any significant code in it either. I did like coding in some similar languages, Perl was ok, and I liked the interpretive model. Since I was heavily involved in the implementation of the languages I can say that some languages have beauty that is only skin deep.

IMO … Languages that specialize in “quick and dirty” are languages that specialize in creating technical debt.

If I’m doing a truly one-time ETL or data reduction, quick and dirty has pride of place and legitimately so. OTOH, for any other mission, Q&D is simply an attractive nuisance. Do it rightly here & now, or pay me quadruple next year. 400% APR against is a losing proposition for any boss not totally pointy-haired.

And yet we persist in making crap using crap tools.

Speaking as a guy who earned a living writing APL (!1!) at one point

Who here remembers the days when major programs were all written in assembly language – and in the days when every different computer had a radically different programming architecture than every other computer?

My first programming job included maintaining our Fortran compiler, consisting of 400-some pages of entirely unstructured assembly code. It seemed like just about every other line was a conditional jump (not a subroutine jump) to someplace else 50 to 350 pages away.

Hey, if you’re going to have one Assembly program, at least it’s a compiler…

Got it.

Try 500 things, each of which seems like it ought to work. One finally does, and I have no clue why it did and the others didn’t. It’s a day spent on what in my home-territory development environment would be a 2 minute 30 second fix (at least most of the time).

Part of what I find so frustrating about php is probably really an artifact of what’s frustrating about the web. I have data right here on the page, either because the user typed it in into entry fields or because I fetched it from cookies or acquired it via some other process. But now I need to do something (as in “verb” – store the data or display the results of a search or whatever) so I need to call a web URL, and the web is stateless so all the data I have right here vaporizes unless I do cute and clever things to pass it from me to myself so I can again have it on the new freaking web page.

Anyway, I’ve GET’ted and POST’ed and cookied data and stored it in FileMaker and fetched it back out of FileMaker, but things that oughta work don’t, and things that work here don’t work there. I get a dubious comfort from it being reliably repeatable: once I finally get the damn thing working it seems to be working consistently.

This is the paradigm of web programming: Write once, debug everywhere.

Everything was written in Assembly in those days. Even the assembler. If you need to write an assembler because you don’t already have one, and you write it in Assembly, how do you assemble it?

The COBOL compiler was written in Assembler.

There was a major batch-oriented source code editor and manager, all written in Assembler.

One of our local programming staff spent several years on a very special project: He wrote a brand new link-editor, far more featureful than any previous, and he wrote it in FORTRAN ! That was utterly scandalous in those days.

Pascal programmers, on the other hand, have never acknowledged to this day that any Pascal compiler has ever been written, or ever needed to be written, in any language other than Pascal.

C is 50 years old this year. No need for assembly most of the time.

However, I read assembly pretty much every day. Might be running on the CPU, might be on the GPU. I’m used to both.

Even on very limited microcontrollers, it was often easier to write most stuff in C, with just a few small bits of inline assembly (say, to bit-bang a 115k serial port on a 1 Mop/s processor).

I’ve written a lot of code in a lot of languages. But I have to admit, C/C++ is the only “real” language of the lot as far as I’m concerned. It takes more effort, but it is the only language where I know I can get what I want out of it. It’s fast, and the difference increases as you spend more effort. And it doesn’t break when you push on it too hard. Perl, Python, C#, and others all have their uses, but just feel like toys. The power of C/C++ reminds me of Neal Stephenson’s comments about Unix (which are a little out of date these days, but only because the competition got much better):

It is difficult to explain how Unix has earned this respect without going into mind-smashing technical detail. Perhaps the gist of it can be explained by telling a story about drills.

The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in a typical hardware store you may find smaller Milwaukee drills but not the Hole Hawg, which is too powerful and too expensive for homeowners. The Hole Hawg does not have the pistol-like design of a cheap homeowner’s drill. It is a cube of solid metal with a handle sticking out of one face and a chuck mounted in another. The cube contains a disconcertingly potent electric motor. You can hold the handle and operate the trigger with your index finger, but unless you are exceptionally strong you cannot control the weight of the Hole Hawg with one hand; it is a two-hander all the way. In order to fight off the counter-torque of the Hole Hawg you use a separate handle (provided), which you screw into one side of the iron cube or the other depending on whether you are using your left or right hand to operate the trigger. This handle is not a sleek, ergonomically designed item as it would be in a homeowner’s drill. It is simply a foot-long chunk of regular galvanized pipe, threaded on one end, with a black rubber handle on the other. If you lose it, you just go to the local plumbing supply store and buy another chunk of pipe.

During the Eighties I did some construction work. One day, another worker leaned a ladder against the outside of the building that we were putting up, climbed up to the second-story level, and used the Hole Hawg to drill a hole through the exterior wall. At some point, the drill bit caught in the wall. The Hole Hawg, following its one and only imperative, kept going. It spun the worker’s body around like a rag doll, causing him to knock his own ladder down. Fortunately he kept his grip on the Hole Hawg, which remained lodged in the wall, and he simply dangled from it and shouted for help until someone came along and reinstated the ladder.

I myself used a Hole Hawg to drill many holes through studs, which it did as a blender chops cabbage. I also used it to cut a few six-inch-diameter holes through an old lath-and-plaster ceiling. I chucked in a new hole saw, went up to the second story, reached down between the newly installed floor joists, and began to cut through the first-floor ceiling below. Where my homeowner’s drill had labored and whined to spin the huge bit around, and had stalled at the slightest obstruction, the Hole Hawg rotated with the stupid consistency of a spinning planet. When the hole saw seized up, the Hole Hawg spun itself and me around, and crushed one of my hands between the steel pipe handle and a joist, producing a few lacerations, each surrounded by a wide corona of deeply bruised flesh. It also bent the hole saw itself, though not so badly that I couldn’t use it. After a few such run-ins, when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror.

But I never blamed the Hole Hawg; I blamed myself. The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner’s product by a liability-conscious manufacturer. The danger lies not in the machine itself but in the user’s failure to envision the full consequences of the instructions he gives to it.

A smaller tool is dangerous too, but for a completely different reason: it tries to do what you tell it to, and fails in some way that is unpredictable and almost always undesirable. But the Hole Hawg is like the genie of the ancient fairy tales, who carries out his master’s instructions literally and precisely and with unlimited power, often with disastrous, unforeseen consequences.

And that is why nobody really develops modern web apps that way anymore. They all use jQuery or React or whatever the latest data framework hotness is. So they are not GETting and POSTing a page.

Instead a more or less fixed page is fetched just once at the start and it’s full of script that is pushing data back and forth to the server(s) via a different connection(s) in the background, and dynamically rewriting the html and css of the semi-fixed web page to make the browser display the changes wrought by the user’s actions and the resulting modified data.

Now whether any of that is within your capability set is a different question. And whether any of that is compatible with how FileMaker does things is unknown to me. I’ve been out of the business myself far too long to have a useful opinion on the details.

But rest assured a couple generations of devs have already fought that battle and moved beyond the [POST it all back, process it on the server, and return a complete fresh browser page] approach. As you quite correctly say, that approach is a right pain in the ass.