So many frameworks, so many concepts repeating their form every 3-5 years...and only with pure luck you pick the one framework that will be there for the next 2 years to come.
Nobody refactors. Everybody reinvents. Everybody abandons. It's an endless cycle of catching your own tail.
If you read a software engineering book about patterns and architectures you'll quickly realize how many framworks reused a concept that is 30 years existing already, yet selling themselves as the hot new cool kid on the block.
I don't understand why lately architecting software doesn't result in refactoring anymore. I think that only through refactoring you can really understand and learn from your own mistakes.
> Everybody reinvents. Everybody abandons.
There's that saying about haute couture - "out of fashion" is just highly avantgarde.
That's why I build CGIs. They as up-to-date today as they were 15 years ago.
The process is not going to be commercially viable for many years simply, and this is why crap persists because that crap does solve real problems today.
You can check out the project: http://www.adama-lang.org/docs/why-the-origin-story
It's going to take a long time until I get to a 1.0 release.
Will it be used to build online board games (like an engine) or to "generate" one?
There's also another nice tool for simulating games. Not really in the scope if your project, but around the games topic. https://machinations.io/
As a developer, I can code the back-end for a board game without thinking about the failure modes for disk/db/network and I code as if I'm a single process (you know, the way we coded as kids). The mental model mirrors if you gather all your friends to play a game with the same keyboard and mouse.
As a service, it is a combination of EC2/Lambda for compute, Ably for notifications and connectivity, some DB for storage of state, and workflow for orchestration of people transactions. All within a single package.
As a game designer, my hope is that I can make it easier enough that the rules backing a game can be built and then evaluated with simulation and artificial intelligence. I have rough prototypes of this, but I implemented the back-end of Battlestar Galactica and had a random bot just play it. That's a remarkable achievement in a way, and now the question is how to train a system to search for patterns in looking at what decisions are made with a JSON document as the state of the game.
Commercial players are finally entering this space, with Roblox getting more attention and Unreal/Fortnite moving in this direction.
Are you sure you need a new programming language? It seems like a DSL or a framework would do for the problems you're trying to solve, and you'd save time for yourself by not writing a standard library, and for your users by letting them use a language they know.
A comparable framework for some of the workloads I envision would be https://akka.io/docs/ , but then you have to live within the framework or bad things happen. My idea with the language is that I eliminate all the bad things and keep thing simple.
Where I've scratched my head on this problem with existing solutions is that you need a lot of things to align. For instance, making it possible to coordinate players easy requires having a language support async/await semantics. This lets the server coordinate you playing a card which another player can interfere with, and another player could interfere with that.
The challenge with async/await in modern languages is what do you do with the process if the future takes... hours to return? How do you handle upgrades? operations in the cloud of cattle? This is where I started to re-invent a logger for board games, but then you must treat all your game code as deterministic. If you don't, then you are in for a surprise as the server replays the log. Instead of trusting myself, I'm forging the standard library such that everything is deterministic.
The final component that gives me confidence in needing a language is the reactivity. My language is basically a text-based Excel engine with tables, objects, and global values. This means that when a player makes a move, I simply need to manipulate the state appropriately and then everything bound to that state gets computed on the fly as needed. The state also is annotated with privacy controls such that important information doesn't leak between players, and this is something that is really hard outside of a language context.
All in all, I don't really need a language to ship a single game, but if I want a platform to enable anyone to build a board game, then I need to make it accommodating.
That's because craftsmanship in software has massively diminishing returns outside of a few niches.
Unless you're writing some VERY highly optimized kernel code, some physics logic that makes a simulator run correctly, etc... you're writing code that gets the job done until it's replaced.
A login form on a website works, until the business requirements for it change. Is it worth going back and understanding all of the fine details to make sure your changes don't break anything, or should you just rewrite it from scratch in an afternoon?
This is how I feel generally about craftsmanship. There are some places where it's warranted for long term stability and incremental improvement. But the power of software lies in it's mutability (else it's better and faster in pure hardware), so the vast majority of software will break due to changing requirements or dependencies, and will be cheaper and less buggy to just replace. There's no point in finely crafting these replacements because eventually they'll suffer the same fate.
linguae used the word craftsmanship, which covers more than just performance. Correctness is another obvious aspect. (We still write production code that is vulnerable to buffer-overflows, for instance.) Standards-compliance is another. Wikipedia has a list that applies here. [0]
This is analogous to other engineering disciplines. There's no market for supersonic civilian aircraft, but there are plenty of challenges besides speed to keep aeronautical engineers busy.
Even if you're developing 'just another website', poor craftsmanship might result in downtime and loss of customer data. It might also result in longer onboarding times for new developers. The list goes on.
[0] https://en.wikipedia.org/wiki/List_of_system_quality_attribu...
Assembler code for old 2D game consoles is unclear, partly because it's not structured programming, partly from rushing out the door and/or generational cruft, and partly from talking to awkward hardware interfaces, and partly from optimizing performance. I've seen C code with #ifdefs to pick different code on x86 and RISC CPUs, which might've made sense as an optimization with CPUs and compilers from 15 years ago. Duff's Device is faster on older processors, but sometimes slower on new processors and compilers.
From what I've heard, microservices address organizational problems more than technical ones, and dependency injection may be more useful in large enterprise projects (not sure, in my minimal experience it creates complexity).
I think that all of performance, clarity, elegance, and replacability (possibly linked to modularity) are values, and software craftsmanship can encompass one or more to varying degrees.
Am I misinterpreting your comment, or did you just list 3 distinct items?
1. easily understood and simple code
2. code easily maintained and extended by corporate employees
3. fast code.
In my experience, points (1) and (2) are one and the same. No tension at all. Easily understood and simple code is easily maintained and extended, by anyone.
When I write code, I never try to cater to some junior idiot. I write for myself, 6 months later. Yet people who see my code often compliment how easy to read, use, and extend it is. Junior and experts alike.
Even with something like a login form. If you keep on improving it with what you learn whenever you need to re-implement it or extend its requirements you end up with at least a re-usable "architecture", and most of the times you probably end up with big chunks of code that you can use, either the JS part, or html, or back-end logic. You now have a nice show/hide password field, your html is semantic, issues that were on the first quick and dirty were ironed out a bit with every iteration.
> But the power of software lies in it's mutability (else it's better and faster in pure hardware)
This doesn't seem at all right? The power of software lies in it doing what it's supposed to do, not introducing problems that might be costly or annoy users to the point they don't use it anymore or something better comes along and not doing what you don't expect it to do. And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it?
I also think that if you can rewrite it in one afternoon, perhaps it's ok, but I doubt the things where some semblance of quality and effort matter is when whatever is the software isn't rewritable in an afternoon.
> so the vast majority of software will break due to changing requirements or dependencies
This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.
You do realize that "mutability" means "ability to be changed", correct? It's value comes from being able to be rewritten piecemeal, as opposed to hardware where you'd have to design a new PCB, manufacture it, then snail-mail it to all the places it should be, then install it.
>> so the vast majority of software will break due to changing requirements or dependencies
> This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.
What you said literally had nothing to do with that except you quoted from my comment.
It's not any better. And has the added challenge that since it doesn't need to make money, sometimes projects keep going when they aren't doing very much useful on the order of the resources put into continued development. "Sunk cost fallacy" can be enormous.
Software is just hard.
Another context than the software industry is the "enterprise", where software is being created to support some internal business process (in the broadest sense of 'business process'). That has it's own pressures. But that software too ends up looking much the same.
The OP article really struck me, I have to think more about what to take from it, but I think there's a lot there.
This article to some extent suggests a kind of "software pessimism" -- is all software just destined to be a garbage pile? (Although the authors say "we can and must do better", the text doesn't leave me confident in that).
Software is just hard. It's also eating our world though. If it's all destined to be a garbage pile, we're in trouble -- forced to spend our lives fighting with buggy, hackable, inhuman software that acts like it wants to kill us.
one way or another, we probably need a lot less software in order to make it better software. That seems pretty unrealsitic, I realize.
I've thought before about, what would a "slow code" (like "slow food") movement look like?
He also has millions of dollars, thus, years to devote.
We might exploit this example to say about a slow code movement "people in the slow code movement would recognize at the start of a slow code project that they will be working in relative secrecy for several years".
> Perhaps the solution to making software jewels less rare is to make it easier for software engineers to make jewels by creating more sophisticated developer tools, so that way the quick-and-dirty approach just so happens to align with "the right thing."
That would go a long, long way, but culturally we would need to embrace quality over profits and I don't see that happening any time soon.
I do believe we will make some gains in the tooling due to open source/collaborative work a lot of us do for fun. Granted, without the cultural shift, it'll be a slow, gradual change.
It didn't have to be really good: It was better than any other digital music store out there!
Apple had some good UI ideas in the past. For a fleeting moment, they were the best. But eons ago they sold out the user to sell him a lifestyle/subscription system built around keeping people from leaving. This vastly compromised their UI designs to the point of making them frustrating and sometimes futile.
https://discussions.apple.com/thread/250315803
Software that loses data it fetched or produced is an accident. Software that actively search for and deletes data it has nothing to do with (in backups!!), is malware. People went to jail over such things.
Why specifically do you hold iTunes in such low regard? The bolt-on, beyond-music functionality has always sucked, but I didn't find it wanting from a music management POV. (Although I never used it for ripping. dBpoweramp for me, thank you.)
As far as the raw UI, they were shown to the door by Zune which was a massive failure! Couldn't Apple with its money and music business success have made Zune or something even better? Of course they could. They had an early lead. My point is they chose not to because openness and control in music (or anything else) is antithetical to their business model. This adversarial view of users is also what lead to terrible iTunes bugs like eating your music, which others also recall well.
Then how would you know how good or bad Apples software UI/UX is if you have only one frame of reference? It's good or bad compared to what?
I don't think you can easily make that claim.
The classic Mac OS and pre-Big Sur macOS were the best environments I’ve used from a UI/UX perspective, with Windows 95/98/NT/2000 being worthy runners up.
Perhaps the solution to making software jewels less rare is to make it easier for software engineers to make jewels by creating more sophisticated developer tools, so that way the quick-and-dirty approach just so happens to align with "the right thing."