Hacker News Reader

I personally think that the web development industry is the software industry's peak form of rushing things to market.

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.

Intesting - that's my impression as an outsider (mobile, not web).

> 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.

Psst, serverless computing.

The original arrogance is believing that you know which problem is most valuable to solve. Yes, the constant cycle is annoying but framework producers are under the same incentives as those delivering applications. There's only so much runway and at the end of the day you need something useful if anyone will adopt in slightly more useful than switching cost if you want anyone to change to your framework from another. From each attempt we gain insight and perspective that we can use to feed in to a slightly better implementation on the next tool or implementation.

I'm in the process of crafting my jewels over the next few years, but I have the position of being almost retired. I'll be able to take my time and focus on crafting good software.

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.

That's a very interesting tool/language. I don't really understand how it works, but I kind o understand the idea behind it. I think.

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/

At core, it's an infrastructure language such that it enables the people to come together without fuss.

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.

I love the idea! I've been wishing for multiplayer game development to be free of networking troubles for a long time.

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.

So, my language is basically a DSL for Java in many regards. I basically translate Adama code to Java, and then build on the fly.

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.

> the industry, in my opinion, does not seem to value craftsmanship in software outside of a few niches

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.

Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up.

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.

> Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up.

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.

> Unless you're writing some VERY highly optimized kernel code

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...

I personally don't agree.

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.

> And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it?

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.

I’m not sure the same developers would produce much better software given more time and less pressures. It may very well end up more complex and over-generalized. I think jewels are more the outcome of passion and relentless iteration.

I have experience working in non-profit/academic open source software.

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?

Let's make it a little easier by talking about a slow code project instead of a movement. I think that could look something like Jon Blow's development of the Jai programming language, which is in closed beta after being developed for several years already. He's emphasizing the joy of programming.

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".

IMHO market pressures, focus on profit, lack of care for quality by the developers as well as management, and so forth are all why software is basically shit these days.

> 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.

I don't have any Apple products but I think they have a reputation of valuing quality.

I agree. The Mac ecosystem has long valued quality, especially when it comes to UI/UX. One of my favorite proprietary software companies is The Omni Group, which has made a lot of very well-done software tools for the Mac, such as OmniGraffle. The company's adherence to Apple's UI guidelines is strict, and its products are wonderful to use. Apple itself has also made excellent software (I'm a longtime macOS user), though I feel that its UI/UX perfectionism has slipped in recent years.

> Apple itself has also made excellent software (I'm a longtime macOS user),

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.

I’m not exclusively a Mac user. In the past 30 years I’ve also used MS-DOS, every version of Windows since 95 (except for Me and server-based versions like 2003 and 2008), various Linux desktops, Android, ChromeOS, and iOS. I’ve even played around with NeXTstep, Haiku, Pharo, and Plan 9.

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.

How's Pharo in practice? It seems really cool in demos.

This answer is how you should preface your argument. Gives people like me context. Saying Im long time mac user in a vacuum misleads small minds like mine

Their UI quality is more mystique than reality. iTunes was a particular abomination among many. Not only did it have a terrible interface which conformed with nobody's standards and looked nothing like any other Mac app, it also had a propensity for eating your music, especially music which was yours and acquired outside the Apple store. Hardly a quality program. Apple apps are still famous for focusing more on keeping you in their walled garden than on making the best UI for the user.

> iTunes was a particular abomination among many

It didn't have to be really good: It was better than any other digital music store out there!

Software that does this: https://discussions.apple.com/thread/250315803 is likely worse than nothing at all.

Assuming you mean Apple Music (iTunes was an okay MP3 player/ripper, but is dead), I consider it the exception that proves the rule. Enjoy the schadenfreude of this recent Apple Music for macOS review: https://www.youtube.com/watch?v=gE8ZikfrpFU

No, I meant iTunes. Their willingness to make that was a harbinger of Bad Things to Come, ala the review you linked.

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.

I once read a composer complaining that iTunes has deleted his master records and "helpfully" replaced them with compressed files (lossy compression of course). I tried to find it to prove your point, but found this instead:

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.

There are many iTunes stories like that. A friend of mine who is a composer and singer had his original songs erased from his library, irreplaceable live recordings, because of Apple's open hostility toward files they didn't create.

iTunes was SoundJam MP with an Apple makeover. Both SoundJam MP and Audion were the shit at the time, so I recall being thrilled at the acqui-hire.

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.)

iTunes was never as good as any of the free music managers out there at the time. It lacked most serious features that users with a real collection (of their own) might need. Anything related to finding, sorting, organizing, naming, changing metadata, moving, sharing, re-ripping, ripping at all, etc. were severely crippled. Perhaps that's because SoundJam didn't build those features. But they stayed unbuilt because Apple didn't want them.

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.

I'm not going to weigh in on Apple but raising one of the most monolithic, insular, biggest capitalization companies on the planet to talk about software craftsmanship feels so so so so far from the point, from the question of software craftsmanship in the world. Icd rather not start the discussion by looking at extremes.

Reputation, yes, however this is no longer reality IMHO. Think of all those posts about how the keyboard sucks on macbooks, think of the posts complaining about Apple's quality in general over the past couple years. It may be a somewhat recent change, but Apple does not produce good quality any more. Apple is useful, but a bit janky these days.

Agreed about their software quality, but their laptops are still the best. The keyboard was an very real issue for awhile, but now they seem sorted out and are one of the best keyboards out there. Not to mention I cannot find a non-Apple laptop with the quality of screen and especially touchpad. It's a shame too because I am trying to move further out of the Apple ecosystem, but I can not find an acceptable laptop.