
A rant about application configuration - wging
http://robotlolita.me/2016/01/09/no-i-dont-want-to-configure-your-app.html
======
userbinator
_compare the experience of using both coffee machines, even if the former
doesn’t give you the exact kind of coffee you want, you are still far better
off._

 _Documentation is terrible for applications. If you think that your
application really requires documentation, it’s too complicated, and it’s
going to make your users frustrated._

I strongly disagree. There is value in providing good defaults, but users will
and should be encouraged to go beyond them. That's what the documentation is
for.

Being frustrated is also normal. It's a natural part of the learning process.
If everyone was always expecting everything to "just work" and gave up the
moment they encountered the smallest bit of frustration, nothing would ever
get done.

That said, although there is a lot of superfluous complexity in software today
(dependencies are mostly responsible), I don't think it justifies turning
everything into unconfigurable featureless appliances or not writing
documentation. General-purpose computers are immensely flexible and powerful,
and if we want them to remain that way, I think it's well worth putting in the
effort to learn. The culture of instant gratification that seems so prevalent
today may become counterproductive in the long term.

~~~
kstenerud
> There is value in providing good defaults, but users will and should be
> encouraged to go beyond them. That's what the documentation is for.

While the original article does not state this directly, it is implied that
he's talking about programs where you have to read the manual to be able to
use even its most basic functionality. Right now, I want to get a job done.
Exploring can come later when I've got time for it.

> Being frustrated is also normal. It's a natural part of the learning
> process.

It's part of the learning process when you're breaking ground. It's not
appropriate when you're trodding the well-worn path. If your users have to
resort to SO questions just to do common case things, you've failed them.

> I don't think it justifies turning everything into unconfigurable
> featureless appliances or not writing documentation.

He is recommending neither.

~~~
lelandbatey
The author explicitly states:

    
    
        If you think that your application really requires documentation, it’s too
        complicated, and it’s going to make your users frustrated.
    

Additionally, the author says:

    
    
        If you compare the experience of using both coffee machines, even if the
        [simpler] doesn’t give you the exact kind of coffee you want, you are still far
        better off.
    

The author is explicitly saying that tools should not require documentation,
and that _ease of making a choice is preferable to the potentially better
outcomes of a more complex choice._

I believe that neither are absolutely true.

There is no mystery as to why these open source applications do what they do.
They don't because either they can't know what you want them to do, or we
programmers haven't made the appropriate changes so they handle the cases
where the program _can_ infer what the user wants.

Side note: If this post does anything, I hope it's to get someone to submit a
pull request to NVM so it prints better help messages during first use (like
suggesting setting up a default alias).

~~~
ekianjo
I think the author is deeply wrong if they think there is "One KIND" of users.

Depends on the product category, target users, what your product actually does
and how it differentiates with the rest, etc, there's a bunch of different
variables to consider before sending a blanket statement that's so obviously
false in many situations.

------
n0us
Javascript build tools seem to be the worst offenders here. I just want to
transpile and bundle my app, not program a build tool by clobbering together
100 libraries. Grunt was okay, but it was slow and required lots of
configuration. Not much worked out of the box without downloading plugins.

Gulp was much much worse. Nothing worked at all out of the box and months
later I still hadn't found the patience to get everything working right.
Documentation was next to non-existent and there were points where I wanted to
rip my hair out trying to work around "vinyl source streams", whether I needed
a buffer or not, how to wrap a regular stream, how to get live reload to work,
figure out why they had "blacklisted" popular modules that just made it easy
to plug things in. At least it was fast but I never did get it working for
some of the things I wanted to do and fell back on grunt sometimes.

Webpack is somewhat better I suppose but at this point I'm just prepared to be
disillusioned every time I try some new javascript package which has maybe
nulled the pain to some extent.

It isn't even that doing this stuff would be that difficult it's just that the
docs are usually wrong, missing, incompatible, or outdated. No one bothers to
fix them because by the time they do the JS community has just chugged along
to the next "framework" leaving a trail of broken and abandoned projects in
its wake.

I don't give a damn about bloat and modularity. Most of the time I'm just
looking for a quick solution. If I have to download a big package so be it. Do
everyone a favor and package things together that are compatible and work
together so I don't have to spend hours tracking down the proper module for
doing something like compiling sass and then another hour figuring out how to
configure it and insert it into the build tool.

If I wanted to work on build tools then I would work on build tools but I get
so tired of doing this stuff each time I need to set something up. In theory
it sounds nice for there to be a million ways of getting something done but in
practice I think it's just easier for someone to set a precedent for doing it
one way and then have the community work on incremental improvements to that
one way of doing things. This eliminates a load of confusion, incompatibility,
and excess work.

All this might be an unpopular opinion but when I'm working on a project I
like to direct my time towards the project, not the supporting development
tools.

~~~
gkya
In the JS community there are overkills à gogo, a cacophony of many build
tools, package managers, various --pilers, minifiers, maxifiers etc. The
cadence of reinvention is unfathomably fast, I don't understand how one keeps
up, but I guess most of the non-problems these quasi-tools solve would easily
be solved with make and some vendoring, though that is already invented and
time-tested ergo bad and boring...

~~~
userbinator
A lot of web development in general seems to be more about reinventing things
as much as possible and creating problems for solutions. Then again, web
design is heavily fashion-driven so that attitude pervades into everything.
There is a lot of churn, often for little gain.

------
egypturnash
So where does this leave complex, professional-level applications?

Sure, a home user doesn't want that high-end coffee machine. But a
professional Maker Of Coffee does; that's a tiny cut-down example of what
you'll find in pretty much any coffee shop you visit, being used to crank out
at least a dozen different drinks multiple times a day.

Or compare a kid's first toolbox to a fully-equipped carpenter's workshop full
of power tools. Those power tools can rip through raw materials a lot faster
than hand-powered ones, and can also rip through your flesh if you're not
careful; they come with manuals, there are safety precautions you need to
learn to use them.

That said it is certainly nice to:

\- have all the configuration switches for your app in one place (a story:
I've been using Adobe Illustrator regularly since 2000; it wasn't until like
2010 that I accidentally double-clicked on the pencil tool and found out that
it has settings that don't live in the main 'preferences' window. Its defaults
are IMHO terrible and made it a useless joke of a tool; once I'd found that it
has settings it suddenly became the way I draw 90% of the shapes that make up
my art.)

\- have sensible defaults (see above parenthetical story)

\- make your app easy to get running, which a hell of a lot of programmer
tools certainly are not.

~~~
chipsy
Complex applications are the worst of both worlds. They don't do things
intuitively, they invent unconventional UI paradigms, and they are extensively
configurable, so they need a manual that begins with "how to read this
manual".

The workshop analogy builds on a false premise of low configuration equating
to underpowered function. A pro will use a lot of different speciality tools
that have no or minimal configuration, vs. a Swiss Army Knife that is mediocre
at everything. In the same way, Unix-style workflows are very "shoot yourself
in the foot" stuff, but formal configuration of each tool is minimal.

The best thing a complex application can do is be a general-purpose
programming API at its core, with common workflows surfaced as a polished,
simpified UI. Each of those workflows is its own application, with internal
developer documentation to orient someone who wants to hack on it. Then the
80% cases are solved by default, and the 99% cases("this thing doesn't let me
configure x") are solved by copy-pasting the application code and modifying a
single line based on a Stack Overflow answer. And everything beyond that, you
had to code anyway, so you enjoy a real programming environment with
documentation instead, and hopefully a hook into the broader ecosystem so that
the API is available throughout different coding environments.

Sadly, almost no application intentionally evolves in this way.

~~~
KayEss
AutoCAD always has. The GUI is really nice, in that it understands how to
build the LISP commands that actually implement the system. You can put in a
template LISP command and tell it where you want a 2d point, or a distance and
the GUI collects these and fills in the values. It can even do embedded calls
to generate these from other things.

It's extremely flexible and allows you to arbitrarily build new commands that
are easy to use. I automated a workflow for a drafting studio I worked at in
1989 and reduced the time taken to complete a drawing from three days to three
hours just by writing new LISP commands for all of the most common things we
did and wiring them up to the menu on the tablets we had.

------
alexandercrohde
I'm really glad somebody has written this. I think it makes essential points
and does it with undisputable examples and a sense of humor. Bravo.

I agree with the javascript examples; I had an even worse experience trying to
set up a LAMP stack back as a teenager. It was a perfect storm of new problems
and vague errors (which .conf file on my hard drive represents what's running
on port 80? Did I screw up permissions? Is there something wrong in my
php.ini? Did I install php as a module or a library? All I get is a
timeout...). Today I know all the exact commands to debug the setup, but I
wasted so many hours back then blindly struggling with something that could
have been explained in minutes by more experienced people / software.

~~~
cheese1756
I have no idea why your comment is at the bottom of the page. So many
arguments in this comments section set up a straw man, claiming that the
author is saying that nothing should ever be configured. Of course, it's not
that you never need configuration, it's that you should have sane defaults for
very common use cases.

If you hear about Linux and want to install it, for example, Googling "Linux"
just takes you to the linux.com homepage. Last I checked, it contained no
links to distros. This is the same situation. Someone's goal is to install a
Linux distro or to use nvm, so you should make it easy for them to install a
Linux distro or use nvm. Don't make people wade through complex instructions
for a process that should be simple.

Most software solves problems. Why add complexity when someone wants to get
something else done?

------
wging
Interesting... this got re-titled, but I'm not sure why. The original title
was taken from the title of the linked post: "No, I Don't Want To Configure
Your App!".

(ed: I'm more intrigued than anything. It's a good re-titling IMO--I'm not
sure who did it or why, but it's something I might've chosen if I didn't think
choosing anything other than the post title was frowned upon. hope this
doesn't distract from the actual post).

~~~
anonfunction
That's odd because it's the opposite of the stated policy. I came to say that
the original title and article, in my opinion, had a much different meaning
and intent.

    
    
        Original Title:    No, I Don't Want To Configure Your App!
        Hacker News Title: Don't Configure Applications

~~~
lambda
The guidelines say:

    
    
      Please don't do things to make titles stand out, like 
      using uppercase or exclamation points
    

and:

    
    
      Otherwise please use the original title, unless it is 
      misleading or linkbait.
    

I think the idea behind this change in title is because the original is
perceived as being linkbait; it has an explanation point, is very opinionated.
The kind of thing that really tempts you to click through, or come and post a
scathing rebuttal, because of how strongly worded it is.

Not saying I necessarily agree with the new title, but it is milder, and I
think that in general moving away from clickbait titles is a good thing.
There's enough clickbait junk going around the rest of the internet, having at
least some standards at HN is fine.

~~~
Dylan16807
So remove the exclamation point or something. A misleading title is worse than
clickbait.

And honestly, I find such a bold statement as "Don't Configure" to be more
click-baity than the original title.

------
exizt88
I don't think the author ever said that you _shouldn 't_ be able to configure
an application. It's more about proper default configs. Default configs are,
incidentaly, an important part of the Unix philosophy of "program that does
one things well". Since it does one thing, it's easier to guess which default
configs should be shipped with it.

mkdir doesn't, for example, explicitly demand permissions with which to create
a folder (but you can do that: mkdir -m 777 dirname). less doesn't require you
to tell it whether to squeeze consecutive blank lines into one (but you can:
less --squeeze-blank-lines).

It's especially sad to see JS community forgo this principle, since it seems
to embrace modularity (as in "one module that does one thing well") so much.
Babel 6 and Webpack could've been so much more fun to use if they came with
sane configs out of the box.

~~~
djur
> Applications do things in one way, and one way only. You can’t change that.
> You can’t combine them. You can’t configure them. You can’t program on top
> of them.

That seems pretty cut and dried to me.

~~~
exizt88
Huh, you're right. I disagree with the author, then.

> They’re like the coffee machine on the office: you press the button,
> delicious coffee magically appears in your cup

But even office coffee machines usually have some level of configurability, in
terms of serving size, flavor, etc.

------
kazinator
A program needs inputs. Either those inputs are supplied when the program is
run, or they come from a configuration. Some configurations can be reasonably
defaulted. Some can't.

For example, a newly installed browser on a machine that has never had a
browser cannot read your mind to figure out your home page. It can run and do
its job, but without a URL, and a default home page, it can just display an
empty window.

(Some inputs cannot reasonably be made configurations. Should a ssh program
connect to some particular host if run with no arguments? Maybe. Should "rm"
have a default file name to remove if none is supplied? Crazy!)

Configurations are necessary, though. There are otherwise too many inputs.
What's the answer? "I don't like programs that take many inputs; don't make
such programs?" That's just dumb. Some functions simply don't decompose. You
can't take every program that has 60 inputs and make it into 6 completely
independent programs that have 10 inputs to somehow do the same job. If it
_can_ be done, maybe it should, sure.

 _Of course, nobody should be required, before using a program, to configure a
myriad preferences that can all be reasonably defaulted._ That seems to be the
point of this blog, which is largely self-evident.

~~~
jjoonathan
> For example, a newly installed browser on a machine that has never had a
> browser cannot read your mind to figure out your home page. It can run and
> do its job, but without a URL, and a default home page, it can just display
> an empty window.

 _That_ 's your example? Browsers have been doing better than that for
decades.

~~~
kazinator
It's an example of something that is not bad in this regard: browsers run
anyway if there is no URL and no home page configured, defaulting in some way.
(If you think that what modern browsers show instead of a blank page is
better, that's great.)

------
paulannesley
I prefer minimal config, but she lost me here:

> If you compare the experience of using both coffee machines, even if the
> former doesn’t give you the exact kind of coffee you want, you are still far
> better off.

Nope. Probably true for people that don't care about coffee, but give me the
full espresso machine any time.

~~~
atemerev
I feel the same about coffee machines (owning one of the beasts), but I mostly
agree with the article.

I wonder if pro coffee machine technicians prefer single-button full autos.
Would make sense.

------
justin_vanw
Every year someone learns to program and for some reason the first thing they
do is start lecturing.

~~~
TeMPOraL
It's a part of the learning process.

------
dham
I thought Babel 6 was some kind of satire on Javascript build tools. I even
hit him up on Twitter. In fact Sebastian was serious.
[https://twitter.com/drewhamlett/status/681245325282164737](https://twitter.com/drewhamlett/status/681245325282164737)

~~~
spankalee
That's a ridiculous conversation, on your part. What defaults should Babel
choose? What if I disagree?

~~~
dham
What do you mean? Babel 5 and before included everything out of the box. You
just told it the stage you wanted and your done.

------
smt88
Even if you disagree with some of the points here, I think any modern web
developer has looked at the (growing) number of config files in the root of
his/her latest project and been surprised.

I definitely like that everything is configurable, but between 5 or 6 config
files and dotfiles, there are hundreds of different options that are exposed
that make my build/run phase operate _slightly_ (or something _vastly_ )
differently. That's pretty overwhelming sometimes.

------
lelandbatey
The entire premise of this article is that tools like NVM are "apps", which is
interesting for me. I do not think of software like NVM or node as 'apps', as
much as I think of them as 'tools'. And for me, the entire point of a tool is
that contrary to point 4, you are expected to read the manual before using
them. A tool has little in the way of safeguards, and it doesn't presume to
know what you want. It does what it was designed to do, and you are expected
to understand what it does and doesn't do.

For example, the problems had with NVM are nearly all explained by reading the
README[0] which on my laptop is ~6 screens of medium size text. If perused, it
would explain how to install versions of node, how to enable different
version, and how to set default global versions.

Now, the question is "why is it the case that tools aren't expected to be as
simple to use as apps?" I believe the answer is because anticipating and
guiding a user through learning that tool takes a ton of time and energy, much
more time and energy than your average open source developer has.
Additionally, it's incredibly easy to break things like automation of command
line tools in an effort to cleverly anticipate and guide a user.

Most importantly, I'd like to remind everyone that this is open source
software and you are more than welcome to attempt to change it. For example,
NVM is a ~2000 line bash script; making some of the simpler changes you bring
up (such as improved help messages and suggestions) is well within the grasp
of a single person with an afternoon.

I don't mean to dismiss the author's points: the software mentioned is
frequently frustrating to use, and can be extremely unhelpful. I've struggled
with nearly all the same ones brought up in this post. However, it's not as
though these where tools designed by Apple for the everyman; they where built
by engineers under time pressures with an intended audience of other
engineers, and if you think they should be different you are welcome to bring
that change.

[0] - [https://github.com/creationix/nvm](https://github.com/creationix/nvm)

------
rdtsc
In the real world you can't have both, you can have one coffee machine, or the
other. In software world you can have both. It is usually done by having a
simple mode and an expert mode, or in a range in between in. VLAN has that for
user preferences (now I know the goal is to not have preferences at all, but
it is just an example).

------
cooper12
I hate to say it but this is the fault of the Unix philosophy, which favors
power users over the novice. It dictates that applications should do _exactly_
what you tell them to. For example, using the `install` subcommand of a
package manager should not update your packages, but rather that should only
be done by the `update` subcommand. Of course you could put in an `if`
statement that checks if the package is already installed, and instead it will
update it for you. (Not the best example but bear with me) The problem with
this is that it breaks expectations; no longer do flags/commands do exactly
what the name says, but each will have their own side effects; subtree of
commands that are called that you might have to figure out. (Or maybe not if
it is well-documented, like how `git pull` calls `git fetch` and then `git
merge`) This is antithetical to scripting purposes and completely controlling
your own experience. Instead you have to work around the well-meaning one size
fits all experience proffered by the developer. Unix tools hate state because
commands are meant to be chained together anew each time. They also hate
interactive sessions for that reason since it forces people to walk through
repetitive steps even when they might already know what they want. What else
can you do at that point but offer configuration options? Maybe a possible
solution comes from git again: architect your application as a low-level API
and include a higher-level implementation. This worked out beautifully in my
opinion, with anyone needing to dig into the internals using the plumbing, and
the majority of the end users, the porcelain. This comes with its own
drawbacks such as the oft-complaint that git uses leaky abstractions and its
not always clear how a command modifies the internal state, as well as
inconsistent flags. (Note: this is coming from someone who read "Do one thing
and do it well" and made it his mantra, not realizing that only robots want to
do one thing at a time as in an assembly line; the rest of us want a complete
experience)

------
underwater
The author has identified a real problem in the JavaScript ecosystem, but I
think his solutions miss the mark.

Firstly the distinction between library and application less important than he
supposes. In the case of something like Babel, it can be both. There are just
two interfaces to the same functionality. The errors he saw with Babel are
obviously bad, but that seems to be a symptom of implementation.

Dropping configuration in favor of convention is a dangerous suggestion. Magic
is great until it breaks, and when that happens you've created an opaque mess
for the end user. I still have configuration, it's just implicit,
undocumented, and spread throughout my environment.

------
__david__
All pretty good points except I'd like to point out that asking an interactive
y/n question is generally a bad idea in a command line app, especially if it's
a superfluous question. A _much_ better idea (if you're into this kind of
hand-holding) would be to print out the command line that sets the default. Of
course you wouldn't want to print this out _every_ time, since it seems like a
reasonable use case to not have a default, so you'd want to keep track and
only print it the first time.

------
erikb
All your ideas are nice, but you obviously have never programmed a thing that
other people use. These results don't happen because they were supposed to
happen. It's just what did happen.

E.g. you hit an exception that should have never popped up. Does it read
badly? Oh well of course it does, because nobody who could have written it
more clearly knew it was even possible to pop up in this instance. He might
have even tested your scenario, but his system package xyz wasn't in version
13.4.12 as yours, but in 13.4.12b, so in his context it worked. You can
minimize these things, but you can't completely make them go away. Even make
them go away most of the time is often too expensive. You can of course also
choose to invest $500k every year into Babel to increase their testing, but I
certainly wouldn't, just to make a few exceptions more readable.

And in fact, if you tracked down from all the context variables why it failed
in your context, you will actually find out that you can track down the change
to an issue and a developer and you can discuss with them how in that case a
better exception can be printed, how the code may need to be changed to
consider the context you are providing etc.

Nothing of this is done better when reading usability guidelines. Just as well
as you and me people mostly know what is good and what is bad. They don't need
teaching in that.

The thing that can be really done is always try harder in your code (when was
the last time you looked into the docs/source of a lib function you use and
catch the exceptions that function can throw, handle some of them and raise
more readable exceptions for the once you can't handle?). Secondly, when you
hit such a situation you can spend the time to track down the error to its
core, write a good issue about it, discuss with the responsible devs what to
do and help implement the solution (have you looked at the underlying library
functions, caught their exceptions... oh, you know what I mean, right? People
often don't do that part). Last but not least when one has done that often
enough to be good at it, to spend time and energy to help some noobs to do the
same (and teach them how to read the underlying library functions).

~~~
avolcano
> All your ideas are nice, but you obviously have never programmed a thing
> that other people use.

This is an unnecessarily rude assumption. Even the most rudimentary glance at
the author's Github page, linked at the bottom of their blog, would have shown
you that the author has created and contributed to multiple popular
applications and libraries.

~~~
erikb
Sorry, didn't mean to be rude. I considered it an observation. If you go to a
university and ask a 2nd year student what he thinks about that topic he will
tell you exactly that: Read some guide about how to do good usability and then
just implement it that way. I think you need to have experienced that, putting
a lot of energy into making a usable tool and then having users running into
such kind of errors that you haven't been able to forsee yourself. Only then
can you understand that it's not about not getting the guide but that the
underlying problems that result in bad usability often are in other areas
(like not enough testing, like not looking into the libraries one uses, like
not fixing bugs in a way that improves the bug's situation as well as the
corresponding error messages). It is less about 'what to implement' (clear to
most devs) it is more about 'how to implement it' (often completely ignored
topic).

In that regard I hope I can make clear why it is not necessarily rude to tell
someone that they haven't made the experience. I have certain assumptions
about climbing mountains, but I have never done that so quite a few of these
assumptions will be wrong or not about the actual points you have to deal with
while climbing. I need to be aware of that, though. Otherwise I will a) think
that I know everything there is to know about that topic and b) I will think I
can give advice to other people how they should do it.

------
EGreg
That depends on who your audience is.

"I need the user's database credentials" \-- cool, find them in this
convenient spot anyone can hack!

"I need the user's facebook and google api keys" \-- cool, find them in this
convenient spot anyone can access!

Obviously, what is needed is an OS-level keychain that can be accessed by the
installer. I wonder if anything like that exists... ;-)

It would be awesome if the user could be walked through creating all the
external accounts, apps and api keys if the external service doesn't provide
an API for this. If it does, then hopefully it provides an oAuth flow for it.

Come to think of it, everything should just be an oAuth flow :)

------
Nutmog
I recently struggled with an application that requires an environment variable
to be set for it to work correctly. That's all. There are no choices where you
might want different behavior. The application is either broken (produces
corrupt output) when the environment variable is not set (obviously the
default state), or working correctly when it is set. I guess that variable
(PRINTF_EXPONENT_DIGITS) is used by some library that itself is broken without
it.

------
spankalee
I almost couldn't disagree with this article more regarding Babel. Babel can't
get away from configuration because Babel has no idea what your target
environment is.

Are you targeting Edge 13 or Chrome 49? Great you only need to compile out a
few features. Are you targeting IE 8? Well, better compile everything. Unless
Babel is to assume the whole world is uniformly stuck at ES5, it simply can't
pick a good default.

~~~
Havvy
Lowest common denominator says to default to ES5, tell people that's the
default, and then show them how to change it later if they want or need to.

------
oliwarner
The problem with several of the arguments made in this article is they are [at
least initially] made as absolute statements. Documentation is always bad.
Configuration is wrong. People are lazy idiots.

It certainly baits more people into response than a moderate argument but I'd
rather see that version than see other programmers cite this one as a reason
to document nothing. That's much worse.

~~~
derefr
I've never quite understood the point in "moderating" the arguments in a
persuasive essay. If you are trying to convince someone who's at -100 on a
spectrum, of a view that's all the way up at +100, then—even if you make the
best points ever and completely "win them over" during the argument—you'll
maybe only sway their day-to-day view to being -50, or possibly as high as 0.

If you tell someone who thinks the sky is blue that it's red, then they'll end
up believing it's purple. If you try to convince them that it's purple,
though, then they'll probably think it's far closer to blue than you meant. If
you _want_ them to see the sky as purple, then you have to insist it's red.

It's sort of a Red Queen problem: people _know_ others use hyperbole and
absolutes to make rhetorical points. So, when listening to an argument, people
internally temper every point they hear to "remove" the rhetorical effect.
Thus, when trying to make a point, you _need_ the hyperbole and
absolutes—because even without them, people will still assume they're there
_anyway_ , and "temper" your point into nothingness.

This isn't to say that _personal opinions_ need to be expressed in such
absolutist terms to have impact, though. When you're giving your _opinion_ ,
you're just telling people where _you_ are on the spectrum. A reader can
pretty easily tell—usually from the different writing style—what's rhetoric
and what's personal thought; and while people engage with (i.e. debate with)
rhetoric, they _compare themselves to_ opinion. When I say "I think the sky is
purple", that's not an argument; that's a way of letting you know that if
_you_ think the sky is purple too, you've got someone to discuss that with.

HN seems to really like anecdote-rich "humble" presentations of (opinionated!)
personal experience, but the persuasive essay has an important place as well.
For every Folklore.org, there's a Unix Hater's Handbook. And although
Folklore.org is certainly _entertaining_ , I've never really seen a
_productive_ debate stem from a post there—certainly never anything that
inspired someone to code up a new project to prove their point.

------
macinjosh
Off topic but does anyone know what terminal emulator is being used in those
screenshots?

~~~
Newbcake
Looks like Pantheon Terminal used in elementary OS

------
stevejones
tl;dr: Stop using Node, it only encourages them.

------
stephentmcm
Are they actually complaining that using a transpiler needs configuration?
Also if-it-ain't-broke-don't-upgrade-it? If they liked Babel v5 why jump on
v6?

~~~
BinaryIdiot
Why does a transpiler need a configuration? Isn't the whole point of it to
transform one set of script to another set? Seems to be a very basic set of
default configuration items could be (and should be) integrated into said
application and allow advanced users to override.

But yeah in node land if you don't upgrade to the latest major you're going to
be left behind in bug and security fixes (good luck finding projects with
actually maintained LTS branches and if they exist they're almost always the
previous major version and nothing further back).

~~~
spankalee
That whole point of Babel 6's design is that it can't know what "set" of
script to compile to. The user necessarily has to know where they want their
code to run.

~~~
BinaryIdiot
The design the fine but the level of intuitiveness is absolutely not fine. Not
shipping the default transformations that the vast majority of developers use?
Or really shipping ANY of them and thus making your initial download not
usable until you download something else? Inexcusable. Shipping a product that
is incomplete unless you get something else should simply not be acceptable in
this day.

------
stn
That's why every time with a new piece of software is coming to my toolbox, I
find myself eagerly documenting all the hoops I had to jump through.

------
phaed
What terminal app is he using there?

------
kennydude
> You are happy and gay.

... What is this supposed to mean in 2016?

~~~
Havvy
The author really likes lesbians - see her twitter feed for example. You can
safely ignore the 'and gay' part as just a bit of her personality coming out
in her artwork as far as the technical argument goes.

------
meesterdude
Actual title: No, I Don't Want To Configure Your App!

Yet ANOTHER needless title edit by HN moderators. Seriously? stop editing the
titles! Not only do you suck at editing them and often butcher the original
meaning and intent, but it's totally unnecessary and adds ZERO value.
Meanwhile, I have to bring it up that you butchered the title, which detracts
the comments from the actual discussion.

Just stop.

Edit: is there any statistics for how often HN titles are different from their
actual articles? Maybe some analysis for how often they changed the tone or
meaning too. Could be a fun little project for someone.

~~~
dang
That level of indignation seems a tad overwrought.

The article title is obvious linkbait, so changing it was called for by the HN
guidelines. People sometimes mistakenly think that the guidelines ask for the
original title to always be used, but that's not so: see
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

In this case the procedure we followed is almost a technical one. First, take
out the obvious linkbait: "no" and "your". That leaves "I don't want to
configure app[s]", and that's misleading, since the article is not about a
personal desire but rather a critique in general of applications that require
configuration. "Don't configure applications" seemed as close to that as one
could get without being either misleading or linkbait. Think of it as dropping
a perpendicular from the point of the original title to the HN guideline.

But that's not to say we got it right in this case, let alone always get it
right. When we do a bad job of a title, a good way to show that is by
suggesting a better one, i.e. one that is more accurate and neutral. If you
read HN often enough to be mad about title changes, you should be aware of how
happily we accept better suggestions from users. Just please don't suggest a
title that goes back to breaking the HN guidelines, since that's always the
reason why we change them in the first place.

By the way, if you think we suck at editing titles, that is likely because you
notice the cases you dislike while the others blend into the background.
Everyone bats zero if you only count the strikes. I'm going to mark this
subthread off topic now.

Edit: ok, let's try "A rant about application configuration" instead of "Don't
configure applications".

~~~
meesterdude
First, I don't think it's linkbait. I see plenty of linkbait on HN, but that
is not. That is framing it from an individual's perspective, and it is an
opinion piece on configuration. You're just reading the words without
understanding the actual meaning behind them, and what that conveys to the
reader when they look at a HN link.

This is what linkbait looks like: watch what these this kid can do with a
keyboard! / 10 tips for a slimmer you! (you wont believe number 3!) / I saved
$3000 a month on hosting with this one trick

Yes, I want you to be editing linkbait titles so they are actually descriptive
and helpful to users. I am grateful for that thankless service. But this isn't
linkbait. and another post you edited wasn't either. And it's REALLY annoying
because in both cases it totally changed the meaning.

here is what I would suggest:

1) make it clear in the guidelines what linkbait is. I think that is not
established.

2) make it clear when a title has been edited in the UI

3) when a title differs from it's original, cite the original, and explain the
reason for the change.

4) only change it if you can really do a better job than the original title;
or if someone else suggests something better. (better being: more descriptive
of the contents). Err on the side of leaving it alone.

~~~
dang
There are many genres of linkbait. You've mentioned some, but indignant
denunciations are another, and so are personal appeals, especially negative
ones ("no, you are not foo", "I am not your bar", and so on.) Such formulas
are bait because they grab people's attention due to human hard-wiring, not
anything interesting. Worse, there's a misattribution-of-arousal effect [1]
where the excitement they induce is enough to guarantee upvotes—lots of
upvotes. HN moderation tries to counter that effect. We don't get every call
right, but I bet you'd be surprised how consistent we are.

I'm happy to have conversations about this stuff, but can imagine little more
soul-destroying than having to come up with a bureaucratic taxonomy of it and
a punctilious rulebook to match. That wouldn't be in HN's spirit anyhow. This
place has always been about having a small number of informal principles and
interpreting them as best we can. The principles are long established; there's
a reason why we change the site guidelines so rarely.

1\.
[https://en.wikipedia.org/wiki/Misattribution_of_arousal](https://en.wikipedia.org/wiki/Misattribution_of_arousal).
I originally wrote "mere proximity" but that was the wrong effect.

------
geralt_g
>rants about ux >not a responsive webpage

~~~
lelandbatey
Many people, myself included, prefer pages which are not responsive. They
require extra work to create, and a _lot_ more work to get universally right.
As an example, this page attempted to be responsive, but it loads like this
one my phone: [http://i.imgur.com/AJwaDWQ.png](http://i.imgur.com/AJwaDWQ.png)

Even then, all it usually saves a phone user is a double tap to zoom into the
article.

~~~
qewrffewqwfqew
+1. I knew what I was going to see before I clicked on your image, not because
I browse a lot on mobile, but because I use a tiling WM with my browser at
~50% width, or around 900px.

That's enough to get most "responsive" websites showing with no left margin at
all, which looks fucking awful. Worse still, half the time I get a hamburger
menu and mobile-style navigation!

Apologies for not adding anything to the conversation, I just had to rant
about another web anti-pattern :(.

------
FLUX-YOU
This looks like it should be easier to install. But I hope this rant and any
contempt was constructed after the fact. If not, google a fucking guide when
you hit the first snag and save yourself some time and grief.

None of those errors are particularly cryptic and neither is that help for
nvm. Don't be impatient

