I had recently been given the opportunity to puzzle on a form whose inputs and outputs were AI-generated. Yes, yes, this goes into the joke that AI is replacing software with something worse, but there are advantages to creating such a form:
<ol>
<li>
The LLM can convert prose to other metrics. For example, if I want a number, the LLM knows "thirty" is 30. If I want a boolean, "yeah", "yes", "yup" are true. I could look for these specific words in code, which would be faster, but it wouldn't guarantee I am preserving the original sentiment of the sentence. (Not that an LLM guarantees that either, but let's move on.)
</li>
<li>
The bot can answer other questions the user has. For example, if a question is unclear, the bot can clarify it.
</li>
</ol>
So it's not a terrible idea.
The idea was to represent the form as a JSON object and go through the object iteratively. This allowed the form to change if we needed it to.
I decided that the questions should be written by me and not presented by the LLM, as I'll explain later.
For "age", try "30", "thirty", or "fifteen times two". Just works.
For the personal preference questions i.e. "Do you like pineapple on pizza?" a "yeah", "yup", "yes" suffices to record a boolean value.
For these same questions, asking "What is coffee?" or "What is pineapple?" coerces the bot to search through the internet for answers. So this type of form can be useful for clarifying questions.
The response from the LLM was formatted in this way:
<pre><code>interface StringResponse {
 value?: string | null;
 answer?: string;
}

interface NumberResponse {
 value?: number | null;
 answer?: string;
}

interface BooleanResponse {
 value?: boolean | null;
 answer?: string;
}

type Response = StringResponse | NumberResponse | BooleanResponse;
</code></pre>
Paired with the prompt:
<blockquote>
Extract the {string|number|boolean} value from the user's response. This is the question the answer belongs to: {question}. If, instead of answering, the user asks any questions, answer to the best of your ability.
</blockquote>
This is a bit clunky and something I hacked together for interest of time i.e. my boredom. What I really want is a definitive answer from the user, converted to JSON, or a reply that not related to the answer. Of course, with the latter, I give the LLM the tools to misunderstand the user's query, but I'm fairly certain it'll be accurate in most cases.
The ideal place for this code to live is in the server - a session should be created for the user, and the data of that session should be manipulated entirely in the backend. All the server has to do is provide the program's responses, whether informed from the bot or by the programming logic; the client renders the responses and sends the user's answers to the server. A very simple and effective design that does not burden the client. I did not implement the code in this way as I didn't want to mess around with sessions.
The fundamental issue I have with "AI" is that it's really an LLM, a Large Language Model. It works really well for language. It does not understand, unfortunately, any other type of human communication, such as mathematics or logic; these have to be supplemented with external code. This becomes confusing when you realize that the purpose of language is to convey logic. It's a reminder that the LLM knows how to generate words by statistical analysis. Ironically, the LLM itself does not understand the statistics (though, as I read through Carl Sagan's "Dragons of Eden", humanity doesn't really understand the neural networks that comprise our own knowledge).
Thus, people, namely, an audience, or a client, get confused and expect a level of autonomy behind the bot. This is far from the truth. A programmer has to wire the bot's thinking into actual actions. So, really, the bot is just an interface using sentiment analysis. This is hardly the future everyone imagines AI to trumpet forward, but it's certainly an interesting future.
So, no matter how you look at it, you still need the programmer. You still need to break algorithms into clear, explainable pieces of code that represent the domain logic. You could ask the bot to generate code, but it'll use code samples from the internet, which is not vast and computionally expensive at all. In fact, the most common sense thing to do, until the technology is solidified anyway, is to rely on regular ol' user interface technology. A regular HTML form is a happy replacement for our bot, because we have been testing and assuring HTML forms for decades.
As for examples on what I coded specifically, I knew what questions I wanted to ask the client, so I did not allow the bot to innovate. I wrote the code to iterate through the form, again not allowing the bot to figure out where it should go. The bot was only responsible for converting the user's responses to JSON-valid values, and this it was very good at. In fact, while it's typical to pass onto the LLM the context of the entire conversation, I decided to only present the current question being asked as context. Does it need the entire conversation to answer certain questions? Maybe in a different sort of form, where questions are not atomic. But if I needed the bot to make a decision and to use prior language, I could implement this as a conditional statement in the code, choosing to remove now-unnecessary questions from the form, or asking new questions instead, which is the first thing you learn in programming, which is thus the easiest thing for me to do rather than trust the LLM, which means I have talked myself out of this bad decision.
Programming, after all, is to write in logic, and this language is as precise as it can be at the moment, regardless of whether you write in Java or Python or JavaScript. A program is an expression of logic, whether it's an HTML form or a cron job or a sorting algorithm, and so why write a bot to do what a program does in more steps and more labor? But, because logic is so sparse, it hardly captures the richness of life. We must then figure out how to translate the various languages of life, as color, as mathematics, as the English language, into the language of logic. That is what the role of the LLM should be, and that's what special about this technology. Perhaps computer scientists already understand this and I'm preaching to the choir.

I visit the concept of the HTML questionnaire with a twist: I use an LLM to process the responses.

Implementation of a form using an LLM

I wrote this as a thought experiment on how to rewrite the Gang of Four's articles. Observer is one of my favorites and is a favorite of the web's, and fairly simple to wrap one's head around.
<hr>
Given:
<pre><code>interface Subscriber {
 onNotify(event: any): void;
}

class Observer {
 subscribers: Array&#x3C;Subscriber> = [];

 add(subscriber: Subscriber): void {
 this.subscribers = this.subscribers.concat(subscriber);
 }

 remove(subscriber: Subscriber): void {
 this.subscribers = this.subscribers.filter(sub => sub !== subscriber);
 }

 notify(event: any): void {
 this.subscribers.forEach(sub => sub.onNotify(event));
 }
}

class SubscriberA implements Subscriber {
 onNotify(event) {
 console.log(`${event} A!`);
 }
}

class SubscriberB implements Subscriber {
 onNotify(event) {
 console.log(`${event} B!`);
 }
}

const observer = new Observer();

observer.add(new SubscriberA());
observer.add(new SubscriberB());

observer.notify('Hello');
</code></pre>
We observe printed to the console:
<pre><code>Hello A!
Hello B!
</code></pre>
A real-life example:
<pre><code>class SubscriberC implements Subscriber {
 constructor(private element: Element, private greeting: string) {
 }

 onNotify(event) {
 this.render(event);
 }

 render(text: any) {
 this.element.textContent = `${this.greeting}, ${text}!`;
 }
}

// Given an existing document where our script is located...
const observer = new Observer();

observer.add(new SubscriberC(document.getElementById('example1'), 'Hello'));
observer.add(new SubscriberC(document.getElementById('example2'), 'Howdy'));

observer.onNotify('world');
</code></pre>
We observe that the text in two locations on our page has changed to 'Hello, world!' and 'Howdy, world!' This is essentially how popular frameworks as Angular and React work.
<pre><code>class TastyObserver extends Observer {
 notify(event) {
 if (typeof event === 'string' &#x26;&#x26; event.includes('tasty')) {
 super.notify(event);
 }
 }
}

class HungrySubscriber implements Subscriber {
 onNotify(event): void {
 if (typeof event === 'string' &#x26;&#x26; !event.includes('tasty')) {
 throw new Error('I only want to eat tasty things.');
 } else {
 console.log('Yum!');
 }
 }
}

const observer = new TastyObserver();
observer.add(new HungrySubscriber());

observer.notify('tasty sandwich');
observer.notify('nasty pasta');
observer.notify('A ROCK');
</code></pre>
Observe the console printing:
<pre><code>Yum!
</code></pre>
only once.
Furthermore, the code above will not halt the main program flow. This concept is useful for subscribers who require specific data and observers who filter data. (That being said, you should always validate/assert data.) Indeed, this is crucial to the popular global storage package, Redux.
Weaknesses:
<pre><code>class SubscriberD implements Subscriber {
 constructor(private observer: Observer) {}

 onNotify(event) {
 const newEvent = `${event} D!`;
 console.log(newEvent);
 this.observer.onNotify(newEvent);
 }
}

const observer = new Observer();
observer.add(new SubscriberD(observer));

observer.onNotify('Hello');
</code></pre>
We observe the above will cause a stack overflow error. Note this becomes more pernicious based on the complexity of the <code>onNotify</code> method.
<pre><code>class Person {
 pointingAtFeet: boolean;

 pointAtOurFoot(): void {
 this.pointingAtFeet = true;
 }
 shoot(): void {
 if (this.pointingAtFeet) {
 throw new Error('You have shot your own foot.');
 }
 }
}

class SubscriberE implements Subscriber {
 constructor(private person: Person) {}

 onNotify() {
 this.person.pointAtOurFoot();
 }
}

class SubscriberF implements Subscriber {
 constructor(private person: Person) {}

 onNotify() {
 this.person.shoot();
 }
}

const observer = new Observer();

const person = new Person();
observer.add(new SubscriberE(person));
observer.add(new SubscriberF(person));

observer.onNotify();
</code></pre>
Because our observers are called sequentially, we observe that, as a result of <code>SubscriberE</code> being called before <code>SubscriberF</code> (and this is always the case), we have shot our own foot.
<pre><code>class Human {
 currentMeal: string;

 constructor(private satisfyingMeal: string) { }

 isSatisfied(): boolean {
 return this.currentMeal === this.satisfyingMeal;
 }
}

class BurgerHuman extends Human {
 constructor() {
 super('burger');
 }
}

class PizzaHuman extends Human {
 constructor() {
 super('pizza');
 }
}

class SubscriberG implements Subscriber {
 constructor(private humans: Array&#x3C;Human>) {
 }

 onNotify(event) {
 this.humans.forEach(human => human.currentMeal = event);
 }
}

const observer = new Observer();
observer.add(new SubscriberG([ new BurgerHuman(), new PizzaHuman() ]));

// PizzaHuman is not happy.
observer.notify('burger);
// BurgerHuman is not happy.
observer.notify('pizza');
</code></pre>
The observers do not care who they are serving. Therefore, they do not understand the needs of the people subscribing to them. There is no way to make the entire system happy and a better design is needed.
Do not attempt to use concurrency to solve this problem, by attempting to put each observer "on an equal footing". This will cause much, much worse issues.
Observers should work with systems closed from one another. Hence, encapsulation is a hard requirement.
My (personal) thoughts:
I do not advise using the Observer pattern for doing work at the highest level possible i.e. at the very root of a program. By this I mean, if we can imagine a program as a tree of components, with components at the root of the tree being used directly by the client and every leaf used by a higher level component, the Observer pattern should only be used at the lowest levels possible.
The pattern is aptly named, in the sense that we observe the sun is setting or, upon entering the door, the house smelling nice. These are observations. We can change what we are doing (as in the case for night time, I may call delivery) or we can do nothing (the house smelling nice denotes a nice-tasting dinner, which dinner I would have eaten regardless of nice-tasting-ness or not).
It is not wise to make observers observe exceptional events, for exceptional events should be handled exceptionally. I do not observe a bear in my house, for example, because the time I take observing may cost me dearly.
Let's use Amazon as an example. Amazon tracks everything you do on a page. If it sees you linger on an item, it will update its user interface to recommend you more things like that item. This is more-or-less the Observer pattern. This user interface, in the grander scheme of things, is unimportant. It can error out by 1) not updating, 2) showing the wrong product, or 3) not showing anything at all. At its worst, this error may cost Amazon a potential sale.
It would be extremely unwise if product recommendations affected the cart - users being able to see their cart, check out, give Amazon money, etc. That's real, not potential, money being lost. If product recommendations are truly necessary, there needs to be a reconciliation mechanism built that should not be incorporated into an Observer pattern. The Observer pattern should not fix itself by throwing more, quote-unquote "correct", events. Amusingly, I have seen many carts implemented this way.
It's fine to build an emergency mechanism, to warn the observer of its bad data, so long as it is truly for emergencies. The entire system should halt and work on reconciling the emergency rather than moving along while the emergency is being worked through. Then again, the programmer should not throw emergency-causing data into the observer. That is the rub.

Taking a stab at writing about the Observer Pattern, from the Gang of Four's (in)famous Design Patterns.

The Observer Pattern

I have four classics on writing programs: Andrew Hunt and David Thomas's "The Pragmatic Programmer", Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides', otherwise known as the Gang of Four's, "Design Patterns: Elements of Reusable Object-Oriented Software", Fred Brooks' "The Mythical Man-Month: Essays on Software Engineering", and the first volume of Donald Knuth's "The Art of Computer Programming".
"Pragmatic Programmer" is still as useful for my career as it was when I began. It's not a book couched in technical knowledge; the content is merely a repetition of one axiom, "When it comes to software, anything goes." It exhorts the reader to acquire as much technical knowledge as possible in the hopes that it will save their projects, and, failing that, to have the humility to accept inevitable failure and to learn from it. We forget this occasionally, and because we forget this we also forget to add to our and others' banks of knowledge on how to correct our mistakes. This is the history of programming, which is still very new.
I have not gotten too far into Knuth, but I find his writing moving.
"Mythical Man-Month" is a great read, even though many professionals writing software nowadays are unlikely to understand some of Brooks' observations, particularly with scheduling jobs on the OS. Some may not be working for organizations in similar size to the ones Brooks worked for. Some of his data and consequent conclusion seem suspicious. Nevertheless, it poses lots of philosophical arguments on how software should be built, and is worth a lot of thinking over. And Brooks is simply an engaging writer.
"Design Patterns" is useless. Which is odd, as it's considered a classic.
If I had to rank the books in datedness, it would be:
Art of Programming > Pragmatic Programmer > Man-Month > Design Patterns
In terms of usefulness:
Art of Programming > Pragmatic Programmer ~ Man-Month > Design Patterns
In terms of writing quality:
Man-Month ~ Programming ~ Programmer >> Design Patterns
In terms of wordy title:
Programmer > Programming > Man-Month > Design Patterns
To be fair, I'm a web developer. But, to be fair, web applications have only grown in complexity. Fine, fine, perhaps Google's Developer Platform or Amazon Web Services' dashboard are not fair examples, but take one look at, say, the <a href="https://www.nytimes.com/">New York Times' site</a>, Facebook, or the website of your bank of choice. Web devs will beat the drum that the best user experience is a simple one, but, for whatever reason, we're building complex web applications. And we're writing applications with complicated I/O mechanisms. So even if a book is meant for C++ or Java, I do think it is fair for developer of all spades to evaluate it, unless the content, up-front, is about the language or compiler in particular.
In the prologue to Knuth's work, he states: "It should be mentioned immediately that the reader should not expect to read an algorithm as if it were part of a novel; such an attempt would make it pretty difficult to understand what is going on. An algorithm must be seen to be believed, and the best way to learn what an algorithm is all about is to try it." This approach does not help "Design Patterns" at all. I made a serious attempt to write out the code examples in the section "Creational Patterns" and I was struck by the fact that the resulting maze does not work, or results in code smells. An example of the latter comes from the Abstract Factory pattern, where clients can create mazes with bombs. It's a neat idea, but to actually configure which rooms or walls have bombs requires downcasting <code>Wall</code> into <code>BombedWall</code>. If I have to know what walls I'm installing into a maze, what complexity does the pattern save me, then?
The work suffers from logorrhea, or, in simpler terms, the work is rambling. In multiple parts it feels as if the book senses it is losing its audience and so summarizes and justifies what it has just done, which in turn loses the audience all the more.
I want to clarify that I understand the context in which "Design Patterns" was written, but that doesn't protect it from its uselessness. Firstly, as the book reads like a manual, it loses any historical interest. I suppose it's interesting to see what technology and what products were common in the days of the book's writing, but it doesn't go into depth on these topics. Secondly, a frequent defense of the book is that it was useful when certain languages did not support certain features, in which case the obsolescence of the book is all the more poignantly argued. In the same sense we are not interested in the classical elements, we really shouldn't be interested in these over-designed patterns.
My ultimate feeling towards the book is that its main content i.e. the code is described in an inefficient language: English. Code is the best way to describe good code. The worst part of the patterns is that we hide their explicability behind names, really jargon, and the names point to, ugh, more jargon. If we're looking at this in an even deeper way, code should really be described in the language of logic, thus cementing the idea that code is an expression of human thinking. So said Diogenes: <a href="https://en.wikipedia.org/wiki/Zeno&#x27;s_paradoxes#Proposed_solutions">solvitur ambulando</a>, or, "[good software] is solved by walking."
So saying, the issue with "Design Patterns" is in how it arrives at its conclusions - in that it rambles and never gets there - and not in the concept of patterns themselves. <a href="https://www.martinfowler.com/eaaCatalog/">Martin Fowler</a> deals with them in "Catalog of Patterns of Enterprise Application Architecture". Immediately he's got it right because he makes the "Enterprise" part explicit, understanding the solution is tightly coupled with the problem. (What's the solution to the Gordian Knot? If it was made of carbon fibers, a sword wouldn't do.) There are two nice things about his patterns: 1) they're all simple i.e. local, and 2) reading their descriptions is more valuable than knowing their names. The irony of object-oriented programming is that Alan Kay, one of the designers of Smalltack, an early OOP, <a href="http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en">thought it was an efficient way of grouping various calculations together</a>. Nothing more than that.
I shouldn't say "Design Patterns" is entirely useless, because it fulfills an existential purpose: the fact that it exists means you can organize code as encapsulated objects. And indeed it has been useful to me in this way, where I consider deeply whether code should be organized in a class, instead of a namespace or a set of functions. But there's another issue: why object-oriented programming? Why does the programmer need a metaphor to the real world to help make decisions for a digital world? Again, misleads on top of misleads.
A possible solution to the book's problems is to begin each design pattern with a case study and then undergo theoretical considerations - why, when, how of the pattern - in the remainder of the chapter. Indeed, this is the layout of "Pragmatic Programmer". And, in fact, this is how I structure essays. I put a fair amount of thought into writing, despite my asides and over-fondness for wordplay. Everyone can recall a high school English class of their distant memory where it was said that writing begins with the most interesting information and then peters out into specifics, which is also interesting but less so to a general audience. The other reason to structure sections this way is that theory, after all, is theory, and so being unproven should be considered and not followed.
On a final note for this topic, it's neat that <a href="https://refactoring.guru/design-patterns">Refactoring Guru</a> has a page for design patterns, but there is still the issue that the explanation is not in code. At least it has images, which are slightly better than text.
I think others have noted how dangerous these patterns are. As Paul Graham has <a href="http://www.paulgraham.com/icad.html">mentioned</a>, "The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write." Keep in mind the authors of "Design Patterns" exhort their reader to "use [patterns] and look for other patterns that fit the way you design." What they really mean is, Analyze how others code (good advice, BTW), but the fear is that this stinks of confirmation bias: Look at everything as if they are design patterns so that you can confirm that design patterns are indeed real.
Last thought on this essay in general: programmers act occasionally like lawyers. We often deal with language and what words really mean, mostly because we are taking the physical things the words represent and trying to understand their relationships with others. Programmers like to litigate, argue, complain. As I do in this essay. But there's a part of me that thinks we shouldn't encourage this part of our trade. The real fear is that we hand-wave actual complexity as an issue of "semantics" - which means erasing some of the reality the problem actually poses. We're seeing this with AI as we speak now, where the machines being trained don't actually care about the content they are creating and occasionally spreading straight-up lies. So to say: I fear "Design Patterns" is an overly legal book. It's too wordy, for a profession that is usually obsessed with saying the least. It may be wise to refactor "Design Patterns".

A reflection on the Gang of Four's Object-Oriented Design Patterns in the modern world.

Thoughts on the Gang of Four's Design Patterns

<h1>Angular vs. React</h1>
It's probably safe to say that the whole "Angular vs React" debate has been talked to death. It may even be outdated. (As to why Vue doesn't figure into it, I assume it has to do with it having a bit of both, and we'll have to see how Svelte goes.) Nevertheless, I'll add my own thoughts. I'll keep it simple:
If you want to build a website, go with React.
If you want to build something data-heavy, like a complex series of forms or an analytics dashboard, go with Angular.
But, of course, the developer needs to weigh across all aspects of the problem before deciding. (This is where I would put an ambiguous smiley face.)
React is simply faster. By default. People will get lazy and toy around with Angular's change detection settings. When React detects change, it will literally ask you to create a new diff from scratch, which is a lot better for debuggability than Angular's state-based approach.
Then there is the issue of Angular cluttering the UI with meaningless host element tags which, granted, improves code clarity, but does not help for peformance or SEO (as sites can be penalized for particularly thorny DOM trees).
I also find the React eco-system, i.e React, Gatsy, is geared around website building, focused on building fast sites. There's some guarantee that someone else is aware of the problems you're running into with those solutions. Not that Angular lacks server-side/static rendering solutions, but, from my own personal experience, they're finicky. Part of the reason why is that Universal expects you to know how Node Express works, which is not a problem, but is rather frustrating that there's no real out-of-the-box solution. Furthermore, I'm not sure how many people use Universal (SSR) or, for that matter, prerender. Forums for Angular Universal are pretty quiet, which is unnerving.
However, the Angular eco-system is geared around working with data, particularly complex inputs. No wonder, given how complex (and kinda nice) the Google Cloud dashboard is.
The stateful approach works better for forms, in comparison to React's do-it-all-over-again philosophy (I should put that in quotes, given that hooks are one of their cheats). Out of the box, Angular's <code>@Input</code> and <code>@Output</code> decorators are extremely clear as to what they do and how they convey the component's inner state. We're not even talking about other stateful innovations, like the <code>@HostBinding</code> ... bindings. Furthermore, Angular 15 comes with a feature to associate Angular directives (probably one of the smaller pieces of code you'll write for Angular) to components, allowing for reusability. No, seriously, after six years of developing in Angular, this is a great feature and possibly better than the standalone components stuff.
Angular's <code>FormBuilder</code> API allows you to represent complex data in JS form. Data relationships can be represented through RxJS via streams. You can plug the models from the <code>FormBuilder</code> API into an Angular-registered input component and it all just...works. (Of course, you need to know and be aware of what you're doing, but, as engineers, that caveat comes with the job.)
RxJS is also straight-up great, though cumbersome size-wise and debugging-wise. For my own React projects I have attempted to replace RxJS with native JS Promises; I feel I have more-or-less succeeded, but only as a result of changing the code's architecture frequently. RxJS streams give you so much more control over when you want data to be consumed and when you want code ran. It also makes for a nicer event messaging system than anything I have seen JS offers natively.
RxJS and Angular singletons, which I am salivating for in React, make for a dream team, allowing you to move a lot of your JS code outside of your React components without losing context. There's nothing wrong with JS functions, but their external context comes from parameters (as they should!) or the loosey-goosey rules of JS function scopes, of which we could find a JS quirks forum describing some real head-scratchers. Angular allows you to combine various transforming services together without fear of duplication. Oh, and being able to provide everything you need through the constructor, via Angular's injection system, is a truly great convenience. You can't beat it.
So.
When making a website - and most websites, I think, are for branding, which means speed is an absolute requirement; sometimes you can shop in them - elegance and simplicity, which mean omission, are necessities. React is better. (Again, we'll have to see how Svelte pans out.)
A data-heavy form is not used for a small peek. You need to point out the complexity of various data relationships to your user. To a certain extent, speed can be sacrified for verbosity on the UI and readability/maintainability behind the scenes. And to emphasize, Angular isn't slow, unless you're doing something blatantly wrong (as I have done from time to time); you're negotating over milliseconds and kilobytes, though these seemingly small units of scale are certainly important. If you need a big toolbox for the Javascript side of your application, then Angular is better.
And, for goodness's sake, do not use Redux. (Smiley face.)

TL;DR - It's down to commercial sites, like this one, and enterprise solutions.

Musings on software development

Implementation of a form using an LLM

The Observer Pattern

Thoughts on the Gang of Four's Design Patterns

Angular versus React