Monday, July 31, 2017
Sunday, July 30, 2017
Saturday, July 29, 2017
There's a thing that I feel like programmer-type people do a lot, where they sort of can only think of things from their own immediate perspective of knowing how something works, and having zero if not negative empathy about use cases where people are lost, or are screwed by the technology.
For example, there's jstest-gtk. It shows there being 4 controllers. Uh but right now I really only have 1 wireless xbox 360 controller talking to the usb receiver. So how the hell do I know which of the 4 is actually reporting in? The controller says it is #1 of 4, but when I drill down into the first controller in jstest-gtk and try to move values from the controller, nothing happens. So do I have to manually go into each of the other 3 and see what is happening?
Like, the intelligent design would have been for the list-of-controllers to have even just a little fake light that would flicker and change whenever any of the controllers are generating input. That way I could fiddle on the controller and immediately see if it is being successfully mapped to anything at all.
Instead I apparently have to figure out how to enable debug text logging or god knows what, or dig through each of the entires in the gui in turn.
Of course, being linux type software, there's a kicker to already having to suffer through the bad UX in that when I click on the "close" button in any of the individual joystick dialogs, nothing happens. Well the first time I clicked anyway. So then I go click the ubuntu red x in the sub window title bar... and the entire jstest-gtk app quits, rather than just closing the sub dialog so I can go try another controller. So then I have to laboriously re-launch it. Complete and utter epic usability failure. Just mind bogglingly stunningly insanely bare-faced bad. (Subsequently I have had the 'close' button be more than unresponsive, but when it works it has the same effect of quitting the entire app.)
For example, there's jstest-gtk. It shows there being 4 controllers. Uh but right now I really only have 1 wireless xbox 360 controller talking to the usb receiver. So how the hell do I know which of the 4 is actually reporting in? The controller says it is #1 of 4, but when I drill down into the first controller in jstest-gtk and try to move values from the controller, nothing happens. So do I have to manually go into each of the other 3 and see what is happening?
Like, the intelligent design would have been for the list-of-controllers to have even just a little fake light that would flicker and change whenever any of the controllers are generating input. That way I could fiddle on the controller and immediately see if it is being successfully mapped to anything at all.
Instead I apparently have to figure out how to enable debug text logging or god knows what, or dig through each of the entires in the gui in turn.
Of course, being linux type software, there's a kicker to already having to suffer through the bad UX in that when I click on the "close" button in any of the individual joystick dialogs, nothing happens. Well the first time I clicked anyway. So then I go click the ubuntu red x in the sub window title bar... and the entire jstest-gtk app quits, rather than just closing the sub dialog so I can go try another controller. So then I have to laboriously re-launch it. Complete and utter epic usability failure. Just mind bogglingly stunningly insanely bare-faced bad. (Subsequently I have had the 'close' button be more than unresponsive, but when it works it has the same effect of quitting the entire app.)
Friday, July 28, 2017
Sunday, July 23, 2017
It does/not amaze me how bad the Dropbox web ui is. Just fundamentally utterly broken. So, so bad. Of course it is probably because I run Linux, use Firefox, with Ghostery. Not that the web was originally intended to, you know, "just work" by using "standards" and stuff. Featureitis is a real thing with both good and bad consequences.
Saturday, July 22, 2017
Wednesday, July 5, 2017
Basically I think the whole approach to PC graphics is bad, wrong, broken, dumb. Consoles that have a "streaming" mentality are more what I want in life. I want immediate mode. I don't want to upload static meshes and have to much with them on the GPU in painful ways. I want fast fast fast immediate mode. So the whole 2 gb + ram caching PC architecture is just horrible evil demented legacy medieval stupid constraining crap. That's how I feel, as a frustrated artist wannabe.
One thing I strongly dislike about the computer programming world is the focus on componentization without enough focus on ux and quality. So we end up with the current living heck of a zillion npm or elm or yarn or typescript doo-dads, all of which have to somehow be downloaded and cajoled into actually working together, let alone also with {bower,browserify,webpack,etc.}. It really is a just a crap fest of broken exploding configuration state space overkill.
These days (well, probably for ever, actually), it seems like any time I try to go and start doing some new personal mini programming project, I end up getting nowhere fast due to really stupid bad broken crappy useless hateful ass backwards ux of everything. Somebody give me a million dollars (US, please) so I can pay some smart people to make a programming language ecosystem that isn't just a minefield of crap hell, please.
Tuesday, July 4, 2017
So far, Elm feels like it is over-hyped. The UX just isn't there in my opinion. A few examples:
- The error messages are supposed to be so great. But they are really just overly verbose. And wrong often enough to drive me nuts e.g. I had a variable name typo, or a misplaced extraneous comma, but the error messages where about completely different things. And sometimes the error message doesn't even say a line number.
- The limitations of the error detection & messaging means that I end up breaking things apart more than I otherwise would, just to be able to get the compiler to tell me the real error.
- The debugging story is supposed to be so great, but I haven't seen a way to e.g. debug a single function interactively from the repl. Debugging utility functions seems to be only doable as part of an overall app being run and debugged?
- elm-format drives me nuts. I really do not like a lot of the aesthetic choices made there.
- As much as I love Haskell, I really do not like whitespace-sensitive syntax since it leaves too many things as ambiguous, which then makes using elm-format a gamble and a wrestling match.
- Seems like several elm editing modes think that format-on-save is enough, but I consider it necessary but hardly sufficient.
- The naming of things sucks now because of the history of change. Which linear-algebra package should I be using? Why did webgl fail to install? etc.
- The unit testing framework (uh, again, which one should I even be using?) elm-test doesn't support a message string per assertion to show when Expect fails, which makes it even more annoying to try to figure out why it failed (cf. the lame debugging story).
Monday, July 3, 2017
I am a pure functional programming fan. But at the same time, I think loops are not pure evil. It drives me nuts when people go to ridiculous lengths to avoid them.
Saturday, July 1, 2017
I think Elm gets error message UX wrong. They claim to have such "friendly" error messages, but heck there's plenty of times I've seen where it was just utterly wrong about the real reason the error happened, so making it seem all "friendly" seemed to me to just be increasing the misdirection. Also, they are kind of overly verbose for my taste. All in all not as wonderful as all the blog posts had let me to envision in my mind's eye. It is to sigh.
Subscribe to:
Posts (Atom)