[HN Gopher] Prescriptive software is better than descriptive sof...
___________________________________________________________________
Prescriptive software is better than descriptive software
Author : sergiomattei
Score : 133 points
Date : 2021-04-05 13:48 UTC (9 hours ago)
(HTM) web link (kilianvalkhof.com)
(TXT) w3m dump (kilianvalkhof.com)
| EGreg wrote:
| 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.
| jayd16 wrote:
| 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
| waffletower wrote:
| Yes.. we need more fiefdoms. More prisons. More machined
| conformity.
| esjeon wrote:
| 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.
| andreareina wrote:
| s/descriptive/proscriptive/g I think. Descriptive doesn't attach
| value to the observations, while "hey that's wrong" definitely
| does.
| [deleted]
| ed312 wrote:
| What does this notation mean: "s/descriptive/proscriptive/g" ?
| pdkl95 wrote:
| 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-_00
| 22s...
| cochne wrote:
| This means find and replace descriptive with proscriptive. It
| is a pattern used by Vim and Sed, and probably some other
| programs.
| virgil_disgr4ce wrote:
| It's regex, vim and sed just happen to use it
| Jtsummers wrote:
| Substitute <pattern> with <replacement> globally.
|
| https://www.gnu.org/software/sed/manual/html_node/The-_0022s.
| ..
| adwn wrote:
| _Replace all occurrences of 'descriptive' with
| 'proscriptive'_
| virgil_disgr4ce wrote:
| 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.
| singlow wrote:
| Agree. I see the concept but the analogy to grammar terminology
| doesn't quite fit. I'd suggest _corrective_.
| saurik wrote:
| 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) 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
| carapace wrote:
| I think the answer is to develop and use systems that make it
| easy to apply (and "un-apply") the Futamura projections (aka
| partial evaluation.)
| tdfirth wrote:
| 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.
| kilian wrote:
| 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 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.
| [deleted]
| pca006132 wrote:
| 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 wrote:
| 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 wrote:
| > emacs framework ... don't want to spend a long time
| configuring the tools
|
| Are you sarcastic?
|
| Edit: Extended quote
| exdsq wrote:
| 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 wrote:
| 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 wrote:
| Ah ok didn't make that connection.
| beckingz wrote:
| "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.
| [deleted]
| kansface wrote:
| 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.
| teodorlu wrote:
| 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 wrote:
| 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 wrote:
| > _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?
| nitrogen wrote:
| _Was anybody 's choice of editor really a major point in
| their developer progress and productivity?_
|
| Having used multiple IDEs and editors, from DOS edit/qbasic
| to notepad.exe, RHIDE from DJGPP, Visual Studio, Xemacs
| (briefly), Vim, Eclipse, IntelliJ, probably others...
|
| Yes, some of those bring unique abilities that the others
| lack, that have an effect on the way I write software. Had
| I just picked one editor or IDE and never used any others,
| I would be much less accomplished. Vim, for example, is for
| me incredibly rapid at rearranging and replacing
| words/lines/regions of text compared to the others.
| coldtea wrote:
| > _Vim, for example, is for me incredibly rapid at
| rearranging and replacing words /lines/regions of text
| compared to the others._
|
| Sure, but how much of that clerical work is relevant to
| programming, where a rate of say 100 lines per day is a
| major achievement, and it's usually much less? Even if
| one needs to delete/copy/re-arrange 1000 lines in order
| to get to those 100 (and usually it's more like 30-50 per
| day than 100 anyway), it's still a tiny part of the time.
|
| In any case, I've seen great coders, from Brian Kernighan
| and Bill Joy, to Linus, Carmack, and Persson using
| whatever from Vi and Emacs to Visual Studio and Eclipse,
| and still getting shit done...
| athrowaway3z wrote:
| The numbers aren't helping. 100 lines of what? It all
| boils down to 'it depends'.
|
| In my personal experience, before i started using
| spacemacs i would postpone re-arranging code when i was
| busy coding something useful. Pushing all the cost into
| an afternoon of _just_ rearranging code.
|
| Besides not having a very 'productive' afternoon, the
| costs would linger because i need to update my mental map
| of all the stuff that moved around.
|
| Now, most rearranging is a couple of key strokes away.
| I'm not sure what i would do in another IDE. I would
| probably do the rearanging as soon as required, because
| I've learned my lesson.
|
| But moving my hand to the mouse and clicking multiple
| buttons while typing new file names and dragging my mouse
| over pieces does take a lot of flow out of the session.
| tsimionescu wrote:
| > But moving my hand to the mouse and clicking multiple
| buttons while typing new file names and dragging my mouse
| over pieces does take a lot of flow out of the session.
|
| I don't understand why people equate IDEs with mouse
| interaction. All major IDEs, from Emacs to VisualStudio,
| have key combinations for anything you can do. It's fair
| to say some key combinations are better in one program
| than another, but there is no reason to imagine that
| using an IDE means you must also use a mouse. The mouse
| is always an extra option, not a requirement.
|
| And there are code modifications that an IDE can do for
| you cheaply at the press of a key that would take hours
| of tedious, error-prone manual work, even with fancy vim
| fingerwork. Even the lowly 'Extract Function' already can
| save a good half an hour for more complex cases. And
| modern IDEs offer things like passing a parameter down
| through a long call stack in all places (a calls b calls
| c calls d calls f, and now you want a variable in a to
| become a parameter in f), with guaranteed 0 manual
| intervention. Or extracting an interface out of a class
| and patching all callers.
|
| Not to mention all of the code exploration options, such
| as IntelliJ's 'Dataflow to here', which finds all of the
| code which is responsible for a variable's value
| throughout your entire program (or the dataflow from here
| operation, which finds how a value set in this function
| is used further down the call stack), stopping only at IO
| (so if a.foo() reads a value from a file and stores it in
| a field that is read in a.bar() which puts it in a
| dictionary, where it is read by baz() which adds 7 to it
| and prints it out, you can ask for dataflow to the
| variable being printed and it will find that it was read
| from some file in a.foo()).
| why_Mr_Anderson wrote:
| >programming, where a rate of say 100 lines per day is a
| major achievement
|
| Wait, what? 100 lines per _day_ is an achievement?
|
| I'm honestly curious in what branch of SW development
| this happens. I'd assume something that requires formal
| proof of every piece of code ever written?
| thrower123 wrote:
| On Brownfield software, your LOC counts probably average
| out to nearly zero. It wouldn't be uncommon to spend four
| or five hours diagnosing, tracing, reproducing, then
| fixing and verifying a bug, and the end result would be
| two lines of code changed when you were all done, with
| maybe twenty or thirty more in tests.
| passivate wrote:
| 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.)
| slx26 wrote:
| Well, you can also have both. Most tools should be prescriptive
| unless you have to go really deep and do your own. If you have
| the expertise, it might be ok for you to choose the rules of
| what you are doing. If you are not, being guided it's much
| better. I agree with the general idea of the article, but I
| also think it would have been interesting to discuss more in
| depth where each approach can be relevant. Making things
| accessible doesn't only require knowledge and features, but
| years of insight and clarity of thought. You want to benefit
| from that while you are new, because it will make your life
| much easier until you reach the point where you really want to
| choose on your own.
| swiley wrote:
| > Most tools should be prescriptive unless you have to go
| really deep and do your own.
|
| Absolutely not. Compare most WiFi connection UIs to
| WPA_supplicant.
|
| On windows: 'connection failed'
|
| On wpa_supplicant: 'associating... atempting
| authentication... getting dhcpc lease... dhcp timed out'
|
| One says "sorry computer doesn't work" and the other tells
| you what you need to deal with the problem. Stop
| infantilising users, it's disrespectful and counter
| productive.
| pjmlp wrote:
| For most users the wpa_supplicat messages could even be a
| foreign language for what they can get out of it.
| thrower123 wrote:
| Unfortunately people will actively refuse to read any kind
| of diagnostic information that you do output to them, as I
| have learned during over a decade of doing troubleshooting
| sessions with customers.
|
| If you're having a good day, you can get them to leave a
| pop-up error message open for long enough to read the whole
| thing on the third or fourth attempt. On a good day...
| fouric wrote:
| > Stop infantilising users, it's disrespectful and counter
| productive.
|
| Yet another logically-vacuous emotionally-manipulative
| statement.
|
| The equally-manipulative counter-argument to that is
| "You're not emphasizing with the users - how would YOU like
| for, say, government bureaucrats to give you back a bunch
| of technical gibberish instead of telling you how you
| filled out the form incorrectly in plain English?"
|
| Use logic instead. I think that it's easy to build
| interfaces that are friendly to both power users and non-
| power-users - talk about the possibility of that using
| logic instead of trying to manipulate the emotions of
| others to shame them into agreeing with you.
| jimmaswell wrote:
| Simple solution is a "connection failed" message with a
| "view technical details" option. Which is generally the
| best idea, sensible defaults and usability for the
| average user and as much customization/technical stuff as
| is appropriate for power users.
| rapind wrote:
| I agree, except specifically when it involves government.
| I actually don't want them to hide details, but that's
| because I don't want them handling super complicated
| stuff most of the time. Gives them too much room to hide.
| bosie wrote:
| > Stop infantilising users, it's disrespectful and counter
| productive.
|
| that goes both ways. if you show the wpa_supplicant
| message, my mother wouldn't even understand if she is
| connected or not. nor would she gain anything by that
| information. you just came up with the other side of the
| same coin of terrible UX.
| rapind wrote:
| This is true and yet I wonder how much more efficient it
| would be when they call me for help. "It said a bunch of
| gobbledygook that ended with dhcp timeout", or "it just
| says connection failed".
| bosie wrote:
| or have some sort of a middle ground.
|
| 'not connected. more info: blah #32893289327". Microsoft
| did something similar with an error code that you could
| google. that was super useful for debugging. the error
| message was in laymen terms though.
| Groxx wrote:
| Makes things much easier to search for too, as those IDs
| don't need to change across languages or UI refreshes
| (which may e.g. rewrite the error messages, breaking all
| those old searchable phrases), both internally
| (unambiguous to grep!) and externally (google /
| stackoverflow / etc). And users are FAR more likely to
| read them back correctly to support, instead of saying
| what they _think_ the message says (every tech-support-
| person has had to deal with this some number of times).
|
| Error IDs on everything, please.
| tablespoon wrote:
| >> On windows: 'connection failed'
|
| >> On wpa_supplicant: 'associating... atempting
| authentication... getting dhcpc lease... dhcp timed out'
|
| >> One says "sorry computer doesn't work" and the other
| tells you what you need to deal with the problem. Stop
| infantilising users, it's disrespectful and counter
| productive.
|
| > that goes both ways. if you show the wpa_supplicant
| message, my mother wouldn't even understand if she is
| connected or not. nor would she gain anything by that
| information. you just came up with the other side of the
| same coin of terrible UX.
|
| Yes, you need _both_. When I write error messages, I try
| to combine a "user friendly" summary with more technical
| information and a suggested action, e.g.:
|
| "Wifi connection failed: dhcp timed out. Try reconnecting
| or checking the router's configuration."
|
| If you don't communicate both, someone's going to be
| frustrated. And even nontechnical people who have no idea
| what DHCP is benefit from mentioning it in the message,
| since it gives them something to Google.
| devmunchies wrote:
| > Linux, Emacs
|
| you proved the article's point with these examples. If you want
| to write software that can become a sustainable business, don't
| do what linux and emacs did. It only serves power users and
| other businesses who will sell services.
|
| I also prefer descriptive tools (I hate rails/django), but I
| acknowledge that descriptive is typically worse UX unless the
| user is a power user.
| athrowaway3z wrote:
| No. The article overgeneralized when it conflated the term
| 'software' with 'product a business can package and sell'.
| devmunchies wrote:
| replace "product a business can package and sell" with
| "serves the most users" and the point still stands.
|
| Serving the most users (ie. NOT power users) is usually the
| best economic decision as well.
| TeMPOraL wrote:
| Serving or entrapping them?
|
| The end goal of any piece of software that wants to
| deliver actual value is to turn its user into a power
| user. Power users aren't born, they're made - made
| through repetitive use. Software that doesn't give a path
| for the user to grow and become more proficient is
| software that literally wastes their limited time they
| have on this planet.
|
| As usual, what's the best economic decision and what's
| actually good are aligned here only so much that you
| won't get laughed out of the room for proposing they're
| the same. But not much more than that.
| devmunchies wrote:
| > made through repetitive use
|
| now who's entrapping who?
|
| you think its practical for every piece of software to be
| a massive time sink?
|
| > software that literally wastes their limited time they
| have on this planet.
|
| There's a saying "linux is only free if you don't value
| your time", now you're saying that software that takes
| MORE time commitment saves you time? C'mon, take off your
| engineering hat for a second.
| TeMPOraL wrote:
| I'm saying that:
|
| 1) Actual value to people is mostly created in software
| that's being used repeatedly. The tools people use for
| work, to run their errands, and to communicate.
|
| 2) For any tool that's used repeatedly, if there's no
| path for the user to grow ever more proficient and
| efficient in using it, the tool is wasting that user's
| time.
|
| > _now you 're saying that software that takes MORE time
| commitment saves you time?_
|
| No, I'm saying that _less_ time spent on using software
| to accomplish unit of value is better. For software used
| repeatedly, this is achieved by learning to use the
| software better - and that can only happen if the
| software offers room to grow, and isn 't just a Fisher-
| Price toy.
| ZephyrBlu wrote:
| You are assuming there is zero opportunity cost in
| learning to use the software better. Perhaps further
| increasing my efficiency with this software is not as
| impactful as spending my time on something else.
|
| This also assumes that the time you invest in learning
| the software will be offset by productivity gains, which
| seems extremely unlikely for the majority of users
| assuming the software is non-trivial.
|
| There is also risk associated with learning the software.
| What if you begin to learn it and then for some reason
| you stop using it? You've just wasted a whole lot of
| time.
| TeMPOraL wrote:
| All three of your points are covered by my base
| assumption: software used _repeatedly_. Any opportunity
| cost is consumed by the fact you 're using this software
| all the time. For the same reason, productivity gains
| compound, and there is little risk of switching any time
| soon (also this is the kind of experience that tends to
| generalize well).
| tsimionescu wrote:
| That is only true in so far as that piece of software is
| somebodys livelihood or hobby. In many cases, people have
| rare uses for a portion of piece of software, so they
| benfit immensly from it being dumb and easy to use.
|
| For example, as a programmer I occasionally need to
| prepare presentations, in which case I use PowerPoint
| because that's what the company bought. I use probably
| less than 1% of what PowerPoint can do, and I wouldnt
| lose anything at all if I were given a program that did
| exclusively that 1%. I would in fact gain some
| productivity by having to browse through fewer options. I
| have no intention and would gain nothing by becoming a
| PowerPoint power user.
| TeMPOraL wrote:
| > _In many cases, people have rare uses for a portion of
| piece of software, so they benfit immensly from it being
| dumb and easy to use._
|
| One doesn't have to exclude the other. You can present a
| gradual onramp but make advanced features available and
| discoverable.
|
| > _I use probably less than 1% of what PowerPoint can do,
| and I wouldnt lose anything at all if I were given a
| program that did exclusively that 1%._
|
| That 1% solution is called Google Office Suite :).
|
| You obviously don't need PowerPoint much, and your use of
| it isn't really creating much of value either. Contrast
| that with people who use PowerPoint for most of their
| working day. Ignoring for the moment the difficulty of
| quantifying value of managerial meetings, it would be
| really bad if Microsoft one day decided to ignore the
| people who use PowerPoint extensively, for the sake of
| greater amount of casual users.
|
| That's the kind of ass-backwards "economic thinking" I'm
| complaining about. I get where it comes from - pursuit of
| _growth_ at all costs. It 's a disease in software
| industry. Instead of great many tools optimized for the
| needs of diverse audiences, the "servers most users",
| "best economic decision" mantra is to create lowest-
| common-denominator toy that can gain userbase fast, and
| suck out oxygen from the market.
| whimsicalism wrote:
| If that was the article's point, then unfortunately they
| chose the wrong title.
| cjohansson wrote:
| 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
| bordercases wrote:
| 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.
| jeffreygoesto wrote:
| 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.
| elihu wrote:
| > 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 wrote:
| I think that ideal is extremely difficult to reach without it
| turning into the situation you quoted.
| nickthemagicman wrote:
| 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.
| Pxtl wrote:
| I fell like the terminology here is too vague... Opinionated vs
| configurable seems clearer than prescriptive vs descriptive.
| orasis wrote:
| I think the library vs framework lens is more productive. Write
| libraries, not frameworks:
| https://www.brandonsmith.ninja/blog/libraries-not-frameworks
| taeric wrote:
| Issues of whether this is prescriptive or not aside, I think this
| hits close to a paulg tweet:
| 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.
| hammock wrote:
| 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 wrote:
| I think 'discoverable' is one of the big Apple tenants of
| design, or it used to be (but I am not a designer).
| ziml77 wrote:
| 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.
| api wrote:
| https://en.wikipedia.org/wiki/Decision_fatigue
| iandanforth wrote:
| 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 wrote:
| 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...).
| depressedpanda wrote:
| In what way will you end up kinda screwed when using black?
| ghoward wrote:
| 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-... .
| gregmac wrote:
| > 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 agree with this.
|
| I see parallels to a lot of frameworks, languages, libraries,
| etc: the "getting started" guide is fairly simple, but then to
| do a "real" thing with it, you need to basically throw all that
| away and learn a whole different system.
|
| The other mistake a lot of systems make is abstracting away the
| complexity with defaults (aka "magic"), but making it so if you
| do want to change one thing you have to learn and re-implement
| the entire configuration yourself.
|
| In both cases, it's the learning curve that is important to
| think about: going from usable defaults (beginner) to
| customization (expert) should not be one giant all-or-nothing
| step.
| taeric wrote:
| 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 wrote:
| 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-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-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)
| taeric wrote:
| I feel this fits things that "aren't really wrong", but
| that are dangerous.
|
| Other examples include monoculture of crops. Generally, not
| a good idea. Happens wherever it can, though.
|
| That is, I agree with your points. I just have difficulty
| thinking we have the full picture covered. :(
| [deleted]
| fctorial wrote:
| 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.
| 0wis wrote:
| 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]
___________________________________________________________________
(page generated 2021-04-05 23:00 UTC)