hsn915

> Exactly! Your api contract and your storage are ALWAYS two different objects

Not really. I have request objects for everything. "Search" is a request object. List pagination is a request object.

Every function exposed through the RPC API takes a request object and returns a response object.

The response object is often just a collection of objects straight from "the database".

A response to a paginated list request will contain a list of objects straight from the database, in addition to some metadata about the pagination (names: current page number, total page count).

The cruicial part is there's no "transformation" of data as it goes out from the database into the UI. There's some aggregation and grouping (an outer object that contains multiple objects), but that's about it.

Again though there's a subtlty: some transformations do occur, but they don't occur on the path from the storage to the UI. Instead, everytime I store a complex object, I also derive a "simple" version of the object and store it too.

When you request a list of objects, you get the "simple" version, and the UI displays them in summary format. When the user clicks one of them items on the list to see more details about it, the backend sends the "full" object.

Notice the underlying principle: the UI flow dictates how the storage layer stores objects.

This is the anti-thesis to the common wisdom, where the storage layer does not care about the UI, and it's the job of the intermediate layer to transform data for the needs of the UI.

I don't like learning new things.

Unironically.

I like learning good/useful/effective things.

Not "new" things.

Most "new" things are less capable variations of existing things that are better and more mature.

You're citing an exception as if it was the rule.

But even in this case, I don't have two representations of the same object. Rather I have two different object:

Account (persisted)

SignupRequest (not persisted)

The SignupRequest is used to create the Account

The signup form on the UI is about editing the SignupRequest object. This object will be sent from the UI code to the backend as-is. The backend code will use it as-is (ignoring the json encoding/decoding).

There's a code path in the backend that takes SignupRequest and uses it to create a new Account.

It's ok man. I don't need to be cheered up.

It's completely fine to accept your situation without giving up on improving it.

The problem is when people refuse to acknowledge reality because they really hate certain labels and are too invested in not having that label apply to them.

I'm slow and it's ok.

I'd like to become faster in the future.

But for now, I'm slow, and that's ok.

Thank you for posting the link. This was definitely one of the inspirations (in terms of the provocative titles). But I couldn't remember what it was called exactly.

OP here.

I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer.

So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time being, this is my speed.

I was going to make a writeup about coming to terms with that.

But somehow as I was writing (originally on Twitter) I linked it in my head to the way I hate modern dev culture: the docker and the webpack, etc. Programming is already hard, why make it 10x harder with all the tools that require complex configurations, etc?

I remember raising this point on HN and other places with other developers, and that there was always push back from people who swear by these tools.

So it clicked in my head: I hate these tools because I'm already slow as it is and I can't take it when these complexities slow me down even further.

Then as I spent more time thinking about the content, I thought this a manifesto worthy content.

But in terms of the points mentioned: I'm dead serious about all of them. Although what I actually mean might not be obvious from first glance.

When I said I write objects as-is, it appears that most people in this thread thought I'm writing individual files. This is not what I'm doing. I'm using a B-Tree backed key-value store and doing binary serialization. I also have a scheme where I make use of the properties of B-Trees to make indexing/querying possible. I have a whole write up about this topic: https://hasen.substack.com/p/indexing-querying-boltdb

For using HTTP as a medium for RPC, I also have a writeup: https://hasen.substack.com/p/automagic-go-typescript-interfa...

These alternative techniques took time for me to develop, so you could say that it would have been faster for me to just use postgres/docker/aws etc (the standard stack). But this is my point: I really am too stupid to learn them.

But, _what_ is the point of using a different layout/structure for storage vs the UI layer?

Remember I'm a 0.5x developer. If I have to write code to transform data for every kind of entity/object I need to store and have a UI to view and edit, that's way too much. I'm already very slow. No need to slow me down further by telling me I have to write so much extra code that does no useful work.

No that's not what I'm saying.

No. I'm too stupid to even understand what that means.

This sounds counter productive.

Third party authentication providers are a single point of failure, and usually they themselves require a password to authenticate you anyway.

If your gmail password is hacked, then effectively all your accounts on websites that use Google auth are also hacked.

Passkeys appear to also be handled by central services? At least that appears to be the case with Apple, according to the link in the post:

https://developer.apple.com/passkeys/

I personally think having a browser-managed "private key" (the same kind used for ssh auth) would be better, but now as a user you have to manage the multiple private keys you have associated with an account; a totally confusing concept for the average user.

UTM is great in theory but I can't seem to be able to get directory sharing to "just work" and it's very frustrating.

This comment suggests otherwise:

https://github.com/ziglang/zig/issues/89#issuecomment-122118...

Although I'm not sure the "self hosted compiler" is the same as "llvm free backend".

You can certainly create legislation while pretending you are just interpreting text.

Roe vs Wade is an excellent example of this. Which is why finally getting rid of it was a good thing.

Hence most CI services are stupid

The Supreme Court's job is not to legislate.

30k servers? Are you operating a botnet?

No, packages are stored locally in a "modcache".

Unless you're doing something stupid like "create a clean virtual environment for every build" then yea your build might break if you lose the internet or the packages disappear. Just don't ever do that stupid thing.

The lack of clear distinction between different widget types (buttons, labels, input boxes) is one of my biggest pet peeves with "modern" UI design trends.

The main challenge in UI design is balancing between:

- Allowing the user to perform desired operations in as few steps as possible

- Without cluttering the screen with all kinds of irrelevant controls

These constraints can be at odds:

Every time you hide some feature away in a menu, you are adding steps the user has to perform to achieve what they want

On the other hand, presenting every single feature on the screen all the time just clutters the UI and makes the user feel confused

It's no good to let the user decide what goes on the UI either: you've now just burdened the user with the job of creating a UI for your application.

Other constraints:

- Make sure all features are "disocverable" by just casually playing around the UI.

This rules out the idea of "hiding" things until the user triggers some kind of magic incantation.

Command pallets and shortcuts are great ways for enabling power users to perform operations quickly, but the product must have other ways for exposing features that is predictable and boring. Menus are a great way to do this. A user casually playing around with buttons and menus will eventually discover features, and they will also eventually learn the shortcuts for them.

What OpenAI is doing is not alignment.

It's suppression.

Alignment works on the level of desires and intentions.

Suppression works on the level of output.

Everyone in a dictatorship sings in praise of the dear leader, but most will defect when given the chance!

There's another approach that I don't see discussed often: structure operations so that code just "passes through" on errors and code the happy path.

In the case of opening a file, you would get an invalid file handle that you can still pass around to functions and nothing would "fail"; it would just be as if you passed a handle to /dev/null. This scheme requires that you can still explicitly check if the handle is valid.

Most people are familir with some form of this with the special NaN floating point value.

What exactly are you proposing here?

> I don't know if people have noticed, but lawyers win when people fight

People have disagreements. It's inevitable. It seems like you want people to never disagree on anything. But it's unclear how that can ever be possible.

> Judges cannot and should not look down on self-representing litigants

Is that not already the case? Is there anything preventing anyone from representing themselves?

SEEKING WORK | Japan | Remote

I'm running a consulting service focused on improving the local development experience for clients.

See: https://hasen.substack.com/p/local-first-development

Email: consult@judi.systems

Consultation calls are free

I'm using substack, but eventually I want to move to something I own.

What waitlist? I got immediate access as soon as I paid.

The articles starts out with the premise absolutely backwards on its head: efficiency is the exact opposite of constant 100% CPU utilization.

The more efficient the program is, the _less_ CPU resources it will consume to achieve its task.

Specially when that task is serving http requests. Unless you are always serving one million concurrent connections with one servers, you should never see chronic 100% CPU utilization.

> Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.

The problem is not forcing people to do this or use that.

The problem is the quality and development experience is just _so bad_ that people are resorting to other options.

Don't get me wrong, the dev experience for web is terrible, but it's still light years ahead of legacy toolkits like qt/gtk/etc.

> What would you expect to see instead of a bunch of configuration files and cryptic commands?

The fact that you even need to ask ..

Like, it's so _obvious_ that any computer system can't possible be made to work properly without a bunch of cryptic configuration files and cryptic commands.

You proposed it as an alternative to the complexity in the OP, but it's more or less the same thing: edit a bunch of config files and run some cryptic commands

I find that equally triggering