There is a lot of deliberation over where they should go.
If you say that, then I’ll have to believe you. My standpoint on this is more akin to your next statement,
Music is a language. People in a jam session are speaking words and phrases to each other. There are grammar rules
That means that once the piece of music turns out to be in, say G major, then there is little (I even dare say no) deliberation on whether you’re playing a G natural or a G sharp. There may be deliberation in the phrases you play or in the general direction the piece you’re playing will go. There may even be deliberation in not playing a G natural from time to time. But by default you don’t think about these things. You just play.
This is what I’m comparing to using an AI tool. One doesn’t think about every single note every single time, just like one doesn’t think about ever single filler word that’s only there for grammatical purposes in writing prose, and just like one doesn’t think about every single color channel of every single pixel when creating a digital painting. So why does using an AI tool invalidate the art? Because there is no deliberation over every single tiny aspect of the output?
If you’re using an LLM, then your jam partners aren’t speaking to you, they’re speaking to a robot.
This is just plain wrong. It’s like saying you cannot be a musician if your instrument is MIDI. Or you can’t be a singer if you’re using an artificial voicebox. The LLM still produces what its user intends it to produce. The LLM doesn’t produce output on its own. It is operated by the user. Just like a guitar is operated by its player.
Your first example is exactly what I’m talking about. 2/3 of screen space are wasted and literally show an empty void. And you’re telling me it’s essential to see that?
I grant you that this might change as development goes on, but as the screenshot stands now, it’s an argument in my favor.
As for the NASA image: I see that all these indicators may be open, so the user can immediately see when one flashes red. That isn’t so much the case for people who have discord (or task manager, WTF?) open on a full screen. Or a calendar, as I mentioned in another comment.
filter() right before displaying my data felt easier than getting the right data to begin with.
The issue here is that you don’t know what the right data is to begin with. SAP does what you’re suggesting. They demand you set the filters correctly before requesting any data, which is a terrible user experience.
Imagine you need to debug that and don’t even have an intermediate step to see whether the wrong data is arriving or whether filter/sort logic is wrong for a specific case, or whether its just the rendering.
That’s a strawman. Why would I not know what data arrives in the frontend. That’s what the network debugger is for. That’s what a breakpoint before the filter is for.
But you can’t tell me that applying filter/sort to 8MB of data in the frontend is anything but mega scuffed.
Personally, I find re-transmitting those 8MB of data for every different sorting request way worse. Remember that this isn’t even cacheable, because the data is different for different sorting requests.
Maybe we have different types of frontend and different levels of user proficiency in mind. In my case, I cannot possibly ask the user to know how they want a list sorted and filtered before seeing the list and the options. They’d throw the frontend in my face. If you have very knowledgable users that know what they want from the get-go, then it might be possible to show them a form to sort and filter and only request the data when the user sends the form.
Not to even mention how that would run on low-power devices with bad internet connection.
I don’t see how ‘bad connection’ is an argument in favor of re-requesting data just for it to be displayed in a different order. I’ve made this back-of-the-envelope calculation in another comment. For a good connection, latency is about 20ms. In that time a 1GHz processor can to 20 million operations. Take 10 operations for each comparison (to adjust for more complicated comparisons), and you can use 2 million comparisons to sort the list in the time it takes to re-fetch it. (Keep in mind that the act of rendering the HTML itself is also computationally expensive for tables). 2 million comparisons sorts a list of 120,000 entries.
OK so now imagine 4 things you’re doing and they take up the width of one monitor each
That’s an assumption I [Edit (bad English): contend challenge]. Often when I see people who claim they need n monitors, then they’re wasting screen space like nothing. For instance, giving 2560px to a web browser that effectively uses the 920px in the middle to display text, because reading a line across 17 inches is terrible.
That would work, but it demands co-operation by the backend for the additional validation. It also means re-transmitting 8MB of customer data just so they can be arranged differently in the frontend. I don’t really want to move presentation logic that far to the back. If you want to display more data, you need to touch both the table-drawing logic and the sort-validation logic.
bleistift2 @ bleistift2 @sopuli.xyz Posts 212Comments 2,614Joined 1 yr. ago
Fixed