When I read the Orwell's version, I immediately had the same feeling I had when reading mathematical proofs. I hate so much to hunt the preceding text for anaphora resolution... It's just such a bad and pretentious way of writing. It's hostile to the reader with the side of flaunting author's superiority.
It's like having to sit through a party with acclaimed academics: every single one is so full of themselves, they will constantly one-up each other by belittling everyone in their workplace s.a. to make you feel how great of an intellect they possess and how much more they would accomplish, had they not been surrounded by all these bumbling idiots.
I agree that it's not great style for just conveying information clearly and plainly (e.g I'd hate to read documentation written like this) but I'd argue that here, the medium is part of the message.
It's supposed to sound dry and depressing and somewhat sterile.
> It's hostile to the reader with the side of flaunting author's superiority.
I think if someone deliberately obfuscates meaning to sound fancier when the point is to communicate information directly, sure, I'd agree. But writing is often art, and I think demanding effort from the reader is fair in that case. I wouldn't make a blanket generalization like that.
I agree in that I don't know in what context Orwell wrote the quote above. Maybe it made more sense the way it fitted in that context.
Whenever this kind of discussion happens, I recall Andrey Platonov (a Russian writer, who was so weird in his rejection of the "decadent" parts of speech and sentence clauses that he'd never use passive voice or adverbs, would never put two adjectives side by side etc. that even Soviet censorship decided to ban him.) His works were added to the mandatory high-school reading list back around the collapse of the Soviet Union. I studied book publishing in college right around that time and had taken an elective in editing (the process of preparing a manuscript for publication, especially for the more technical fields, like encyclopedias or handbooks). My professor was a huge fan of Platonov, and, probably, forever spoiled for me whatever people enjoy when they read flamboyant or contorted prose like the one quoted above.
One thing that would send my professor into a fit of rage about that quote is that the real subject is people: it's talking about how people incorrectly rationalize the connection between effort and outcome. But, it's written in a way that, formally, the subject is... "the consideration", making it necessary for the reader to work back from the formal towards intended before they can figure out what the author was really trying to say.
I disagree. There is plenty of writing that operates at the same level of abstraction (philosophy, mathematics) without being needlessly convoluted.
Orwell is a master precisely because he understood language deeply enough to be able to produce a monstrosity on both the level of content (undue abstraction) and structure (winding, breathless syntax).
I inherited an electrical one from the previous owner. It ran on... battery. (Why would anyone do this is beyond me, but it turns out to be very common where I live.) The battery died and I needed a replacement. If I wanted to replace it with something that connects to the power cables inside the house, I'd need to drill a hole in the front wall (made of brick and mortar) and find the closest cable to connect to... And I was too lazy to do that.
On the street I live, there are mostly old houses. Some of them have a bell that exposes a handle on the outside that you need to pull in order to ring the bell inside the house. Some have a "door hammer" (is it what it's called?), a decorative, usually shaped as a ring in an animal's mouth, hammer that's attached to the middle of the door one would use to knock on a metal plate used for this attachment.
I bought an actual cast iron bell and attached it near the door above the mailbox.
What happened is that people seem to doubt so much the functionality of an obvious bell that they prefer knocking on the door to pulling the thread attached to the bell. That's what most package delivery service people do.
I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong.
So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations. And, if anyone should be given the power to act on it, the QA seems to be the most likely candidate.
> So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too?
Good thoughts and framing, thank you for that. I think I'm in the former camp, because I think fixing bad expectations is a matter of thoughtful redesign that should follow a slightly different process to fixing bad implementations (what I would call a bug). Not every issue in a program is a bug, and that has nothing to do with the importance or urgency to fix the issue.
Assuming a rigid product organization, I think developers _should_ ask testers to escalate "works according to spec" even if the spec is unreasonable. Otherwise developers might be torn between QA, UX, and architects fighting about how something should or shouldn't work. At least for me, finding myself in such a position is a recipe for excessive meetings and losing focus on other equally important matters.
I am in latter camp. Although I also agree with you on >escalate "works according to spec".
But let me use Steve Job's phase, "you must start with the customer experience and work backwards to the technology".
A bug to developers is work according to spec, but a bug to a user is that is it has mismatched expectations. And it really should be someone's job to make sure this is corrected. But as parent said, there hasn't been one in most if not all companies.
And perhaps that is what makes old Apple such a success. They have a low pay $1 dollar salary beta tester to test out literally everything.
> Who else uses the Shift key to end the screensaver, because in case the event goes through to an actual program it's least likely to do have unintended effects?
Hahaha. Yup. That's me :) Not the screensaver in my case. I leave my desktop "suspended to memory" overnight, and when I come back in the morning / afternoon, to wake it up I press the Shift key.
But, more on the subject, I kinda find it disappointing that the post doesn't try harder to analyze why this happens to the developers. The explanation doesn't feel satisfactory to me.
This was my experience working on a product that was virtually universally believed by its programmers to be of good if not excellent quality, while, in reality it was atrocious. Just to give you a taste of the quality: Jenkins landing page didn't work because it would take too long for it to load and various timeouts that happen when it fails to load would kick in and just mess it up so much it wouldn't have been useful anyways. Jenkins tests were generated from some horror-show templates written in YAML (some RHEL tool, forgot what it's called) and because there was no other way to test what the template generated other than to deploy the new test into the actual Jenkins server, the server was full of dysfunctional "orphan" (no longer tied to any template) tests that were never deleted. The only way to navigate to the test results of the job you were interested in where to memorize the way the templated name would expand into the URI components of the Jenkins job URL, have some other test results bookmarked, and then modify the URL of the bookmarked page to get the URL of the job you want.
The CI/CD team, however, decided to combat this situation by developing their own server which collected data from Jenkins and displayed a table with the most recent results for select jobs. Green and red being used to indicate whether the job succeeds or fails, the table was mostly red most of the time, with some jobs being continuously red for many months.
Initially, I was hired into CI/CD team, but when I remarked on the desperate state of events in CI/CD department... they wanted me fired, but the company was going through acquisition and they wanted a higher headcount, so, they kept me, but transferred into the least relevant department where I would be as useless as possible: the quality control!
My life as SDET (because QA is a curse word nowadays) exposed me plenty to the situation described by the author. The aspects that the author didn't touch on is that programmers working on such a product that I've experienced a lot are:
* Unwillingness to accept that a large proportions of the product is bad. People have this intuition that some parts might be bad. After all, that's why QA exists: they find a few things, things get fixed, and everyone moves on. And this is how it works in passable quality products. But the situation when everything is on fire and is going to hell in due course sounds alarmist to the people who are on fire and are going to hell in due course. After a certain amount of complaints, all further complaints are dismissed.
* Unwillingness to accept the existence of strategic mistakes. The QA simply is not allowed to voice their opinion on product or feature design. The only way a tester can initiate a fix is if they can create a test that illustrates the problem. Saying, for example, that "our error reporting is bad because it's useless to the customer and it cannot be meaningfully reported back to the developers" was dismissed as "nothing to do here" (but, actually, meaning: it's above your paygrade).
I don't believe either of these would've been fixed by "simply pointing out the bug", as the author claims. Our industry came to a particular way of doing things that are pathologically bad. The way QA works is OK-ish, when the product itself is of an OK-ish quality. When the product is really bad, the QA is powerless to initiate a fix. QA isn't trusted enough, and, usually, is perceived as a liability, and furthermore, stuffed with engineers nobody else wants. Unless this is changed, the pathologically bad products (like the Blackboard) will have no hope of ever improving (eventually, they will just die either under their own weight, or replaced by something else).
Humans have value judgement. AI doesn't. AI doesn't "know" what good code even is. For something to be good, there has to be a purpose. Good is the measure of how well that purpose is fulfilled.
Humans can write better or worse code, but AI is not even in the category of things that can write better or worse code. A human needs to be there to tell bad code from good code.
* * *
Also, in my personal experience with AI code: I'm yet to see good code (but I haven't worked with people who are good at directing AI towards their goals). All code I've seen generated by AI so far ranged from "absolute garbage" to "passable". Which, most likely, reflects the ability of those who managed the tool: before they did that, their code was also atrocious. It was easier to deal with, because the velocity at which these people produced garbage didn't cause a deluge in the same way they do it with AI help.
* * *
A note on what I believe to be good code and its distribution. First of all, I agree with you on that the vast majority of code produced to date is very bad. There are many reasons for it: until few years ago the demand for programmers was smaller than supply and the industry was on course to create conditions for very bad programmers to succeed anyhow (help the losers lose less, tee-hee!). It still didn't recover from all the "paradigms" it created to support bad programmers.
Unlike in well-established fields, where you'd expect normal distribution in terms of how skillful the workers are (i.e. you'd expect very few to be very bad and very few to be very good, but most would be good enough), the distribution in programming is exponential: overwhelming majority are at the proverbial bottom of the barrel, only a few are OK, and you probably will never meet a truly good one. This defies intuition and leads us to assume that the barely palatable is the best it can possibly be. And that's, roughly, where AI is at at the moment.
I haven't seen this mentioned, but... let's talk for a moment about testing automation, and what pain it is to test GUI programs that are mouse-first... It is coincidental, but, in reality, it's pretty much a given, that a program that can be controlled through keyboard will be a lot easier to automate (not only for testing) because of the choice.
A typical way of doing things in a GUI program is to handle "events". The framework arranges for event delivery. The event has properties s.a. what UI element registered it and the sort of mouse action performed, and the handler code specializes on that combination to take the (hopefully) intended action.
When it comes to testing, in order to emulate such events, one would have to calculate the location of the element that "registered" the desired event in order to trigger the desired functionality. This is usually very hard to do because elements change their positions on screen, it can depend on screen resolution, display style of scrollbars and so on.
Another problem with the event-driven model is that it's typically asynchronous. The automation code has no good way of telling when the action associated with the even should take place, or, rather, when it should finish taking place, to assess the results.
Typically, programs controlled through keyboard expose functions associated with desired functionality (because they need to bind something to the key). The test automation then can call these functions instead of emulating events. The detection of the moment when the action finished execution thus becomes trivial.
I'll try with an example first, and then will try to extrapolate to something more general.
I'm a longtime Emacs user and I detest tools like VSCode (VSCode in particular) because they aren't fully keyboard driven. "Fully" is the important part here. You can do a lot of things with keyboard in VSCode, but every now and then there isn't a way to do what you want without the mouse. And it screams "bad (no) design". For example, jumping between different panes in the editor is not always possible without a mouse, or the path to doing it is too long.
Before my attempt at generalization, I also want to address these:
> UIs like CLI or TUI suffer terrible discoverability
They typically do, but they don't have to. The reason for making a CLI and, to a lesser extent, TUI is the development speed. A full graphical interface will take longer to develop. So, whoever ends up making a CLI or a TUI tends not to invest time into accessibility either, because their goal was to save time on the UI in the first place.
Another aspect of this problem is the baseline knowledge. Users of graphical interfaces know how to discover functionality, they recognize familiar controls and patterns, they know that a cogwheel icon is likely to be a gateway to a program's settings, that if they want to make their changes persist, they need to look for something that looks like an open folder, or maybe a diskette icon...
Emacs has absolutely amazing discoverability. No program with graphical interface ever made doesn't hold a candle to what Emacs can do. But the user needs to have the baseline knowledge to... ironically, discover the discoverability. And I don't think there's a way to bootstrap from this problem. The minimal knowledge necessary to discover Emacs' features must come from reading the manual or asking a friend etc. Just to give you a few examples: Emacs can easily display all, without exception, keys and associated functionality available in the current editor's layout. It can also display them per individual component (if you, for example, knew that a key was defined, but was missing from the aforementioned list). You could also use the function name, if known, to find what key it binds to in the current layout. You can easily discover what any key (combination) does in the current layout without actually trying it (rather reading its documentation).
> can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?
Absolutely! If we commit to a general set of rules that allow bootstrapping. This would require a degree of uniformity between such tools and, perhaps, some visual or even physical aids in the computer periphery to make this work. Computer interfaces, both physical and on-screen, evolved to support mouse-first UIs. For example, the navigation arrows on the keyboard are virtually never drawn on jklm etc. The keyboard is presented to its users as a tool solely designed for entering text, not a tool to engage UI controls. Compare this to gamers' keyboards that often emphasize wasd keys (because they are often used for moving your character in games) or even more extreme designs like Nostromo that are geared towards typical game interface.
* * *
Being keyboard-driven isn't about, as you said, having a shortcut assigned to an action. This is not how good keyboard-driven programs work. This is the way of thinking if your baseline experience is a GUI, which must be somehow retrofitted into the world with the keyboard as a primary driver.
Keyboard-driven, to me, means that the program has a systematic, hierarchical and consistent approach to deal with the keyboard input. Assigning keys to actions at random will quickly overload the user's ability to memorize such bindings. A keyboard-driven program is designed to have a system that the user can internalize and use to predict the right key for the desired action. Such a program should make no exceptions when binding actions to keys: any action should be accessible in a reasonable small number of keystrokes.
Hey. I worked there, and I'm no longer bound by their PR policy, so I can mention this. Also, know that the fact that I worked there doesn't make me privy to their high-level strategic decisions, this is a more look from the trenches kind of thing.
My impression I've developed in the years of working there is that Nvidia's relationship with opensource is... not intentional. They kinda suck at it because they genuinely don't know how to do it more than they want to make money out of it.
Here's an anecdotal "success story" which is also an illustration to how things might not work out well otherwise.
So, I was on the team that deals with server infrastructure. One day we get a new "feature" which was supposed to allow Slurm (the workload manager, a kind of software used to run "jobs", including eg. model training) to be deployed with distributed MySQL as a backend. The feature is all obviously written by a single developer with an enormous amount of "help" from AI. I was tasked with testing it.
Trying to figure out what it does... I realized that the "distributed" part of the feature was to be achieved by integrating with Oracle's MySQL by means of using MySQLShell (another proprietary Oracle's product). Until that point, by default, we integrated with MariaDB. Not only was it using Oracle's proprietary tool, the tool, actually, didn't support the "distributed" part of the "solution". It was pitched as the "first step on the way there".
So, I was able to push back on it, mentioning Galera, arguing that the "solution" doesn't solve the problem and will require from customers to change databases (even if they are mostly compatible... they never quite 100% compatible). And the misfeature was rolled back.
I made an effort to investigate how did we even get there, and turned out that whoever authored the "solution" had an experience of working with Oracle products, but never really tried the open-source ones. So, he didn't do a research. He just used what he knew.
Unfortunately, this is a rare win, where the evidence of disadvantages of using proprietary solution was huge and enough to turn the tide. But often it doesn't face any resistance because nobody is even aware of the problem.
If that's true, it may bode well for the future. The AI boom creates some strong incentives for Nvidia to develop an intentional strategy for software generally and FOSS specifically, and there's a chance that could influence the rest of the company in a very positive direction. Hopefully, what they learn by working with HF and having the value of their hardware products increasingly determined by their ability to run FOSS software stacks will backwash into the rest of the company, or at least make them much more aware of the problem at all levels.
I do think that they still might be a bit reticent to release fully open-source drivers, though, only because of the extent to which hardware design could be inferred from the driver source. OTOH, AI itself is making disassembling and reverse engineering binary code easier and easier, so there might not be much of a point to withholding the source in the near future.
I couldn't help laughing a little at all those Russian phrases weirdly translated into English. Granted I probably sound like that too... at least I don't work for any intelligence service.
For the context: I think, English was the most commonly taught foreign language in the Soviet Union, and later in Russia. But, because nobody had access to the genuine English media, whatever we had to read or listen to was produced by Russian speakers who also never heard or never read genuine English, well, perhaps outside of very outdated prose from the 19th century or even earlier.
-- How much watch?
-- Six watch.
-- Such much?!
-- For whom how...
-- MGIMO finished?
-- A-a-a-ask!
The joke from that time, but, apparently, little has changed.
It's like having to sit through a party with acclaimed academics: every single one is so full of themselves, they will constantly one-up each other by belittling everyone in their workplace s.a. to make you feel how great of an intellect they possess and how much more they would accomplish, had they not been surrounded by all these bumbling idiots.
reply