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

Thoughts on the Gang of Four's Design Patterns

Angular versus React

Settings