10 ms·

Prescriptive software is better than descriptive software

170 points by sergiomattei 6y ago

api 6y ago
https://en.wikipedia.org/wiki/Decision_fatigue https://en.wikipedia.org/wiki/Decision_fatigue
fctorial 6y ago
Software intended to be used for programming should be descriptive and end-user software should be prescriptive. No matter how good your prescription system is, it is going to be a bad fit for some programmers use case.
andreareina 6y ago
s/descriptive/proscriptive/g I think. Descriptive doesn't attach value to the observations, while "hey that's wrong" definitely does.
- singlow 6y ago
  Agree. I see the concept but the analogy to grammar terminology doesn't quite fit. I'd suggest _corrective_.
- ed312 6y ago
  What does this notation mean: "s/descriptive/proscriptive/g" ?
  - cochne 6y ago
    This means find and replace descriptive with proscriptive. It is a pattern used by Vim and Sed, and probably some other programs.
    - virgil_disgr4ce 6y ago
      It's regex, vim and sed just happen to use it
  - Jtsummers 6y ago
    Substitute <pattern> with <replacement> globally. https://www.gnu.org/software/sed/manual/html_node/The-_0022s_0022-Command.html https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
  - adwn 6y ago
    Replace all occurrences of 'descriptive' with 'proscriptive'
  - pdkl95 6y ago
    It's originally from sed's "s"ubstitute command[1], and later incorporated into many other tools. The "s" at the front is the command name, which is followed by two sections delimited by "/"; these are regex pattern that is matched on the input, and the replacement string. The final "g" is an optional "global" flag that requests that all matches inthe input should be substituted, instead of only the first. s/ ...matching regex... / ...replacement string... /g The use in the parent post therefor means: "Replace every 'descriptive' in the text with the string 'proscriptive'." [1] https://www.gnu.org/software/sed/manual/html_node/The-_0022s_0022-Command.html https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
- deleted 6y ago
  [deleted]
- virgil_disgr4ce 6y ago
  Although in the beginning of the post the author says "tooling that will tell you everything you do wrong" (which I agree would be 'proscriptive') other parts talk about UNopinionated ('descriptive', though now that I think about it might as well just stick with 'unopinionated') software ("The choice is between your rules and no rules"). So I guess really they're talking about 3 things.
kilian 6y ago
Thanks for sharing this! The concept has been in my mind for well over a decade (initially with the decision to make https://trimage.org https://trimage.org not have any settings) but it's really been taking shape the past few years. We hire software to do jobs like how we hire people to do jobs. Both become better when they share their opinion and help us decide how to fix or approach issues.
esjeon 6y ago
I thought about this topic many times too, but I believe neither is better than the other. Below is just my personal idea, nothing really well founded. “Descriptive” software accelerates exploration, and “prescriptive” software is a lower-complexity implementation, either a prototype or optimized for specific purpose. While “prescriptive” normally offers better performance (for the purpose it is designed for), “descriptive” tends to linger around longer because of it flexibility, but neither is permanent anyway. Making a progress is merely going through those two back and forth again and again. There’s no end.
pca006132 6y ago
Prescriptive software would be much better for beginners and for those who rarely use the tools and just want to get the job done. I think that is why things like VSCode, emacs framework, get popular. Most of us don't want to spend a long time configuring the tools, but just get the job done. For most of us, a sane default is more than enough.
- sumtechguy 6y ago
  I am currently fighting one of these 'sane defaults'. It is sane for one of the programs the output data goes into. Yet for a different program (and per spec) it is a different default expected. Hey they have a spot to change that default (sweet!). Except all of the plugins, and mainline code itself does not use that (ugh!). It is a ranges from hard coded, to using a different default, to using the configurable one. So here I am writing yet another plugin to override what these other plugins did. Usually like you said though 99.9% of the time it is just fine the way it is.
- rightbyte 6y ago
  > emacs framework ... don't want to spend a long time configuring the tools Are you sarcastic? Edit: Extended quote
  - exdsq 6y ago
    To be honest even my vscode config is fairly large. I think the write comparison would be with PyCharm/Goland/etc - ‘proper’ IDEs with everything built in.
  - anaerobicover 6y ago
    You dropped the critical word from that quote, "framework". The point they're making is that people use Emacs frameworks like Doom, Prelude, Spacemacs... to lessen the configuration they do compared to "plain" Emacs.
    - rightbyte 6y ago
      Ah ok didn't make that connection.
teodorlu 6y ago
I prefer using tools like Linux, Emacs and the terminal because those tools are not prescriptive. Instead, they are flexible. I can mold them to my needs. That flexibility brings a cost of learning, which I'm willing to spend. On the other hand, I like using my Remarkable because it's just for handwritten notes and annotated documents. I wouldn't say that prescriptive is better than descriptive, or the opposite. As much as dislike the phrase, it depends. I want my fundamental tools to be flexible. But I don't want to waste all my time configuring stuff.
- npsimons 6y ago
  Thing is, the learning curve may be steep, but it's incredibly valuable, time very well spent. I learned VI on some UNIX tools my father installed on our DOS computer in the 90's. Then I learned Emacs in 2000 and have been tweaking my setup ever since. Sure, it's not perfect, every few years when I have some down time I will spend a day fiddling with things heretofore unlearned, but the general setup has worked well (and gotten better) for two decades. How many other editors have come and gone in that time?
  - coldtea 6y ago
    >Thing is, the learning curve may be steep, but it's incredibly valuable, time very well spent. Is it? Or is it mostly the IKEA effect ("I spent time on this, so it must be valuable") and busywork? Was anybody's choice of editor really a major point in their developer progress and productivity?
    - passivate 6y ago
      For me, I do regret the countless hours I wasted learning vi. Back when I was a C++ developer, editing text was a tiny, minuscule portion of what I did. The overwhelming vast majority of time was spent reading, navigating, debugging, discussing, and explaining code. When I did switch to a mainstream IDE (Visual Studio + Visual Assist X), I was far far more productive in all areas that mattered to me. And so, even if I was born an expert vi user, I don't think I would have gotten any boost in productivity as a developer. Just my opinion though! :) (Yes, I know how you can get vi editing in VS. I purchased a copy of ViEmu.)
cjohansson 6y ago
The is–ought problem is a philosophical problem of how knowledge of the present world does not necessarily lead to knowledge of how the world ought to be. This is also sometimes referred to as Hume's law or "Hume's Guillotine".[2] https://rationalwiki.org/wiki/Is%E2%80%93ought_problem https://rationalwiki.org/wiki/Is%E2%80%93ought_problem
- bordercases 6y ago
  This concept is too abstract for what the post is actually pointing at, which is the tradeoff between expressivity of a language vs consistency in language use, and the cognitive load required to move from the former to the latter when developing software. Here the is-ought distinction breaks down since the state-of-affairs is almost entirely decidable by humans. At that point it's a question of comparing different oughts since the constraints involved are not based in nature, but convention.
nickthemagicman 6y ago
I love this concept. I've always thought if it in the context of the Pareto principle. 80% of the time people will use the defaults but 20% of the time will need more customization.
deleted 6y ago
[deleted]
saurik 6y ago
Look, I do appreciate this thought process: there is certainly a time and a place for opinionated software; as the article states, if you are trying to fully outsource a problem to someone else--preferably someone who will take that problem seriously (unlike the trope of frameworks that claim "I'll solve your browser compatibility issues!" and then aggressively deprecate browsers)--or you are trying to force a decision on others and need an excuse to not waste much time on it (though, this honestly feels low key abusive), well then I totally feel for this thought process: having something just tell me what to do for my own good can be great. But then you find articles like this, which take it to the point of pushing opinionated software principals as its own opinion, framing such design as universally "better" and that that is how software "should" be written... I find myself unable to just sit idly by and not respond to such a thought--seeing where it is on the HN front page--without at least some kind of rebuttal, as it is a thought that I find actively harmful for trying to not just invite people to consider their options, or think about the tradeoffs in what they are trying to accomplish, but to try to actively discourage people from building software that adds value to the world in the form of doing something someone other than the developer wanted done. The world of this article--where everything is "use it or don't"--is a world full of wrong-handed scissors, one-size-fits-many clothing, single-station radios, and "no substitutions" menus that are simultaneously prix fixe. This is a world where people who show up saying "I know I could be X% more effective (or even simply happier) if only your software did Y" are told "you don't know what you are talking about; and, even if you somehow did, you should learn to make do without as that's the austere thing to do". This is a world where not only is everyone working at merely an average level of efficiency, but no one gets to enjoy the art or experience of doing anything, as a world without color is supposedly a world with less stress. To enter the same narrative frame as this author: if I hire software, I want that software to be working for me. I often do know what I need to be effective, and I'm hiring software to do that job: if by any of the developer's hubris, incompetence, or laziness, the software is incapable of doing the thing I wanted it to do the way I needed it done, I'm going to either hack their masterpiece until it works the way I want it to, or I'm going to fire it and find (yes) a "better" piece of software. FWIW, in this way, I'm lucky: I can build my own software, and I can modify your software (even if it is closed source!)... not everyone can. And that's where I feel like this is most dangerous: that software developers are effectively building the world for everyone else, and when we drink the kool-ade of these "opinionated" manifestos, we begin to believe that we are best able to decide how things should work for everyone: that there is one way to best edit videos, or write documents, or compose music. We should listen to our users--even if they are other developers--to learn what would empower them and make them effective, and then add enough settings (or extension points or whatever: "even software should have screws"! https://www.youtube.com/watch?v=ReKCp9K_Jqw https://www.youtube.com/watch?v=ReKCp9K_Jqw) to let them feel like themselves. Because the alternative is just sad :(. Again: there is a time and a place for being opinionated, and it isn't that I'm saying that concept is always broken... but there is maybe nothing more infuriating than something that is almost perfect, and the decision to resist having settings or options in your software because of a claim that they are some kind of cop out instead of an admittance that people have different needs, interests, or understandings, is the kind of "opinion" I have opinions about. Remember: "Opinions are like assholes: everyone has one, but they think each others stink." -- Simone Elkeles
Pxtl 6y ago
I fell like the terminology here is too vague... Opinionated vs configurable seems clearer than prescriptive vs descriptive.
hammock 6y ago
Prescriptive vs descriptive is a false dichotomy, or at least there is a third way missing. Take for example Apple vs. Microsoft/Android. The PC-environment is legendarily descriptive. But the Apple environment is not prescriptive. It's just "intuitive" (for those who buy into it), or, less charitably, it hides the descriptions while at the same time not being explicitly prescriptive either. What do we call this Apple system? It's neither prescriptive nor descriptive.
- lolsal 6y ago
  I think 'discoverable' is one of the big Apple tenants of design, or it used to be (but I am not a designer).
  - ziml77 6y ago
    I think they still try for that. A few days ago my internet connection went out. I needed to get my laptop back online so I decided to tether. As someone who had been an Android user for a decade I first went to my iPhone and started navigating to the settings when I stopped and realized I should think about where a normal user would first check to tether. I put my phone down, went back to my laptop, and clicked the wireless icon in the menu bar. First option after the wifi toggle was "Personal Hotspot" along with info about the iPhone's current connectivity and battery. To me that was a wonderfully discoverable and seamless experience.
deleted 6y ago
[deleted]
0wis 6y ago
I clearly have a need for this about software as I am not a pro dev. I just had the same conversation with a med worker this weekend. Some patients just want prescription and anything more will annoy them. Others will need a description to accept a diagnostic. I assume we, hackers, will tend to prefer the latter but I’m not sure it’s for the best to be like this in every area of your life. [edit : typo]
waffletower 6y ago
Yes.. we need more fiefdoms. More prisons. More machined conformity.
deleted 6y ago
[deleted]
taeric 6y ago
Issues of whether this is prescriptive or not aside, I think this hits close to a paulg tweet: https://twitter.com/paulg/status/1378646213113868289 https://twitter.com/paulg/status/1378646213113868289 Of course, I think this whole idea is basically flirting the same thoughts as "sensible defaults" and "paradox of choice". Which is somewhat of an ironic fight between having all of the options, but not requiring all of the options. A hedge, if you will, around what you may want to do in the future.
iandanforth 6y ago
FWIW This is exactly why I don't use black (opinionated Python formatter) or let it get into the org. It's great until it's not and then you're kinda screwed. My favorite example of a good balance here is React's 'dangerouslySetInnerHTML'. Clear opinion, check, but you've got the escape hatch you need.
- jraph 6y ago
  To be clear, you disagree with the article then, right? > It's great until it's not and then you're kinda screwed Do you have some example? Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I've seen places where I don't quite like what black enforces, but this is very rare and it is a matter of taste and you get used to things, so meh. In contrast, standard (for JS) seems opinionated at first does not come remotely close and leaves many things without opinion, and unfortunately we don't have the same opinions and tastes, so we regularly argue over them and this is a waste of time. I don't actually quite like standard's rules but since this is what we use, I wish it were much more opinionated (over brace position in React files, line length, how obj.hasOwnProperty should be banned, how to declare methods in React components, how order imports should be sorted alphabetically, or which variable we can deconstruct…).
  - Rule35 6y ago
    > Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I hear this all the time, along with 'Juniors will be confused' but it never seems reasonable. Sometimes I line up variables: name_field_id = 0x01 address_field_id = 0x02 Sometimes I don't. I do it when the cognitive load is more on the values or the identifiers, as a group. No tool is going to help with this judgement call. Sometimes stuffing a method on one line is best because you get ten boilerplate methods on ten lines and can see the similarity, other times that's just silly and they'd be best spaced normally. Sometimes I use a rightward assignment { ... } => x because it fits the code better, leaving the reference to x right next to the next statement which will use it. > so we regularly argue over them and this is a waste of time. Strange disfunction. It sounds like your team is too opinionated to allow other opinions. > I wish it were much more opinionated Suggest turning on more rules but leaving them as suggestions. Where any reason to not follow them is enough. You do want to make sure people have some reason to make sure they aren't just leaving a mess but it's easier to get them to care about style if they have a say in what clean looks like. As an aside, part of the issue is comfort with the tooling. If I have to work in someone else's file and I hate the syntax and it's a big deal, I first run the linter to make the code look my way, make the change, run the linter to go back to their style, squash it onto my change, and rebase away the first lint. Work done, no problems dealing with someone else's style - even in the case that it would otherwise be a problem. I never have to, but because I can it doesn't bug me.
tdfirth 6y ago
Like just about everything in life it is more nuanced than that. There is a time, a place, and a market for both opinionated and highly configurable software. Claims that one is better than another can only ever be opinion. The title aside, I don't actually disagree with anything in the article. I've had similar experiences to the author with tools like linters and formatters. Agreeing on configuration for them can waste a surprising amount of time. As time goes on, I do find myself more willing to change to fit my tools rather than change them to fit me. Often, I find the creator of an opinionated tool has more carefully thought through their opinions than I have anyway. Even if they haven't, tools like gofmt showcase the power of consistency for consistency's sake. That said, I use a tiling window manager and I'm pretty insistent that control belongs where caps lock normally is, so clearly I'm not entirely bought in to my own rhetoric.
beckingz 6y ago
"But you wouldn’t hire a consultant that only tells you what’s wrong but not how to improve it." People do this all the time.
kansface 6y ago
The author is really making an argument for bypassing institutional inertia or vestigial process via tool selection rather than a robust argument for opinionated tooling... which is very easy to agree with. To the extent to which your org is incapable of making decisions, don’t force it to make dozens of low risk/low reward decisions! If you are able to move quickly, a better fitting puzzle piece may be more valuable.
ghoward 6y ago
I disagree. I think this is the same "mechanism, not policy" debate repackaged, and I certainly think mechanism is better than policy, where the author of the post thinks otherwise. That said, I think that going all-in on "mechanism, not policy" is a mistake too. I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to. I wrote more about this idea in https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-ease-matters/ https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-... .
- taeric 6y ago
  Reading your post, it brings to mind that a lot of this is around what we are controlling. As a physical example, I can't remember the last time we had to educate people on how to "pump your brakes" in the rain. Turns out, there are flat out better mechanisms to control for some of these things. I suspect many lane assist technologies and other mechanisms to eventually grow to eclipse environments that lack them. But, bringing that back to the software world is hard. There are things that we don't give a second thought to in a lot of what we do. Endianness is an easy example of something that you used to not be able to avoid. How do we get more of our concerns across that line? Can we?
  - ghoward 6y ago
    You make great points. However, I still have learned how to pump brakes in rain, and I taught it to my wife. The reason is that the better mechanism, anti-lock braking systems in this case, can always fail. Joel Spolsky had a whole post about this: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... . If we only teach the happy path, we are setting ourselves and everyone else up for failure when the happy path fails, which it will. As another counterpoint, there is so much automation in modern airplanes that pilots are relying too much on the automation and losing their basic airmanship skills. (https://www.nbcnews.com/news/us-news/airline-pilots-depend-too-much-automation-says-panel-commissioned-faa-flna2D11625301 https://www.nbcnews.com/news/us-news/airline-pilots-depend-t...) I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Basically, at some point, putting more concerns across the line is a bad idea because we will eventually lose the ability to handle things when they go wrong. We also lose institutional knowledge. (https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko)
jayd16 6y ago
I'm all for LINTers but its not exactly a paradigm shift. Though, I am excited about Roslyn Analyzers and how dotnet seems to be pulling together a language standard LINT system. https://github.com/dotnet/roslyn-analyzers https://github.com/dotnet/roslyn-analyzers
elihu 6y ago
> I think software should be opinionated. Throwing everything in a huge settings panel or configuration file and calling it “choice” or “not imposing your preferences” is a product development failure. I think the ideal is that the software is as configurable as it needs to be in order to be useful to the people that use it, but that there's a standard configuration with sensible defaults.
- ZephyrBlu 6y ago
  I think that ideal is extremely difficult to reach without it turning into the situation you quoted.
jeffreygoesto 6y ago
I read the article as "error messages should rather be a beginning than an end" message. Nobody wants a program to fail, that is not why you put effort to configure and start it in. An error just describing what happened puts the load to fix or how to "heal" it onto the user. She needs a mental model of why the program failed and what to do to make it succeed. What I interpret "prescriptive" to be is that the message returned to the user on failure should give some hints how to make the program succeed. Because there are more ways to fail than the program author could think of, or more than fit on a screen, it is opinionated which advice to give then (a subset of all known and unknown possible fixes). I always tell my coworkers, an error message is a call for action, not an out-of-jail-I-just-stop-here card. The better you guide the user, the more efficient she can use our software.
orasis 6y ago
I think the library vs framework lens is more productive. Write libraries, not frameworks: https://www.brandonsmith.ninja/blog/libraries-not-frameworks https://www.brandonsmith.ninja/blog/libraries-not-frameworks
EGreg 6y ago
The best software is one where you have total flexibility and composability, and great default configurations for n00bs to get started with. In fact, the configuration language would be the "programming language" for many in dev ops, orchestration, and so on.
lmilcin 6y ago
This is shortsighted. There is place for prescriptive as well as descriptive components. The huge issue with components that don't give you much choice is that they do not compose well. You find two components clash on some decision and neither has any mechanism to resolve the issue. This is frequently the case with "frameworks", which tend to want to control all aspects of your application. Does this make your life simpler? Sure, but only if your application is exactly or very closely to what the author of the framework envisioned. On the other hand there are "tools/utilities". These can fit same role/functionality as "frameworks", but they are not intrusive, don't tell you how to put your application together. Rather, they give you tools with assumption you will know how to use them. Does this make your life simpler? SURE If you have non-standard application and you know what you are doing you want to compose your application from tools that do not demand too much from the structure of application, dependencies, etc. If you are novice developer it might be temporarily useful to use more prescriptive tools. You don't know how to put stuff together so you might just as well learn how others do it. If you are advanced you will know what to use. If I know I will be working on a very standard application I might just as well use something that takes care of it all for me.
beaker52 6y ago
It's fun to customise and learn, but going forward I'd rather defer to sensible defaults so that I can spend my thought cycles on solving software problems, rather than fixing all the weirdness that arises from my customisation. I'm a big fan of Prettier for this very reason. It just works. It's decent. It lets everyone get on with writing software. If a project has ESLint, there's a high chance I'm going to be talking about semi-colons, or looking at oddly line-broken code. Someone else is going to notice it too, and want to fix it. Then we're all talking about the Airbnb config and what customisations we're going to make. In recent years I've: - Quit using Colemak and gone back to Qwerty - Stopped using vim and went back to IntelliJ - Stopped using custom fonts, themes and just stuck to defaults - Become more selective about what plugins I use And I'm suprisingly (or unsurprisingly) more productive.

170 points by sergiomattei 6y ago

api 6y ago

https://en.wikipedia.org/wiki/Decision_fatigue https://en.wikipedia.org/wiki/Decision_fatigue

Software intended to be used for programming should be descriptive and end-user software should be prescriptive. No matter how good your prescription system is, it is going to be a bad fit for some programmers use case.

andreareina 6y ago

s/descriptive/proscriptive/g I think. Descriptive doesn't attach value to the observations, while "hey that's wrong" definitely does.

singlow 6y ago
Agree. I see the concept but the analogy to grammar terminology doesn't quite fit. I'd suggest _corrective_.
ed312 6y ago
What does this notation mean: "s/descriptive/proscriptive/g" ?
- cochne 6y ago
  This means find and replace descriptive with proscriptive. It is a pattern used by Vim and Sed, and probably some other programs.
  - virgil_disgr4ce 6y ago
    It's regex, vim and sed just happen to use it
- Jtsummers 6y ago
  Substitute <pattern> with <replacement> globally. https://www.gnu.org/software/sed/manual/html_node/The-_0022s_0022-Command.html https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
- adwn 6y ago
  Replace all occurrences of 'descriptive' with 'proscriptive'
- pdkl95 6y ago
  It's originally from sed's "s"ubstitute command[1], and later incorporated into many other tools. The "s" at the front is the command name, which is followed by two sections delimited by "/"; these are regex pattern that is matched on the input, and the replacement string. The final "g" is an optional "global" flag that requests that all matches inthe input should be substituted, instead of only the first. s/ ...matching regex... / ...replacement string... /g The use in the parent post therefor means: "Replace every 'descriptive' in the text with the string 'proscriptive'." [1] https://www.gnu.org/software/sed/manual/html_node/The-_0022s_0022-Command.html https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
deleted 6y ago
[deleted]
virgil_disgr4ce 6y ago
Although in the beginning of the post the author says "tooling that will tell you everything you do wrong" (which I agree would be 'proscriptive') other parts talk about UNopinionated ('descriptive', though now that I think about it might as well just stick with 'unopinionated') software ("The choice is between your rules and no rules"). So I guess really they're talking about 3 things.

kilian 6y ago

Thanks for sharing this! The concept has been in my mind for well over a decade (initially with the decision to make https://trimage.org https://trimage.org not have any settings) but it's really been taking shape the past few years. We hire software to do jobs like how we hire people to do jobs. Both become better when they share their opinion and help us decide how to fix or approach issues.

esjeon 6y ago

I thought about this topic many times too, but I believe neither is better than the other. Below is just my personal idea, nothing really well founded. “Descriptive” software accelerates exploration, and “prescriptive” software is a lower-complexity implementation, either a prototype or optimized for specific purpose. While “prescriptive” normally offers better performance (for the purpose it is designed for), “descriptive” tends to linger around longer because of it flexibility, but neither is permanent anyway. Making a progress is merely going through those two back and forth again and again. There’s no end.

pca006132 6y ago

Prescriptive software would be much better for beginners and for those who rarely use the tools and just want to get the job done. I think that is why things like VSCode, emacs framework, get popular. Most of us don't want to spend a long time configuring the tools, but just get the job done. For most of us, a sane default is more than enough.

sumtechguy 6y ago
I am currently fighting one of these 'sane defaults'. It is sane for one of the programs the output data goes into. Yet for a different program (and per spec) it is a different default expected. Hey they have a spot to change that default (sweet!). Except all of the plugins, and mainline code itself does not use that (ugh!). It is a ranges from hard coded, to using a different default, to using the configurable one. So here I am writing yet another plugin to override what these other plugins did. Usually like you said though 99.9% of the time it is just fine the way it is.
rightbyte 6y ago
> emacs framework ... don't want to spend a long time configuring the tools Are you sarcastic? Edit: Extended quote
- exdsq 6y ago
  To be honest even my vscode config is fairly large. I think the write comparison would be with PyCharm/Goland/etc - ‘proper’ IDEs with everything built in.
- anaerobicover 6y ago
  You dropped the critical word from that quote, "framework". The point they're making is that people use Emacs frameworks like Doom, Prelude, Spacemacs... to lessen the configuration they do compared to "plain" Emacs.
  - rightbyte 6y ago
    Ah ok didn't make that connection.

teodorlu 6y ago

I prefer using tools like Linux, Emacs and the terminal because those tools are not prescriptive. Instead, they are flexible. I can mold them to my needs. That flexibility brings a cost of learning, which I'm willing to spend. On the other hand, I like using my Remarkable because it's just for handwritten notes and annotated documents. I wouldn't say that prescriptive is better than descriptive, or the opposite. As much as dislike the phrase, it depends. I want my fundamental tools to be flexible. But I don't want to waste all my time configuring stuff.

npsimons 6y ago
Thing is, the learning curve may be steep, but it's incredibly valuable, time very well spent. I learned VI on some UNIX tools my father installed on our DOS computer in the 90's. Then I learned Emacs in 2000 and have been tweaking my setup ever since. Sure, it's not perfect, every few years when I have some down time I will spend a day fiddling with things heretofore unlearned, but the general setup has worked well (and gotten better) for two decades. How many other editors have come and gone in that time?
- coldtea 6y ago
  >Thing is, the learning curve may be steep, but it's incredibly valuable, time very well spent. Is it? Or is it mostly the IKEA effect ("I spent time on this, so it must be valuable") and busywork? Was anybody's choice of editor really a major point in their developer progress and productivity?
  - passivate 6y ago
    For me, I do regret the countless hours I wasted learning vi. Back when I was a C++ developer, editing text was a tiny, minuscule portion of what I did. The overwhelming vast majority of time was spent reading, navigating, debugging, discussing, and explaining code. When I did switch to a mainstream IDE (Visual Studio + Visual Assist X), I was far far more productive in all areas that mattered to me. And so, even if I was born an expert vi user, I don't think I would have gotten any boost in productivity as a developer. Just my opinion though! :) (Yes, I know how you can get vi editing in VS. I purchased a copy of ViEmu.)

cjohansson 6y ago

The is–ought problem is a philosophical problem of how knowledge of the present world does not necessarily lead to knowledge of how the world ought to be. This is also sometimes referred to as Hume's law or "Hume's Guillotine".[2] https://rationalwiki.org/wiki/Is%E2%80%93ought_problem https://rationalwiki.org/wiki/Is%E2%80%93ought_problem

bordercases 6y ago
This concept is too abstract for what the post is actually pointing at, which is the tradeoff between expressivity of a language vs consistency in language use, and the cognitive load required to move from the former to the latter when developing software. Here the is-ought distinction breaks down since the state-of-affairs is almost entirely decidable by humans. At that point it's a question of comparing different oughts since the constraints involved are not based in nature, but convention.

nickthemagicman 6y ago

I love this concept. I've always thought if it in the context of the Pareto principle. 80% of the time people will use the defaults but 20% of the time will need more customization.

deleted 6y ago

[deleted]

saurik 6y ago

Look, I do appreciate this thought process: there is certainly a time and a place for opinionated software; as the article states, if you are trying to fully outsource a problem to someone else--preferably someone who will take that problem seriously (unlike the trope of frameworks that claim "I'll solve your browser compatibility issues!" and then aggressively deprecate browsers)--or you are trying to force a decision on others and need an excuse to not waste much time on it (though, this honestly feels low key abusive), well then I totally feel for this thought process: having something just tell me what to do for my own good can be great. But then you find articles like this, which take it to the point of pushing opinionated software principals as its own opinion, framing such design as universally "better" and that that is how software "should" be written... I find myself unable to just sit idly by and not respond to such a thought--seeing where it is on the HN front page--without at least some kind of rebuttal, as it is a thought that I find actively harmful for trying to not just invite people to consider their options, or think about the tradeoffs in what they are trying to accomplish, but to try to actively discourage people from building software that adds value to the world in the form of doing something someone other than the developer wanted done. The world of this article--where everything is "use it or don't"--is a world full of wrong-handed scissors, one-size-fits-many clothing, single-station radios, and "no substitutions" menus that are simultaneously prix fixe. This is a world where people who show up saying "I know I could be X% more effective (or even simply happier) if only your software did Y" are told "you don't know what you are talking about; and, even if you somehow did, you should learn to make do without as that's the austere thing to do". This is a world where not only is everyone working at merely an average level of efficiency, but no one gets to enjoy the art or experience of doing anything, as a world without color is supposedly a world with less stress. To enter the same narrative frame as this author: if I hire software, I want that software to be working for me. I often do know what I need to be effective, and I'm hiring software to do that job: if by any of the developer's hubris, incompetence, or laziness, the software is incapable of doing the thing I wanted it to do the way I needed it done, I'm going to either hack their masterpiece until it works the way I want it to, or I'm going to fire it and find (yes) a "better" piece of software. FWIW, in this way, I'm lucky: I can build my own software, and I can modify your software (even if it is closed source!)... not everyone can. And that's where I feel like this is most dangerous: that software developers are effectively building the world for everyone else, and when we drink the kool-ade of these "opinionated" manifestos, we begin to believe that we are best able to decide how things should work for everyone: that there is one way to best edit videos, or write documents, or compose music. We should listen to our users--even if they are other developers--to learn what would empower them and make them effective, and then add enough settings (or extension points or whatever: "even software should have screws"! https://www.youtube.com/watch?v=ReKCp9K_Jqw https://www.youtube.com/watch?v=ReKCp9K_Jqw) to let them feel like themselves. Because the alternative is just sad :(. Again: there is a time and a place for being opinionated, and it isn't that I'm saying that concept is always broken... but there is maybe nothing more infuriating than something that is almost perfect, and the decision to resist having settings or options in your software because of a claim that they are some kind of cop out instead of an admittance that people have different needs, interests, or understandings, is the kind of "opinion" I have opinions about. Remember: "Opinions are like assholes: everyone has one, but they think each others stink." -- Simone Elkeles

Pxtl 6y ago

I fell like the terminology here is too vague... Opinionated vs configurable seems clearer than prescriptive vs descriptive.

hammock 6y ago

Prescriptive vs descriptive is a false dichotomy, or at least there is a third way missing. Take for example Apple vs. Microsoft/Android. The PC-environment is legendarily descriptive. But the Apple environment is not prescriptive. It's just "intuitive" (for those who buy into it), or, less charitably, it hides the descriptions while at the same time not being explicitly prescriptive either. What do we call this Apple system? It's neither prescriptive nor descriptive.

lolsal 6y ago
I think 'discoverable' is one of the big Apple tenants of design, or it used to be (but I am not a designer).
- ziml77 6y ago
  I think they still try for that. A few days ago my internet connection went out. I needed to get my laptop back online so I decided to tether. As someone who had been an Android user for a decade I first went to my iPhone and started navigating to the settings when I stopped and realized I should think about where a normal user would first check to tether. I put my phone down, went back to my laptop, and clicked the wireless icon in the menu bar. First option after the wifi toggle was "Personal Hotspot" along with info about the iPhone's current connectivity and battery. To me that was a wonderfully discoverable and seamless experience.

deleted 6y ago

[deleted]

0wis 6y ago

I clearly have a need for this about software as I am not a pro dev. I just had the same conversation with a med worker this weekend. Some patients just want prescription and anything more will annoy them. Others will need a description to accept a diagnostic. I assume we, hackers, will tend to prefer the latter but I’m not sure it’s for the best to be like this in every area of your life. [edit : typo]

waffletower 6y ago

Yes.. we need more fiefdoms. More prisons. More machined conformity.

deleted 6y ago

[deleted]

taeric 6y ago

Issues of whether this is prescriptive or not aside, I think this hits close to a paulg tweet: https://twitter.com/paulg/status/1378646213113868289 https://twitter.com/paulg/status/1378646213113868289 Of course, I think this whole idea is basically flirting the same thoughts as "sensible defaults" and "paradox of choice". Which is somewhat of an ironic fight between having all of the options, but not requiring all of the options. A hedge, if you will, around what you may want to do in the future.

iandanforth 6y ago

FWIW This is exactly why I don't use black (opinionated Python formatter) or let it get into the org. It's great until it's not and then you're kinda screwed. My favorite example of a good balance here is React's 'dangerouslySetInnerHTML'. Clear opinion, check, but you've got the escape hatch you need.

jraph 6y ago
To be clear, you disagree with the article then, right? > It's great until it's not and then you're kinda screwed Do you have some example? Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I've seen places where I don't quite like what black enforces, but this is very rare and it is a matter of taste and you get used to things, so meh. In contrast, standard (for JS) seems opinionated at first does not come remotely close and leaves many things without opinion, and unfortunately we don't have the same opinions and tastes, so we regularly argue over them and this is a waste of time. I don't actually quite like standard's rules but since this is what we use, I wish it were much more opinionated (over brace position in React files, line length, how obj.hasOwnProperty should be banned, how to declare methods in React components, how order imports should be sorted alphabetically, or which variable we can deconstruct…).
- Rule35 6y ago
  > Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I hear this all the time, along with 'Juniors will be confused' but it never seems reasonable. Sometimes I line up variables: name_field_id = 0x01 address_field_id = 0x02 Sometimes I don't. I do it when the cognitive load is more on the values or the identifiers, as a group. No tool is going to help with this judgement call. Sometimes stuffing a method on one line is best because you get ten boilerplate methods on ten lines and can see the similarity, other times that's just silly and they'd be best spaced normally. Sometimes I use a rightward assignment { ... } => x because it fits the code better, leaving the reference to x right next to the next statement which will use it. > so we regularly argue over them and this is a waste of time. Strange disfunction. It sounds like your team is too opinionated to allow other opinions. > I wish it were much more opinionated Suggest turning on more rules but leaving them as suggestions. Where any reason to not follow them is enough. You do want to make sure people have some reason to make sure they aren't just leaving a mess but it's easier to get them to care about style if they have a say in what clean looks like. As an aside, part of the issue is comfort with the tooling. If I have to work in someone else's file and I hate the syntax and it's a big deal, I first run the linter to make the code look my way, make the change, run the linter to go back to their style, squash it onto my change, and rebase away the first lint. Work done, no problems dealing with someone else's style - even in the case that it would otherwise be a problem. I never have to, but because I can it doesn't bug me.

tdfirth 6y ago

Like just about everything in life it is more nuanced than that. There is a time, a place, and a market for both opinionated and highly configurable software. Claims that one is better than another can only ever be opinion. The title aside, I don't actually disagree with anything in the article. I've had similar experiences to the author with tools like linters and formatters. Agreeing on configuration for them can waste a surprising amount of time. As time goes on, I do find myself more willing to change to fit my tools rather than change them to fit me. Often, I find the creator of an opinionated tool has more carefully thought through their opinions than I have anyway. Even if they haven't, tools like gofmt showcase the power of consistency for consistency's sake. That said, I use a tiling window manager and I'm pretty insistent that control belongs where caps lock normally is, so clearly I'm not entirely bought in to my own rhetoric.

beckingz 6y ago

"But you wouldn’t hire a consultant that only tells you what’s wrong but not how to improve it." People do this all the time.

kansface 6y ago

The author is really making an argument for bypassing institutional inertia or vestigial process via tool selection rather than a robust argument for opinionated tooling... which is very easy to agree with. To the extent to which your org is incapable of making decisions, don’t force it to make dozens of low risk/low reward decisions! If you are able to move quickly, a better fitting puzzle piece may be more valuable.

ghoward 6y ago

I disagree. I think this is the same "mechanism, not policy" debate repackaged, and I certainly think mechanism is better than policy, where the author of the post thinks otherwise. That said, I think that going all-in on "mechanism, not policy" is a mistake too. I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to. I wrote more about this idea in https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-ease-matters/ https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-... .

taeric 6y ago
Reading your post, it brings to mind that a lot of this is around what we are controlling. As a physical example, I can't remember the last time we had to educate people on how to "pump your brakes" in the rain. Turns out, there are flat out better mechanisms to control for some of these things. I suspect many lane assist technologies and other mechanisms to eventually grow to eclipse environments that lack them. But, bringing that back to the software world is hard. There are things that we don't give a second thought to in a lot of what we do. Endianness is an easy example of something that you used to not be able to avoid. How do we get more of our concerns across that line? Can we?
- ghoward 6y ago
  You make great points. However, I still have learned how to pump brakes in rain, and I taught it to my wife. The reason is that the better mechanism, anti-lock braking systems in this case, can always fail. Joel Spolsky had a whole post about this: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... . If we only teach the happy path, we are setting ourselves and everyone else up for failure when the happy path fails, which it will. As another counterpoint, there is so much automation in modern airplanes that pilots are relying too much on the automation and losing their basic airmanship skills. (https://www.nbcnews.com/news/us-news/airline-pilots-depend-too-much-automation-says-panel-commissioned-faa-flna2D11625301 https://www.nbcnews.com/news/us-news/airline-pilots-depend-t...) I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Basically, at some point, putting more concerns across the line is a bad idea because we will eventually lose the ability to handle things when they go wrong. We also lose institutional knowledge. (https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko)

jayd16 6y ago

I'm all for LINTers but its not exactly a paradigm shift. Though, I am excited about Roslyn Analyzers and how dotnet seems to be pulling together a language standard LINT system. https://github.com/dotnet/roslyn-analyzers https://github.com/dotnet/roslyn-analyzers

elihu 6y ago

> I think software should be opinionated. Throwing everything in a huge settings panel or configuration file and calling it “choice” or “not imposing your preferences” is a product development failure. I think the ideal is that the software is as configurable as it needs to be in order to be useful to the people that use it, but that there's a standard configuration with sensible defaults.

ZephyrBlu 6y ago
I think that ideal is extremely difficult to reach without it turning into the situation you quoted.

jeffreygoesto 6y ago

I read the article as "error messages should rather be a beginning than an end" message. Nobody wants a program to fail, that is not why you put effort to configure and start it in. An error just describing what happened puts the load to fix or how to "heal" it onto the user. She needs a mental model of why the program failed and what to do to make it succeed. What I interpret "prescriptive" to be is that the message returned to the user on failure should give some hints how to make the program succeed. Because there are more ways to fail than the program author could think of, or more than fit on a screen, it is opinionated which advice to give then (a subset of all known and unknown possible fixes). I always tell my coworkers, an error message is a call for action, not an out-of-jail-I-just-stop-here card. The better you guide the user, the more efficient she can use our software.

orasis 6y ago

I think the library vs framework lens is more productive. Write libraries, not frameworks: https://www.brandonsmith.ninja/blog/libraries-not-frameworks https://www.brandonsmith.ninja/blog/libraries-not-frameworks

EGreg 6y ago

The best software is one where you have total flexibility and composability, and great default configurations for n00bs to get started with. In fact, the configuration language would be the "programming language" for many in dev ops, orchestration, and so on.

lmilcin 6y ago

This is shortsighted. There is place for prescriptive as well as descriptive components. The huge issue with components that don't give you much choice is that they do not compose well. You find two components clash on some decision and neither has any mechanism to resolve the issue. This is frequently the case with "frameworks", which tend to want to control all aspects of your application. Does this make your life simpler? Sure, but only if your application is exactly or very closely to what the author of the framework envisioned. On the other hand there are "tools/utilities". These can fit same role/functionality as "frameworks", but they are not intrusive, don't tell you how to put your application together. Rather, they give you tools with assumption you will know how to use them. Does this make your life simpler? SURE If you have non-standard application and you know what you are doing you want to compose your application from tools that do not demand too much from the structure of application, dependencies, etc. If you are novice developer it might be temporarily useful to use more prescriptive tools. You don't know how to put stuff together so you might just as well learn how others do it. If you are advanced you will know what to use. If I know I will be working on a very standard application I might just as well use something that takes care of it all for me.

beaker52 6y ago

It's fun to customise and learn, but going forward I'd rather defer to sensible defaults so that I can spend my thought cycles on solving software problems, rather than fixing all the weirdness that arises from my customisation. I'm a big fan of Prettier for this very reason. It just works. It's decent. It lets everyone get on with writing software. If a project has ESLint, there's a high chance I'm going to be talking about semi-colons, or looking at oddly line-broken code. Someone else is going to notice it too, and want to fix it. Then we're all talking about the Airbnb config and what customisations we're going to make. In recent years I've: - Quit using Colemak and gone back to Qwerty - Stopped using vim and went back to IntelliJ - Stopped using custom fonts, themes and just stuck to defaults - Become more selective about what plugins I use And I'm suprisingly (or unsurprisingly) more productive.