The *concept* of patterns makes sense. A shared language that developers can use when building things.
The *reality* of patterns has been much less useful. The original ones were indeed a reaction to warts in the popular languages of their era. And as we tend to do in our industry, these have been cargo culted along the way and for some reason I still see people talking about them as first class citizens 30 years later.
People don't seem to realize that patterns should be and are fluid, and as our industry evolves these patterns are evolving as well. A major difference between software engineering and the analogous fields people use when talking about patterns is those industries are much older and move less quickly
A pattern is exactly what the word "pattern" implies; something that lots of people seem to have found useful, so you might find it useful too.
If you are a language designer and you see lots of people writing the same boilerplate, it behooves you to put it into the language. A pattern is a desire path - pave it. In that sense, they are missing language features.
Since a single-method object easily serves the role of such a function, that’s simply not true. Looking at the 23 GoF patterns, I can’t identify any that would be obviated by having first-class functions (or lambdas, as many OO languages nowadays have). Some of the patterns can employ first-class functions (e.g. an observer could be just a callback function reference), but the pattern as such remains.
The language feature isn't "passing and returning functions" but "loose coupling." Lambdas and Functors are just a way to represent that in OOP languages that care more about inheritance than about messaging.
I recall a lot of this comes from Java 5/6 where I think passing function pointers around was difficult, if not impossible. Back in those days, I had many a conversation with a friend who would ask "can Python do pattern/feature X?" to which I'd respond "it doesn't need to."
def addX(x: Int): Function[Int,Int] = {
y => x+y
}
addX(5) then returns a function that adds 5. So closures, which are equivalent to objects (behind the scenes, the compiler needs to allocate a structure to remember that 5 and know the "member function" to call to do the plus), and usually more straightforward.
Once you get used to doing this, you realize it's useful everywhere.
In a decent language with functional programming and generics support a lot of GoF patterns can be directly encoded as a simple type signature where you receive, return, or both some function, so there's not really much else to say about them. Like half of the behavioral patterns become variations of the interpreter pattern.
Yes, and in Java and other languages (e.g. in Lean you can literally use the syntax λ x ↦ x + 5). When OOP was more of the zeitgeist, these languages didn't have lambda functions.
I don’t really think AI would help much with the gaps related to the actual game design. It should allow for faster feature development, adding QoL, etc, but you need the actual game part coming from you.
Links with lots of data in them are really annoying to share. I see the value in storing some state there, but I don’t think there is room for much of it.
What makes them annoying to share? I bet it's more an issue with the UX of whatever app or website you're sharing the link in. Take that stackoverflow link in the comment you're replying to, for example: you can see the domain and most of the path, but HN elides link text after a certain length because it's superfluous.
My current hobby project is for DOS. Runs everywhere, mostly thanks to DOSBox, and the API has not changed since 1994 and will never change. For something to run offline and to avoid being stuck forever maintaining code I think this is what I will stick to for most of my future projects as well.
It's not like any modern OS, or popular libraries/frameworks could not provide an equally stable (subset of an) API for apps, but sadly they don't.
I actually think this is rather sensible. If I didn't have to learn DOS from scratch[1] to do it, I would be tempted to use it as a platform for many of my side projects. As you say, it will forever be a desirable platform to maintain (currently in the shape of DOSBox) thanks to the vast quantities of software – especially games – written for it.
[1]: I am young enough that when I last used DOS was before I had started programming, so I never learned it beyond command-line interaction.
Microsoft definitely wants to evolve, from my understanding they are looking at trying to lure people to package their apps, and to present similar hurdles as on macOS if your app is unsigned.
But due to old apps which nobody will update to package, I assume a lot of users will just disable all sort of warnings.
