You might want to consider looking at Wikipedia's internal article quality assessments (these include Featured Articles, Good Articles, B-class, C-class, Start, and Stub). I use these as a rule of thumb for how popular the topic is, it's a solid proxy for both significance and the richness of the available content.
You can't unit test for taste
131–140 of 157 posts
Re: You can't unit test for taste
#132Earlier quoted context omitted.
Yeah you're right, I hear it more like "this is a week long hike, not a sprint" as if a marathon included rest. In any length of racing there's no tomorrow. But I'm doing tongue-in-cheek pedanticness here and will stop that right now !
In a marathon, not sprinting is the rest.
There is no rest. There is just (properly done) a continuous output from start to finish, or a very slight increase of output (negative splitting), but effort to maintain it feels exponential. In terms of feeling, it’s a 32km « dynamic run » where you should feel good, then the hardest 10k you can pull off just after that. If paced properly there should not be a « wall » but at all levels you pass people walking who disintegrated around 30km. Even people with sub-elite/elite bibs sometimes explode.
A half is more intense but way easier, you’re just sub threshold but for a time short enough that you cannot really not make it.
Re: You can't unit test for taste
#133You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can. Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want. Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I…
[flagged]
Re: You can't unit test for taste
#134Earlier quoted context omitted.
Many such churches. Substitute static typing for TDD in your comment, and it will remain equally valid statement.
Static typing is very useful and time saving. I can rename something, knowing my IDE can propogate the change. I can call a function and know what it expects, not just "a thing, hope they added a comment so I know what type/shape wont blow it up!". Here I am talking about the basic static typing, and maybe some generics use occasionally, but obviously people also go overboard sometimes with type features and that hin…
It has benefits, yes. And TDD also has some benefits. In both cases, these benefits are limited, and there are costs associated. And in both cases we have empirical evidence showing that neither is panacea to the problems church members claim they solve.
Re: You can't unit test for taste
#135I may be the only one feeling this way, but the repetitive mention of Claude – worded as if it was a coworker ("we", "me and my friend") to the point that somebody reading it just 3 years ago would reasonably assume this "Claude" was in fact a human – made it hard to read.
How much am I reading a behind the scenes of the "making of" of the application VS an essay on what somebody else (Claude) did ? I don't know.
The reason I browse this website is to see what other humans are saying, inventing, using. But in some cases like this one, I see the line between tool and co-author being blurred for LLMs.
And unless what they did is a specifically impressive thing on its own, I do not want to know what an LLM did.
(Don't get me wrong, I would much rather have this than people lying, but I would also much rather people treat LLMs as tools.)
Re: You can't unit test for taste
#136Earlier quoted context omitted.
Indeed, I'm sure Steve Jobs is rolling in his grave.
Steve Jobs was also responsible for brilliant bits of usability like puck mice, and the need to have two functioning hands in order to right-click.
As somebody who uses a claw grip, I loved the puck mouse. Now the stupid mouse where the charger plugs in at the bottom, that one actually sucks.
Re: You can't unit test for taste
#137You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can. Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want. Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I…
> You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can.
> Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want.
First you have to have it, and if you think this is a tasteful solution, then you didn't.
Re: You can't unit test for taste
#138You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can. Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want. Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I…
This problem predates AI. If we could externalize such a fickle thing such as good taste it wouldn't be such a valuable skill. And God have people tried. Golden ratios, style guides, naming rules, linters, formatters, templates, margin ratios, color palettes, and on and on and on. And yet here we are.
We can quantize some of the basics, and make a not half bad style guide, but we'll never be able to fully actualize a set of rules to match what humans find generally tasteful. Its too contextual and a moving target.
Re: You can't unit test for taste
#139Earlier quoted context omitted.
Static typing is very useful and time saving. I can rename something, knowing my IDE can propogate the change. I can call a function and know what it expects, not just "a thing, hope they added a comment so I know what type/shape wont blow it up!". Here I am talking about the basic static typing, and maybe some generics use occasionally, but obviously people also go overboard sometimes with type features and that hin…
It has benefits, yes. And TDD also has some benefits. In both cases, these benefits are limited, and there are costs associated. And in both cases we have empirical evidence showing that neither is panacea to the problems church members claim they solve.
I don't feel like static typing (the kind you use in Go, C#, Java etc) is a church, it is just a tool. I mean I always want to use it, because it is useful. So that might be like being in the church of say adding an electric motor to my bicycle? I can't show you a study or hard evidence saying having the electric motor is "better".
I mean there are people who go nuts with very complicated types/type systems so there is that, and then you have very complicated programs, maybe that is what you mean?
Using static typing all the time is just using the tools. Using TDD for everything feels a bit suboptimal to me and so needs some obsession to do that. It only becomes a church then if they keep pestering everyone else to do it.
Re: You can't unit test for taste
#140Earlier quoted context omitted.
I'm not familiar with shaders and game engines, so I'm not sure what you are saying. I had a quick look at godot tests, and seems to me they cover some parts of the shaders? Anyway, I was more wondering who/how people are dogmatic about TDD, and manage to leave out one out of three core concepts from red/green/refactor ?
If I cannot write shader code without broken tests, there is a bunch of yak shaving to make testing possible in first place, and that only covers a small subset of graphics pipeline features. It also takes zero consideration for the interactive nature of games/graphics development.
I can't immediately think of what a useful shader test would look like (beyond perhaps, shader doesn't crash program) - if this is something worth discussing, it would probably be useful to see some real world shader code; perhaps especially two versions of the same shader as it evolve.
I don't generally test css code to check that a background is now indeed set to "a more mauvey shade of pinky-russet" after a change - but I might want to.
I might at least want to run a test with browser automation to check that any text is readable on the background.
I could at least find an example of looking at the rendered page for text (as opposed to in the DOM); Google AI had some ideas of how to check the contrast in a screenshot - but no idea if that would actually work as written.
https://medium.com/@dzianisv/vibe-engineering-testing-browse...