oy

 

via https://pleated-jeans.com/2023/08/16/funny-programing-memes/

programming via ChatGPT part 2

My friend Liz had a text file with website information that needed some sorting (No I'm not making that up) - luckily it was already one line per entry, and a LOOOONG time ago (like the cgi version was from 2005) I made a webapp just for that purpose, and it comes in useful every now and then.

But it is weird that it was Perl CGI and sending information to my server! So I decided to rewrite it in javascript and keep stuff in the browser, and also I decided to try programming via ChatGPT (heh, I did the same thing back in March, appropriately enough a day before I found out I was getting laid off in 3 months.)

And sure enough, this is right up ChtGPT's alley- just a minor variant of well-known programming tropes, not a lot to keep track of.

Here is the result, and for fun, here is the series of prompts I used. You can see me improving the UI as I went along - a pretty good example of the synergy you can get with these pairings. (The confusion ChatGPT in implementing probably spoke to the confusion a user might have using it - replacing behavior modifier checkboxes with different action buttons was a big UX win, and then adding in a "sort on column" feature was nearly effortless on my part.)

• lets make a useful one page webapp - a single HTML page with embedded Javascript. The title of the app is "sortof" which should appear in the title and as an h1 at the top. the line of instructions under that says " A really simple sorting program. Just paste text into the box and it will return all the lines, sorted. All in-browser, no information is sent to the server." Then there is a large text area. Under that is a button labeled "sort". when the button is pressed the content of the text area is split into lines, sorted, and then put back in the text area
• great start. a few changes and improvements:
  * the textarea is showing up a little larger than the screen. Please correct the box model or just make it 90% width or something
  * please add the following checkboxes underneath with options to change the sort:
  --ignore case
  --reverse order
  --don't actually sort (useful for simple reverse sort)
  --remove duplicates
  --random shuffle
• please rewrite but replace the random shuffle checkbox with a second button that does a random shuffle
• the "don't actually sort" checkbox isn't doing what I expected. I want it to still change the order of the lines, but reversing the order of things. lets remove "reverse order" and "don't actually sort" and replace it with a new button "simple reversal" that lives between the other two buttons
• doing great! now before the buttons, on line line, add a checkbox that says "sort on column ____ (delimited by ____)" where the first blank is a short input field for a number and the second blank is a dropdown with comma and tab (defaulting to comma)" when the sort button is hit, it should sort on the appropriate column after breaking each line up by the commas or tabs
• very good! add the following cosmetic features and we are done:
  1. use the default sans-serif font for the whole thing
  2. change the header to kirk.is | tools | sortof v0.5 kirk.is should be a link to https://kirk.is/ tools should be a link to ../tools/
  3. all links should be black 4. add either an extra space or a little padding above the row of buttons 
• oops - please keep links underlined, and actually the link for tools should be ".." not "../tools" (my mistake)
• could you add one more checkboxes with the other ones - sort numerically instead of string compare. this should work for both the normal sort and the sort on column
  

So, yeah. Both cool and alarming. It's totally mindblowing that a "just figure out the most likely sounding thing to say next" LLM can do stuff like this.

Fun fact I learned today: "ChatGPT" spoken aloud sounds a bit like "Kitty, I farted" in French.

LLMs, Emergence, and Programming as Gardening

A great summary of where we are with LLMs and how we got here.
(I love deconstructed power point presentations like this, so much more skimmable than the full on video)

I think the most interesting sentence is:

The fascinating thing is that capabilities of these models emerge at certain sizes and nobody knows why.

I help lead a "Science + Spirituality" group at a local UU church, and one term people who are looking for meaning in our physical world (that isn't bestowed from "outside the system") is "emergence". As systems connect, new behaviors show up that you couldn't have predicted by just looking at the lower levels; atomic physics becomes chemistry becomes biochemistry becomes neurochemistry becomes psychology, but you can't really do much psychology in terms of atoms. But we can find meaning in the emerged and shared experiences all humans go through.

And it's funny; I think one of the most important dichotomies in human understanding is holism vs reductionism. The psychiatrist Iain McGilchrist thinks that's rooted in the two-hemisphere model of the brain but is a split in approach that scales all the way up to the societal level; Robert M. Pirsig's "Zen and the Art of Motorcycle Maintenance" sees it as "classical" vs "romantic" thinking (and finds the resolution of where they meet in Taoism). And as a programmer, I think reductionism had been on the rise for the past few decades (for example - a focus on low level unit-level testing vs functional and integration) but that will be challenged as the industry integrates LLMs more and more into its workflow.

This also all reminds me of "A-Life", which was really big a while back - artificial life simulations, often where small rules were established and then allowed to run rampant and in parallel (Conway's "Game of Life" being the Ur- example of this) I took a class at Tufts' Experimental College in it. One thing my instructor Jeffrey Ventrella (his website ventrella.com has lots of cool stuff) said was that in the future, programming would look less like regular engineering and more like gardening. At the time I could only see that in terms of having a human be the selective, weeding force in evolutionary processes, but now it seems like a pretty good metaphor for the kind of "as much art as science" intuitive skill prompt engineering is right now, like the like I started with talks about; you sort of know how to get the results you want and have a basic idea of how to get there, but it's still full of surprises and you never know where an ugly weed of a hallucination is going to show up.

interesting articles from the firehose

 I'm behind on my email, but I subscribe to a few good newsletters... JavaScript Weekly, TLDR, TLDR Web Dev, Frontend Focus.

I used to ask "how did you find out about technology X?" of some of my more with-it peers, and now that problem is somewhat cracked for me, but replaced by a bit of a firehose of potential things to read.

Anyways, as I play catch up a bit here is a set of links that caught my eye:

5 Inconvenient Truths about TypeScript - I especially am aware of "3", where once you are talking about communicating with systems out of your little TS world, many bets are off, and you may have a false sense of security that that integer you got from the API couldn't possibly be a string, and so you can use the "+" sign freely.. . (I would add a sixth... I find the way Typescript and React wraps the legacy DOM stuff  (HTMLInputElement and events etc)  to be complex and a bit bizantine - when a property slips, the error messages or warnings are super hard to track down, though VS Code tools to reformat the warnings can help)

interesting YCombinator conv on leaning more on what is built into EcmaScript , which might be part of a move away from frameworks, or to lighter weight ones.

node best practices -  lot of quick hits with links to deep dive.

Elon Musk's "X" was on the verge of "dark mode only" - I didn't engage much with Twitter but appreciated its former town square plus communicate with famous people or brands directly option, but now I'm usually there by accident. Still... saying dark mode is "better in every way" is categorically false, since people with astigmatism can find it leaving dancing lines of brightness on their retinas. But it is cool, so it's not surprising that a guy who has been trying to name things "X" for decades was on board.

10 answer templates for tough non-tech interview questions - I wonder if I'm too quick to put my cards on the table in terms of salary...

Understanding React Server Components - I'm slightly wary about Vercel who are really working to be the default host for this stuff. Also lines like "The beauty of RSCs is that you don’t really need to know fully how they work to take advantage of them." I guess that's a better attitude than "the EJB development team will generally consist of 5 people" (or some such) from an EJB book I had back in the day, but there's still this smell of overcomplexity of it all to me. (UPDATE: actually here's a better intro to React Server Components)

I'm betting on HTML - HTML itself is getting more powerful (and even more style-able)

If Web Components are so great, why am I not using them? - spicy takes - snickered at "AMP is just one storyline in The Lost Decade of Web Development"

Tailwind, and the death of web craftsmanship - I feel like I hadn't heard much about Tailwind until this year, but when I did it was in the context of the standard everyone was getting a little bit sick of. And I've seen it listed for some employers, as a nice to have. But after reading this article, it confirms my suspicion about how far folks will go just to avoid plain old CSS. I know I'm a little biased towards stuff that runs in the browser natively, and doesn't require a build, and this kind of thoughtful article reinforces that bias I'm afraid.

making memes as a form of self therapy

It is interesting to think about what the industry thinks its getting, and actually gets, with modern frontend engineering practices. I'd say they are designed for scalability in three directions:

1. scalable deployment (what you might need to put your front end on a bunch of different servers), 
2. scalable teams (this was once the best argument I heard in favor of standardizing on Angular.js despite the poor complexity-to-power ratio it offered; it also offered idioms and paradigms and narrowed the paths for "wheel reinvention" that distributed teams at AOL might go down)
3. maintenance and development across time (this is the temporal version of the second point - where you really want to avoid making too much of your own tangled legacy weirdness in the company repositories so that future teams can understand what you were up to)

Actually it's the cross of one and three that is a hurdle for me - I have several small projects in mind that would actually be useful to me (personally, or porchfests, or street bands I help support) but the monolithic server I usually throw things on is running an older version of linux that is a bit too old for some of the current supportive technologies (node/npm), and my sysadmin mojo has always been middling poor, despite my fluency with the Unix command line. (Also I am nervous of working with my service provider to do what is a potentially fraught upgrade until after Porchfest season.)

Maybe I should lean into prewrapped cloud options like Vercel. I'm shy about the possible costs - most offer free tiers, but A. if a project of mine takes off, I don't know what the cost scaling would be. (For Porchfests, for example, I got smacked with a bill for $600 for a map tile service once porchfest day launched us past the free tier - due diligence might have brought that down to more like $80 with another provider, but I didn't have numbers at that point) and B. for projects I might want to make for myself, now I have to also figure out a new backup strategy for any useful data the project generates (Someone one said (and I wish I could find the quote, this is a very rough paraphrase) that the Internet just has one big trick, getting information onto and off of someone else's server, and most of the apps I'm thinking of are definitely in that mold.)

The paradigm I've been leaning on: a mix of SSR and static front ends (rendered in crusty old PHP) with lightweight libraries and vanilla js, using handrolled NoSQL JSON blob on the file system storage of a monolithic server- actually has scaled really well for me across time (3), has handled the thousands of users crush of various porchfests (1), and while I've generally been lone wolf, I feel like I could teach it some other techie without too much hassle (2).

But anyway.
 

I need to decide where to focus these next few weeks. React seems to be the best overlap of what I have used professionally and what companies are looking for - but I have fumbled on at least one late tech screen, and so I might want to focus on stuff like greatfrontend.com, just getting practice in that mode. Or, I've noticed a lot of companies often want React plus something else, so maybe I need more Udemy-like classes. (Though I need to make sure I can show interviewers value from tutorial-based work.) But I also want to build some real stuff.

In May I made another meme that kind of predicted this:

Sometimes I wonder if I should switch gears and lean into the legacy stuff - like I've never done much PHP professionally, say, and it's super unglamorous and probably pays less, but I suspect there are a lot of places not looking to pivot, or to just gradually modernize their tech stack. Reminds me of COBOL programmers making bank in the late 90s as we built up against Y2K!