Elections are bad for democracy - kawera
http://www.theguardian.com/politics/2016/jun/29/why-elections-are-bad-for-democracy
======
jerf
You know, there is so much "Blah blah blah" about how bad democracy is,
implicitly in context because "I think it came to the wrong conclusion" (which
I , that I really expected the article to segue into something that basicaly
amounted to "elites should just be given the power". I expected all the blah
blah was trying to obfuscate this. But that's not where it went.

If you are interested in reading the whole article, please be my guest, but if
you'd like to jump to the payload, use your browser search for "sortition".

(Though I can't help but point out the article undercuts its own premise
accidentally. The EU, to the extent that it is even a democracy, is certainly
subject to the exact same flaws described in the first half of the article!
Therefore, logically, the decision to leave an organization where democracy is
failing must not be so bad, even if it was made by a process that was itself
democratically flawed. This does not "destroy the argument", in the parlance
of the day, but it weakens this particular vote being used as the hook for the
article. A vote on any other topic would arguably work better.)

~~~
nutheracc
Could it be argued that an understanding of how x works is irrelevant, only
the outcome matters, in that individuals who don't understand the workings of
x are still able to tell if the outcome is positive or negative for them, and
vote on that.

~~~
tremon
Not in this case. The full outcome of the Brexit vote will not become clear
for another ten years, probably. Both sides have tried to win over voters by
scheming with "irrefutable facts" that clearly showed the other side's facts
were wrong.

~~~
TeMPOraL
Not only that - ten years from now people will probably assign positive and
negative effects of Brexit to other, more recent causes. The idea of people
voting based on the perceived outcome for themselves is limited by their
memory / attention span. A lot of important decisions, like those related to
infrastructure, have immediate costs but bring benefits only years later.

------
reitanqild
Now, where is the "wisdom of the crowds" when it comes to decisions that we,
"the elites", don't like?

This annoys me. There is no doubt the result would have been "very fair" if it
had been remain.

What we are seeing now is IMO hypocrisy and contempt of ordinary people at a
scary level.

Now, did I want Brexit? No (I had no opinion). Do I think they should have
requested more than 50% of the votes? As a conservative biased person I guess
so, -don't take a risk unless there is clear demand, simple as a discriminator
in electronics: you want to protect against bounces and wobbling...

\- but this should have been said up front, not after losing.

Edit: upvoted this for the discussion, not for the original article.

~~~
brooklyndavs
Its hypocrisy and contempt coming from "elites" via the very institutions that
are critical to a democracy, the media. When the 4th estate works in a
neutral, non-biased, fact based way democracy can work. However, once you have
major media bought and paid for by those "elites" to push some billionaire's
agenda you sow distrust in media. Once the voters don't have a place to go for
trusted information all bets are off...

~~~
TeMPOraL
> _institutions that are critical to a democracy, the media. When the 4th
> estate works in a neutral, non-biased, fact based way democracy can work._

I don't believe mainstream media _ever_ worked in a neutral, non-biased, fact
based way. They definitely have not been for the past few decades I've been on
this planet. _Maybe_ in the past they were more under control by various
"elites", government or otherwise. Now, in the west, they are "free" \- which
means they actually serve Moloch[0], by writing what sells. That is, the most
outrage-inducing, biased misrepresentations (and often outright lies) they can
get away with.

Not sure what is worse[1], but it doesn't matter much. The point is, media
isn't "a place to go for trusted information", it never has been, and if this
is an institution "critical to democracy", then we have a big problem right
here.

[0] - [http://slatestarcodex.com/2014/07/30/meditations-on-
moloch/](http://slatestarcodex.com/2014/07/30/meditations-on-moloch/)

[1] - "elites" at least care about something identifiably human; metaphorical
Moloch does not, so the outcome may be very well something _nobody_ wanted,
including any of the "elites"

~~~
hackuser
> I don't believe mainstream media ever worked in a neutral, non-biased, fact
> based way. ... they are "free" \- which means they actually serve Moloch[0],
> by writing what sells. That is, the most outrage-inducing, biased
> misrepresentations (and often outright lies) they can get away with. ...
> media isn't "a place to go for trusted information" ...

I think painting all news media with the same brush is significantly
misconstrues the situation.

As a comparison, no software developer is perfect and can be absolutely
trusted, and some devs are toxic. But I would be wrong to say: Therefore all
software developers are toxic.

Similarly, there is better and worse news media. Can we absolutely trust any?
Of course not; these are human institutions. But there's a long way from The
Sun and The National Inquirer to The Financial Times and NY Times.

~~~
TeMPOraL
I don't think it misconstrues the situation much.

To follow your comparison - sure, we don't say software developers are all
toxic[0]. But we like to complain that almost all software is shit. There are
gems of almost perfect beauty and usability, and we love them, but there are
so few of those. Here on HN we sometimes like to discuss dynamics of what
makes most of software shit - and we often find similar sort of economic
pressures to those mass media faces.

The thing is, we put extra care in the software that directly affects lives of
people. For anything else, we rarely bother. So if the institution of media is
so important to democracy, maybe we should put some extra care here too.

(Though I don't know how to do that.)

[0] - also note, that I didn't say "all journalists are toxic"; however, the
products of the institutions they form are a different story.

~~~
hackuser
> we like to complain that almost all software is shit

People like to use hyperbole, but IME I've never met someone who thought all
software was bad or equally bad. There is a very wide range of quality.

------
nemo44x
Sortition is just too corruptible and disagreeable I would think. You can
sample a society and "educate" them but then that process will forever be
under fire too.

I believe that in a democracy things should be hard to change. Changing things
should take a super majority. This will lead to more compromise and possibly
better results for all. If there was a 2/3 requirement to change things then
there would be little room for controversial changes to occur that cause an
uproar among the citizenship. There would be more cooperation because to
change something you'd need to compromise with your opponent for them to get a
change they want instead of trying to get a slim majority in the government by
election, etc.

If this principal was applied in the first place the UK never would have
joined the EU and Brexit wouldn't have ever even been an issue. In fact, many
of the things a lot of people find disagreeable wouldn't have happened.

We are divided because we let our form of democracy divide us.

~~~
TazeTSchnitzel
If you impose too high a barrier to change, then laws cannot stay in sync with
society, and that will lead to severe unrest.

~~~
mrec
Yes. I think this is a common misunderstanding about democracy. Democracy is
not good because it provides the best government, or even competent
government; much of the time it manifestly doesn't. Democracy is good because
it provides for stable succession; if a discontented group is strong enough to
stage a successful coup or revolution, then in a democracy it's probably
strong enough to achieve its ends at far lower cost and risk by waiting a
couple of years until the next election.

The EU was founded in large part to prevent yet another European war; that's a
noble goal and for all its flaws I think the EU can claim a lot of credit for
70 years of peace. Warnings against complacency that "it could never happen
again these days" are well-made and well-taken.

But we haven't had a violent revolution or civil war in western Europe for a
fair while either - anything since Franco? - and I think that's largely thanks
to functional democracy. Messing with that is not to be taken lightly either.
You don't have to go back very far to find everyone collectively soiling their
breeches every time a monarch started getting on a bit without a solid heir in
sight.

------
kristianc
This sounds like a variation of Plato's Philosopher Kings, which uses the
'random sampling' argument to get around the obvious criticism of the elites
being given the power.

> The Ship of State is a famous and oft-cited metaphor put forth by Plato in
> Book VI of the Republic (488e–489d). It likens the governance of a city-
> state to the command of a naval vessel and ultimately argues that the only
> men fit to be captain of this ship (Greek: ναῦς) are philosopher kings,
> benevolent men with absolute power who have access to the Form of the Good.
> The origins of the metaphor can be traced back to the lyric poet Alcaeus
> (frs. 6, 208, 249), and it is found in Aeschylus' Seven Against Thebes
> before Plato.

[https://en.wikipedia.org/wiki/Ship_of_State](https://en.wikipedia.org/wiki/Ship_of_State)

Unfortunately, many of the same criticisms apply to sortition as apply to
Plato. The problem is that no-one really has access to the "Form of the Good",
and no-one can accurately predict what the overall outcome of a decision is
going to be over the very long run, however much they study it. In fact, as
Popper argues, you're quite likely to draw the wrong conclusion and end up
going horribly wrong.

On balance, I'd rather put my faith in a large number of people selected from
all social backgrounds than a small number of people selected from a
potentially narrow social background. There's also a sense of shared agency
about the decision making. If it turns out the wrong decision has been made,
what are we to say to the person who is not only on the receiving end of said
bad decision, but wasn't even allowed to vote on it?

It also seems to me that one should be wary about making sweeping statements
about a system that has endured for thousands of years in the wake of a
decision that they themselves disagreed with.

~~~
alienasa
Did you read the whole article? His most significant proposal is that modern
democracies adjust their procedures to use something called "sortition" that
dates back to ancient Greece.

In sortition, rather than polling the entire populace about complicated issues
on which they are likely not well informed, we select a balanced random sample
of people from the populace , provide them information, and then allow them to
engage each other on the issue. Then we have those people vote.

This has several advantages:

1\. It actually places "faith in a large number of people selected from all
social backgrounds" depending on how large your sample, as opposed to letting
elected politicians decide, which is the definition of "a small number of
people selected from a potentially narrow social background".

2\. It solves the problem where a huge number of people end up voting because
of gut instinct or misinformation. Consider the passage of Proposition 13 in
California which prohibits the raising of property taxes. If you poll the
entire population, that referendum is going to win 100 times out of 100,
because for most people the gut check decision is "no I don't want my taxes to
go up". However, the correct way to consider that proposition is to get an
understanding of how property taxes are used, how they are collected, what the
procedures are for changing them in the legislature, etc. and then come to a
determination. That determination might be "Yes", it might be "No", or it
might be "we should not limit increases in property tax rates but instead
limit increases to the real value of collected taxes, by accounting for
changes in property values". [1]

[1] I'm not proposing that is the right answer, I'm just suggesting that you
might arrive at that conclusion if you actually had time to study the issue.
Almost by definition, the vast majority of people do not have that time.

~~~
reitanqild
Sortition is almost what we have elected politicians for isn't it? The default
case?

Referendums are for very important cases were we suspect politicians are out
of touch with ordinary people.

This has been a nagging issue in UK for years and finally they figured it was
better to ask the people.

~~~
tremon
Sortition is based on chance, instead of agreeableness.

Referendums are a great idea, but I think that the British yes/no vote was way
too simple to game. Using hindsight to save the day, given that there appears
to be no gameplan for where to go now, maybe the different options should have
been explored before putting it to a vote:

* remain in the EU

* leave the EU, remain in the single market

* leave the single market

* leave the single market, destroy the chunnel

At least with a referendum like that, you force the people to have a content-
filled opinion, instead of relying just on an empty "no". That also reduces
the options for tea-leaf reading by the losing side.

~~~
kristianc
I wonder if a referendum constructed in that way would actually make decision
making worse.

As I see it, the public have voted to Leave, but some of the options for Leave
are actually quite appealing, and would even appeal to some pragmatic
Remainers (Norway-style EFTA agreement, join Schengen, negotiate trade
agreements with the EU from the outside on a common basis with other EFTA
countries, allow Eurozone to integrate closer).

By allowing the public to decide not only the decision but the details of the
implementation (although I'm sure you weren't 100% serious with the "destroy
chunnel" option) you increase the scope for voters to choose the worst one out
of sheer spite.

~~~
tremon
I'm not sure what you mean with "make decision making worse". Are you
suggesting that having the EFTA option explicitly listed might have made even
less people choose "remain in EU"? I'd say that in that case, the government
has been given a clear mandate on what route to pursue. Right now, I don't
think the Leave side has any idea if the public wants the EFTA option, the
"own island first" option, or the chunnel option.

Thinking about that last option some more, maybe it would make sense to put a
nuclear option (like "destroy chunnel") on the ballot, to weed out the
spiteful votes from the constructive ones. Even if you explain beforehand that
the chunnel will never be closed -- some people just need to vent.

~~~
kristianc
I'm saying that if we're agreed that EFTA is the moderate Brexit option,
having nuclear options (destroy chunnel) on the ballot means that you
effectively give a democratic mandate for the nuclear implementation (which
let's face it, will always be appealing to a substantial minority, see Corbyn)
and sideline moderate voices.

Saying that the public are in control of the direction of travel but leaving
the experts in charge of the implementation (as long as it doesn't go against
the wishes of the public, i.e. politicians can't just choose not to invoke
Article 50, but saying they're free to explore constructive EFTA options)
seems preferable.

~~~
tremon
Given his stance, I find it ironic that you'd equate Corbyn with the nuclear
option...

As I see it, it doesn't really matter if we agree that EFTA is the moderate
brexit option: the primary focus of the Leave campaign was on freedom of
movement, and it was clear (even before the referendum, given the situation
with Norway and Switzerland) that freedom of movement is an integral part of
the single market treaties -- a point reiterated by Merkel and Tusk over the
past few days.

So regardless that you and I may prefer for the Leave side to explore the EFTA
route, it isn't in their mandate -- they won on a campaign of curbing free
movement. Had the "moderate Brexit" been a separate choice on the ballot, they
might have had a mandate to go for that option. But right now, nobody really
knows how many of the Leave voters voted against free movement, and how many
voted "just" against the EU.

~~~
kristianc
Referendums aren't the same thing as elections - they don't come with a set of
manifesto promises or a promised programme of government afterwards beyond
carrying out the policy suggested in the Referendum.

The politicians making the promises may not even be in the government (it
tended to be Leave.EU and Farage that focused on immigration, Vote Leave was
wary of doing the same and focused on the economy). All politicians can do in
a referendum campaign is talk about implied benefits one way or the other.

It's now up to the politicians to work out the best deal for our country. It's
going to be a much smoother ride (and much better for the country as a whole)
if free movement of people is allowed and we join EFTA than if the government
tries to hold firm on that one, for sure.

------
f_allwein
Bit long winded, but boils down to recommending sortition, which I had not
heard of. Interesting:

"With sortition, you do not ask everyone to vote on an issue few people really
understand, but you draft a random sample of the population and make sure they
come to the grips with the subject matter in order to take a sensible
decision."

~~~
humanrebar
Who decides when someone has "come to grips" with a topic? I mean, anyone who
disagrees with me obviously hasn't come to grips with the issue, right?

~~~
jerf
It's very similar to jury duty. And you'd try to use similar mechanisms to
keep the system fair and balanced. And it would have similar failure cases,
but "system without failure cases" isn't really on the table here.

~~~
kiruwa
A jury is a very restricted case. There is a supervising judge and two (or
more) competing advocates. The process for choosing those advocates is very
formalized (defendant selection and public official).

Every one of these other participants breaks the analogy enough to make it
useless.

~~~
jerf
I see I may have skipped showing my work on too many steps here for my point
to have made sense initially. Sorry, my fault (no sarcasm). So, _when you try
to concretely manifest_ the sortition idea, you find yourself stepping in an
awful lot of the same problems you get with juries. With a twist, but very
similar. I'd intend to have advocates on hand for the various positions, and
if you think the bureaucracy won't be stepping in here with procedures and
rules, probably enforced by a process moderator that looks an awful lot like a
"judge", along with formalized rules for the other parts of the process, you
don't know bureaucracies. Surely we don't expect the participants to all be
auto-didacts? And yet, we can't just have one person teaching the relevant
issues, or that one person has too much of the power.

And I don't say this often, but the bureaucrats would be right here. They
would be necessary.

There's no way sortition is going to be "randomly choose 100 people, stick
them in a room with nothing but a problem statement, accept their decision".
It shouldn't be, either; it needs more structure than that. Right down to
things like shielding the chosen participants from undue influences, and a lot
of really interesting questions around transparency... again, quite like a
jury.

~~~
dragonwriter
> I'd intend to have advocates on hand for the various positions, and if you
> think the bureaucracy won't be stepping in here with procedures and rules,
> probably enforced by a process moderator that looks an awful lot like a
> "judge", along with formalized rules for the other parts of the process, you
> don't know bureaucracies.

In a US-like system, if you replace election of leaders with sortition, there
is no superior bureaucracy that can impose a judge-like supervisor on the
sortition-based bodies.

And if you have an bureaucracy that can impose supervision on the elected
bodies you are considering replacing, then you don't have a democracy to
replace with sortition to start with, you have bureaucratic aristocracy, and
talking about problems of elections and democracy is kind of irrelevant to
dealing with your system of government.

> There's no way sortition is going to be "randomly choose 100 people, stick
> them in a room with nothing but a problem statement, accept their decision".

There's basically a couple of possible models of sortition; there's a
legislature-like model (where sortition is how you choose legislators for a
term, and then they are replaced with a new body chosen by the same method.)

And there's a case-by-case model where there is some method of _proposing_ an
issue, and then there is a "jury" chosen for an adversarial "trial" over the
issue. (One way you could do this would be to replace one house of a bicameral
legislature with case-by-case sortation, so that the remaining house would
propose legislation and provide advocates for [and against, usually] that
legislation, who would argue in front of a sortition-chosen panel.)

In the latter, case-by-case, approach, there would probably be some
bureaucracy supervising the process, and the sortition-based body would be
very much like a trial jury in relation to that bureaucracy. But then you
aren't replacing the elected body with sortition, you are replacing it with a
bureaucracy with sortition serving some function within that bureaucracy.)

In the legislature-like approach, though, a supervising bureaucracy is
fundamentally inconsistent with the concept.

> Surely we don't expect the participants to all be auto-didacts?

I would expect members of a legislature chosen by sortition to educate
themselves about issues the same way as any other legislature. This probably
involves a _subordinate_ bureaucratic infrastructure (e.g., staff employed by
each member, and bodies answering to the body as a whole, like the GAO), but
not a _supervising_ infrastructure.

------
323454
Democracy has always been about the people being able to remove their leaders
from power when they become egregiously bad. Kind of like evaporative cooling.
The means by which they choose them is a second order consideration.

~~~
iamgopal
I always understood election as a kind of checking power over whoever is
already at the power, the ultimate authority even above supreme court and
president. Only problem is its not immediate but eventual. Can mass voting
system replace such authority ? [ A robotic president, which will post
questions for which decision needs to be taken for polling via internet, tons
of people choose from the option. ]

------
milesf
"No one pretends that democracy is perfect or all-wise. Indeed, it has been
said that democracy is the worst form of government except all those other
forms that have been tried from time to time."

      - Winston Churchill, House of Commons, November 11, 1947

~~~
noam87
The same could have been said of the horse until someone tried a train for the
first time.

We've never tried sortition on a large scale, and on smaller scales it's
already been shown effective.

A perfect opportunity to experiment with it would be the Canadian senate, IMO.

Also note: sortition _is_ a form of democracy. In fact I would argue it's the
most democratic process proposed which does not run a risk of mob rule. You
still have an "elite" making decisions... only that elite is constantly
changing, is made of a representative sample of the general population, and is
at less risk of being easily corrupted by special interest groups.

It's actually quite beautiful and elegant: so simple, yet it addresses so many
of the criticisms of every other system proposed. While at the same time it's
incredibly flexible in implementation: it can be perfectly fitted to a
parliamentary government structure or any other variation of already existing
governments. Any country or state would be able to experiment with it without
needing a major overhaul of how its legislative/executive branches operate
(only how its members are appointed).

~~~
dragonwriter
> sortition is a form of democracy.

No, its not. Democracy is either direct (in which each citizen has a direct
vote on proposals) or indirect (in which each citizen has a vote on
representatives, who either directly vote on proposals or select other
officials who do.) The _common_ element of democracy is that there is a chain
of choice from the citizenry at large to the decision, what differs among
forms of democracy is whether there are intermediate links on that chain, and
how many, what those particular intermediate links look like.

Sortition is does not share the unifying characteristic of democracy, it is,
instead, one of many forms of rule by an unelected, not-democratically-
accountable elite.

> and is at less risk of being easily corrupted by special interest groups.

People that aren't trying to get _reelected_ , and which are rotated fast
enough to be "constantly changing" (which also means that public attention on
each of them is fleeting), is, if anything, _more_ subject to corruption.

They may be less _valuable_ to corrupt (since you are more likely to be
renting them for a single decision than buying them for a whole extended
career), but I don't think that the combined effect makes them less risk of
being corrupted. At a minimum, I think that claim requires substantial support
that hasn't been offered.

~~~
noam87
On corruptibility, true, it's not been tested so one can't say one way or the
other. But at least in principle it rules out many of the common paths to
corruption.

Let's take four major forms corruption takes: (1) a big bag of money dropped
on your table. (2) I rub your back, you rub mine, reciprocal relationship. (3)
Blackmail. (4) Personal: the desire for power.

(1) is of course still possible, but you're gonna need a lot more bags, and
you're gonna have to be very careful with how you approach. Usually, the path
to bribing someone requires a "romancing" phase; you have to make sure the
other side is open to your proposal and, most importantly, won't give you up.
This is a lengthy process that is much easier when the pool of candidates is
small and doesn't change very often. How valuable is that bag of money when
that person won't have any influence in 4 years' time? You're gonna need a lot
more bags, and you're gonna have to be a lot more careful about who to
approach.

(2) This one is out of the question. These sort of reciprocal relationships
take years to cultivate, and we've immediately removed one of the prime
motivating factors which is campaign funding.

(3) Blackmail. This one will still work, but again: you're gonna need _a lot_
more detective work to dig up brand new dirt, every 4 years, on every member
of a senate. This becomes very impractical. Also I'm gonna go out on a limb
and say the sort of secrets an average sample of the population can be
blackmailed on is not the same as that of a small group of career politicians.

(4) Again, mostly out of question. There is a much higher incentive to pass
laws that benefit people "like you", but not much you can do to benefit
yourself directly (excluding the unlikely chance that the person who drew the
lottery ticket is, say, CEO of some large corporation), and still, this only
works if by some chance a large proportion of other lottery winners are like
you. Otherwise, strategically, the only personal benefit you can get out of a
position of power is to pass laws that benefit the country as a whole.

On the definition of Democratic. Yes, that's a fair point. Or perhaps
sortition lives in a sort of quantum state being both democratic and
dictatorial.

I hope someone manages to test this out. To me it seems obvious that the
biggest threat to society is not climate change, or antibiotic resistance, or
bad economies or poverty: all of these have a single root cause: corruption.

There's no lack of scientific innovation to solve the other problems; it's
corrupt institutions that stand in their way.

Our number one focus as a species right now should be to figure out how
eliminate corruption from our institutions and lessen the impact of bad
actors.

~~~
dragonwriter
Notably, you leave a widely-recognized big source of corrupting influence: a
moneyed special interest establishing a reputation for providing rewards
(often in the form of high-paying jobs) to people in government who serve
their interest when they leave government, without an explicit quid pro quo.

This, of course, remains eminently workable with sortition, especially a rapid
turnover form, where decision-makers will be leaving government soon after
decisions are made and are no longer prefiltered to tend to include people who
have fairly excellent job prospects _even without_ corrupt rewards.

------
thr329889
Democracy is not failing, but elites do. You need to educate people, rather
than labeling everyone who disagrees as a racist.

~~~
zepto
As someone who is actively anti-racist, I weirdly find myself partially
agreeing with you.

Racism is hard to overcome and widespread. People are not either 'racist' or
'not racist'. Certainly people can be pro-racism or anti-racist in their
intentions, but that is separate from how we actually act, since a lot of
racism is unconscious and invisible.

Labeling actions and activities and even groups as racist is necessary,
because we need to become conscious of these forces if we are ever to overcome
them.

However, whether labeled as racist or not, everyone's voice needs to be heard
in the political process. So where I agree with you is in using the label of
racism as a tool to silence or ignore people.

------
kiruwa
This article can be summarized as "Oh no! The 'wrong sorts of people' are
winning! Lets ditch popular elections."

~~~
AnimalMuppet
Or, specifically, the people voted the wrong way on the referendum. Let's stop
letting people vote on referendums.

You see the same thing with the EU Constitution - the voters rejected it in
two countries. That can't be allowed. So we'll do the same thing via the
Lisbon Treaty, but we won't let anybody vote on that, because they might vote
wrong.

~~~
tremon
Yes, the same thing happened with the NL referendum on the EU constitution.
The reason people voted "no" was because they had never been asked before, so
this was their first chance to have their voice heard.

That's about the only part of the article I agree with: if you're going to do
referendums, then do them regularly. Referenda are only a useful tool if the
public feel they really are involved in the process. Otherwise you'll have to
answer for every decision that went around them.

------
Nursie
Ah the Guardian. It's gone into full on hypocrisy mode after the referendum
fell to the 'exit' vote.

It styles itself as the voice for the downtrodden and disenfranchised, but the
moment they make the 'wrong' decision it posts article after article dedicated
to denigrating these same people, advocating their voice be ignored. Quite sad
really.

------
rwmj
There are a ton of great alternatives. My favourite is the Demand-Revealing
Referendum:

[http://stumblingandmumbling.typepad.com/stumbling_and_mumbli...](http://stumblingandmumbling.typepad.com/stumbling_and_mumbling/2007/03/trident_how_to_.html)

------
sametmax
As usual, people confuse democracy, vote, and freedom. In many coutries, we
have vote. In some countries, we have a lot of freedom.

But to this day, we don't have democracy in a single country.

Democracy supposes that the people has the power. It's not the case in what we
call democracies today.

You have a small group of people getting in the election pool because of where
they come from and how much money they can manipulate. Then, this small group
takes most of the decisions, which is what we call an oligarchy.

Voting then, is just a way to swap people from this group. In no way it puts
power in the hand of the people.

Quite often people opposes dictatures with our systems to justify that if they
are in that state, then we are in a democracy. The fact we have a better, and
confortable system doesn't make it magically fit the definition.

For the people to have power, you would need them to want it in the first
place. But most don't read political programs, most don't think hard about
what their country should do, and most certainly don't accept any
responsability for anything happening today in their country. They won't
choose what they buy or whatch on TV according to the impact on the social
life.

Hence, elections are not bad for democracy, it's just we never manage to use
them to setup a democracy in the first place.

In fact, to have a democracy we would need to educate people to want it first.
To make everyday's decisions by thinking about it. And to think about what
society can become on a regular basis.

Right now, as most of us think and act mostly for ourself, we can't achieve
democracy. Democracy cannot be brought only by using a fair political system
(that we don't even have), you also need citizens.

------
xlm1717
>Our voting system worked well for decades, but now it is broken.

Now that the elites don't get the desired result, it's broken.

The beatings will continue until morale improves!

------
hackuser
(Excerpting from another post:)

Most nations are republican democracies, not democracies. People choose the
best of them (or the best person running) to deal with these issues. Direct
democracy, where the people decide issues directly, is actually not part of
the system. The UK has had 3 nationwide referendums and the US none, AFAIK.

There's a good reason for that: The average person has no idea what they're
talking about on most issues. They have other jobs and interests, or no
interest. Do I want the wisdom of the crowds deciding how the military should
be funded and structured, for example, or do I want elected officials who have
hearings, a staff of aids, who study the issue and talk to the generals ...
egads, I pay a lot of attention to public affairs, but I wouldn't want that
responsibility.

Note also that while elected officials are very human and imperfect, their
credentials and experience are far above average.

------
alain94040
I propose a simple fix for major elections such as referendums and
presidential elections. I call it the "really?" approach:

An election needs to get the same results twice back to back.

So for instance, you could replace the primaries and November presidential
elections with that system. Vote once: whoever is first needs to win the next
round to become president. Candidates may decide to drop out, or not. The
public knows: if on round two, they still vote for the candidate that won the
first round, that's the winner.

For the UK referendum, a second vote would have eliminated the protest vote.
You see the results of the first vote, and you really ask yourself: really? Do
I want this to happen? And vote one more time to confirm.

Simple system, with one huge caveat: no guaranteed outcome. But it would
eliminate the need for polling, and hopefully result in better democratic
decisions.

~~~
steve19
The result would be a very low turnout on the first vote, with a meaningless
result that may or may not be representative of the entire population (because
everyone knows the first vote is meaningless so why bother voting), followed
by a large turnout on the second vote... and then followed by howling and
wailing by which ever side loses and the demanding of a third referendum.

Interesting New Zealand recently had a double/two part referendum that was
reported on Hacker News (due the the complexity of changing the National flag)

~~~
kawera
Unless you make voting in the first vote a pre-condition to vote on the second
vote.

~~~
hnal943
to howls of "VOTER SUPRESSION!"

------
Rexxar
The goal of democracy is not to be good but to be fair. Democracy gives people
what they deserve and in the long run they will try to make what is good for
them. Making mistakes is the only way to learn (individually or collectively)
so we shouldn't care too much for each error.

------
Lidador
Qualitative Democracy:
[https://www.youtube.com/watch?v=X5cCyAqCkIw](https://www.youtube.com/watch?v=X5cCyAqCkIw)

------
marcoperaza
I, for one, am exceedingly happy that the media establishment has so loudly
proclaimed their disdain for democracy in the last week. Open your eyes
people, they think they can run your lives better than you and they're quite
upset that you've dared fight back.


Are WhatsApp and Instagram down at the moment? - bholdr
======
svdgraaf
Yeah, partially at least, see
[https://downdetector.com/status/facebook](https://downdetector.com/status/facebook)


Yes, We Will Live with Artificial Intelligence. But It Will Be Friend, Not Foe - Artemis2
https://medium.com/backchannel/a-future-with-artificial-intelligence-friend-or-foe-5e0af3238389

======
api
If it -- they -- are truly sentient, they'll be both. There will be good and
bad and everything in between, just like people.


I've never seen a language's style guide recommend avoiding comments before - vs2
http://www.haskell.org/haskellwiki/Commenting
======
blowski
Avoiding comments that do what your code should be doing is common practice,
and I think that's what this style guide is recommending.

Comments are useful to describe __why__ you're doing something, often when you
are not able to change the unexpected behaviour. Whenever I build an API
library, my code is littered with comments like "Acme Corp API requires this
happens before that" with a link to that bit of the API documentation.

Here's a C++ example about "documenting surpises" (taken from Steve
McConnell's Code Complete:

        for ( element = 0; element < elementCount; element++ ) {
            // Use right shift to divide by two. Substituting the
            // right-shift operation cuts the loop time by 75%.
            elementList[ element ] = elementList[ element ] >> 1;
        }

And a Java example:

        /* The following code is necessary to work around an error in
           WriteData() that appears only when the third parameter
           equals 500. '500' has been replaced with a named constant
           for clarity. */

        if ( blockSize == WRITEDATA_BROKEN_SIZE ) {
             blockSize = WRITEDATA_WORKAROUND_SIZE;
        }
        WriteData ( file, data, blockSize );

He also gives a whole list of situations in which comments are a bad idea, and
it's similar to the OP.

~~~
augustl
Completely agree :) In some cases I prefer to wrap it in an aptly named
function, but in other cases I prefer the whole algorithm to be in a single
function, making comments a very useful tool for "naming".

~~~
couchand
_in other cases I prefer the whole algorithm to be in a single function_

A modern compiler can inline most of your function calls if you like. That way
you can factor the code appropriately for both concerns.

~~~
josephlord
Putting the whole algorithm in a single function isn't for the compiler's
benefit but for the reader's. Especially in languages with side effects any
function call you need to analyse takes time and then you need to come back to
the main function and remember your mental state.

Please note that in many cases putting an algorithm in a single function is
the wrong choice but there is also a cost in splitting it.

------
rotten
Of course everyone thinks they always write good clean code and therefore
don't need comments to elaborate on what the heck is going on.

Unfortunately, having been doing this trade for 30+ years, I've found most
people write crappy code in a hurry to try to hit some deadline based on
incomplete requirements and confusing business rules. A few precious comments
stuck in there can help the next guy, months or years later, figure out what
the heck your original intent was or why a block of code exists at all.

As I get older, I find it helps me remember what I was doing.

One of my software developer friends was fond of saying: "the worst code I
ever saw was my own!"

YES if your code is clean and elegant and well named and clear you don't need
to explain anything in common language.

YES you should strive for such.

However, the REALITY is your code sucks and no one is going to want to have to
figure out what the heck you were doing. A few comments would really help.

The next reality is that the typical developer may be literate in a dozen or
more languages and the language du jour that you coded so elegantly in has
fallen out of favor and no one remembers those dusty corners you so
beautifully exploited to make something work.

Comments would help even more if you learn to use some basic grammar and
spelling when you create your comments. (It doesn't have to be literature, but
try to make your comments as readable as you think your code is - please!)
Nothing will turn another developer off to trying to decipher your code than a
few comments that make you look like a moron.

Style guides that eschew comments, IMO, are counterproductive. They feed on
the developer's ego and disregard reality.

Comments cost essentially nothing to add to your code and can save it from an
early death and complete refactoring by the next guy who comes along.

~~~
augustl
I wonder where the idea comes from that people that write code that's hard to
understand, will write comments that are easy to understand.

~~~
DanBC
Good programmers sometimes have to do weird things.

Leaving a note about that weird thing is probably a good idea.

~~~
notduncansmith
In my experience:

A novice programmer will just do the weird thing (no comments).

An intermediate programmer will spend twice as much time as they should,
trying to think of an elegant solution, before doing the weird thing anyways
(and maybe leaving a comment).

A good programmer will just do the weird thing, leave a comment, and move on.

~~~
dllthomas
I somewhat agree, except possibly for the "should". I think that trying to
think of an elegant solution (and then accepting that you can't, where
appropriate) is an important learning process. Of course this depends on
context; spending time on learning is sometimes inappropriate.

~~~
notduncansmith
I agree with that. Perhaps more accurate phrasing would be "more time than the
seasoned developer would have". Part of getting to the third stage is learning
those types of lessons during the second stage - which only comes with
experience.

------
denizozger
Robert C. Martin's Clean Code book has a great section on comments:

\- The proper use of comments is to compensate for our failure to express
ourself in code. Comments are always failures. We must have them because we
cannot always figure out how to express ourselves without them, but their use
is not a cause for celebration. So when you find yourself in a position where
you need to write a comment, think it through and see whether there isn’t some
way to turn the tables and express yourself in code.

\- The older a comment is, and the farther away it is from the code it
describes, the more likely it is to be just plain wrong. The reason is simple.
Programmers can’t realistically maintain them.

\- Comments Do Not Make Up for Bad Code! One of the more common motivations
for writing comments is bad code. We write a module and we know it is
confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh,
I’d better comment that!” No! You’d better clean it! Clear and expressive code
with few comments is far superior to cluttered and complex code with lots of
comments. Rather than spend your time writing the comments that explain the
mess you’ve made, spend it cleaning that mess.

``` // Bad:

        // Check to see if the employee is eligible for full benefits
            if ((employee.flags & HOURLY_FLAG) &&
            (employee.age > 65))

        // Good:
        if (employee.isEligibleForFullBenefits())

```

~~~
notduncansmith
Sometimes, comments are a justification. Sometimes you have to do things that
seem like the wrong thing to when reading the code (like sending a POST
request instead of a GET when a GET is clearly more appropriate, but you have
to talk to a poorly-written API that will only respond to POSTs on that
route). Comments help rationalize that decision for the next guy.

I also find TODO comments quite helpful. It requires far fewer brain cycles to
process a TODO comment than to parse the code, figure out what it's doing, and
make an assertion that it's incomplete.

Comments can also make code much more approachable to junior programmers, who
may not have heard of principles like Tell Don't Ask, or Composition Over
Inheritance. When I'm working with a junior dev, I find that comments usually
reduce the number of interruptions I receive that are along the lines of, "Hey
why did you do this thing this way?"

Really, it's just not a good idea to make sweeping generalizations like,
"Comments are always failures". The real world has time and budget
constraints, and comments are sometimes the most effective way to satisfy
those without screwing the next developer to read the code.

~~~
dllthomas
If you're systematic about the syntax of your TODO comments, you can also 1)
jump to them, 2) traverse them in order of priority, 3) automatically surface
changes to the list of TODOs as comments in commit messages, and 4) use commit
hooks to refuse to commit code with overly severe TODOs to certain branches.

~~~
notduncansmith
I do 1) pretty frequently, and while I don't go so far as 4), I do use total
TODO count as a heuristic from time to time.

~~~
dllthomas
Yeah, I've never got as far as 4. I do 1-3 on my main project at my day job.

------
shabbyrobe
I see rubbish like this in PHP (and Java) code all the time:

        /**
         * Frobnicates a foobar
         *
         * @param Foobar $foobar The foobar to be frobnicated
         * @param int $intensity The intensity with which the foobar will
         *    be frobnicated (defaults to 4)
         * @return mixed The result of frobnicating a foobar
         */
        function foobar_frobnicate(Foobar $foobar, $intensity=5)
        {
            // frobnicates the foobar
            return $foobar->frobnicate($intensity);
        }

It's utterly ridiculous.

Pretty sure I've been guilty of this in the past, too. As I recall, the
documentor tools make a lot of noise if you don't supply wasteful and
irrelevant values for every single little thing even if it's blindingly
obvious from the symbol, context or idiom what it means and what it does.

~~~
SchizoDuckie
I think we can all agree that this is the most blatant example of useless
documentation.

~~~
w0utert
It's a bit contrived but it's not even as useless as it would appear to be (if
you forget about the likely intentional mismatch between the default value and
its documented value).

The purpose of this comment is obviously not to clarify the code for someone
working on it, but to ensure the automatically generated API docs stay
consistent. I write comments like these above functions all the time, because
we have a zero-warning policy for doxygen comments over here, to prevent
people forgetting to document public API methods (or slacking off out of
laziness). Sure, the comment block is redundant since it contains nothing that
cannot be derived from the parameter names and the name of the function, but
it does make sure a doxygen run will not spew warnings and errors all over the
place, drowning out uncommented methods with far less obvious functionality or
parameters. The redundancy is a small price to pay to enforce a good self-
documented API.

I really don't understand any of the discussions about not documenting code
because it should be 'clean and obvious'. First of all that's mixing up 'how'
and 'why' code is like it is, second it's a small effort to write and maintain
code comments (contrary to what some people like to suggest otherwise), third
it can help you organize your thoughts while you are writing the code (write
the steps of your algorithm in comments, then translate them to code), etc.

Personally I also like how the syntax highlighting breaks up blocks of code
with API doc comments, which makes it much easier to see where functions start
and end when scrolling fast, or how they can separate distinct steps of an
algorithm. 'No comments' really is the inverse of 'literate programming', like
most of the time, the truth is probably somewhere in the middle.

------
dons
Hmm. This is just one guy's style guide on the public wiki.

[http://www.haskell.org/haskellwiki/index.php?title=Commentin...](http://www.haskell.org/haskellwiki/index.php?title=Commenting&action=history)

It isn't official in any sense.

~~~
mike_hearn
Right, also, it doesn't actually say avoid comments, it just gives examples of
where it's best to try and find an alternative.

In the bitcoinj code style guide there is a big section on comments that gives
positive examples as well as negative examples:

[http://bitcoinj.github.io/coding-
conventions](http://bitcoinj.github.io/coding-conventions)

------
duncan_bayne
I've always treated comments as code smells. Not necessarily something bad,
but something that at least suggests the possibility of suboptimal code.

One of the best cases for comments IMO is documenting an unexpected behaviour
on the part of a third-party API. But even then, correct exception / error-
handling code can obviate the need for comments in many cases.

If I'm reading code (from an experienced programmer) and I see a comment, I
immediately pay attention, because Here Be Dragons.

~~~
Boldewyn
The situation must be differentiated by language/environment. The suggestions
for Haskell are certainly not bad. They hold, too, for many systems
programming.

For scientific coding, comments should align with the underlying theory for
the code: “This implements matrix transposition with regard to ... as defined
by ...”, so that next generations can align code with papers better.

And when you’re in a wacky environment like the PHP runtime or coding for a
moving target like the browser, comments might be indispensable to explain one
or the other really strange way of doing things, where you simply have no
other choice. Look at the [jQuery source
code]([https://github.com/jquery/jquery/tree/master/src](https://github.com/jquery/jquery/tree/master/src)),
where they comment excessively, which browser quirk they address with which
work-around.

~~~
nmrm
> For scientific coding, comments should align with the underlying theory for
> the code

100x this. Scientific software should be held to a different set of standards
than non-scientific software, primarily because you can probably not assume
that your reading is familiar with the underlying domain.

~~~
dragonwriter
> Scientific software should be held to a different set of standards than non-
> scientific software, primarily because you can probably not assume that your
> reading is familiar with the underlying domain.

As someone who works as a programmer and system analyst dealing with code in a
non-scientific business domain where I've also worked on the domain side, I
don't think that this separates scientific code from any other codes.
Programmers often disdain domain knowledge beyond that which they already have
found to be immediately relevant. Which is perfectly understandable -- there's
a reason they chose to specialize in programming rather than as domain experts
in whatever domain.

~~~
nmrm
I thought through this some, and your comment resonates -- it's not right to
set aside scientific code from other code with a complicated domain.

But I think complicated program segments related to business practices etc.
also deserves comments, even just "see spec xyz" or "see section 1.2.3 of code
xyz" (similar to how you might say "See Smith et al. '14" in a scientific
setting)

------
koonsolo
Comments say _what_ your code does, your code says _how_ you do it. The swap
example is trivial, but for most functions it is good to add an API comment,
because how you use the function shouldn't depend on how it's implemented, but
what it should do, described in the comment. That way you can change your
implementation as long as you don't change the contract. In other words,
changing how your code does something shouldn't therefore change what it does.
And this last part is specified in the comment.

~~~
icebraining
Well, this is Haskell we're talking about. Between the name, type signature
and the fact that most functions are pure (so, no side-effects to describe),
it's often obvious what they do.

~~~
tveita
Like

      (<+>) :: Monoid m => m -> m -> m
      (^?) :: s -> Getting (First a) s a -> Maybe a

As a Haskell beginner I didn't find it to be a particularly self-documenting
language. Between the use of custom operators and point-free style you can
write a lot of code without naming anything to give a hint about what you're
doing.

~~~
vamega
So as another Haskell beginner, let me take a stab at the first one.

      * Return the first parameter
      * Return the second parameter
      * Perform param1 `mappend` param2
      * Perform param1 `mappend` param2
      * Return the mempty value for the Monoid m

The first two are unlikely to be correct, since if all they were doing was
returning a particular parameter, then there is no reason to have the Monoid
type constraint. The last one similarly makes no sense, since it's a function
that is identical to `mempty` irrespective of it's parameters.

The order of operations however should be documented. I'm almost certain that
the implementation is the third function, but a one line comment stating that
could _possibly_ be useful.

All of my above reasoning was predicated on an understanding of Monoids. So
while I'm not sure the right thing to document is the function, I do think an
explanation of `Monoids` should be documented in `Data.Monoid`.

PS - Where is that first function defined? I've used a similar operator
defined in XMonad, but if I remember right that was defined over Arrows. Also
is that second function from Data.Lens?

~~~
dllthomas
I assume line 4 was meant to be:

        * Perform param2 `mappend` param1

I'd be a little surprised if it was the third option, simply because that's
already spelled <>. Hoogle doesn't turn up a definition with that signature,
though.

------
mbrock
Here's a small function from a real world module used in a Haskell web
backend. It decides whether a "work unit" is appropriate to pick from a queue.
The first iteration was a pretty complex piece of code. When I refactor, I
often think "this is unclear and should be commented," but I've learned
instead to think "this is unclear and should be factored out and given a
significant name." So I ended up with this:

        shouldPickWorkUnit :: (ImportId, WorkUnit) -> STM Bool
        shouldPickWorkUnit (k, u) =
          case hostNameFor url of
            Nothing       -> return True -- Invalid URLs are fast to process.
            Just hostName ->
              takeWorkThat'sAlreadyDone <*>
                (don'tTakeSomeoneElse'sWork <*>
                  don'tExceedTheRateLimitFor hostName)

This way, the domain logic is legible from the actual code, which strikes me
as almost always better than having tricky code with comments. Trying for this
also encourages "domain-driven abstraction," and this is one of Haskell's
greatest strengths.

In fact, the remaining comment can be factored away too:

        shouldPickWorkUnit :: (ImportId, WorkUnit) -> STM Bool
        shouldPickWorkUnit (k, u) =
          takeWorkWithInvalidUrl <*>
            (takeWorkThat'sAlreadyDone <*>
              (don'tTakeSomeoneElse'sWork <*>
                don'tExceedTheRateLimitFor hostName))

Advice like "avoid comments" needs to be taken as a calling for actually
spending time and effort to write obvious code, and for using appropriate
abstractions!

------
krzrak
It's doesn't recommend avoiding comments - it encourages to write
understandable code and avoid meaningless comments. It is a basic rule of the
clean code.

------
SchizoDuckie
The thing with comments is: You should add them for people that don't want to
read your code line by line.

I don't want to run my internal compiler in my head when i'm reading your
code, so you better make sure there's at least a docblock above every function
that describes in 2 sentences what it does so I can get a global overview of
what the heck this file is doing.

People that suggest that 'the code is the documentation' are always forgetting
that reading code is way more taxing on the brain than reading english.

~~~
ARussell
That is exactly why once should take the time to give meaningful names to
their functions, classes, and methods. If you are having a difficult time
doing it, your piece of code is probably doing too much. Split it into pieces
that are more easy to name.

~~~
SchizoDuckie
I already assume you are using meaningful names for functions, classes and
methods, as any self-respecting programmer will do.

I can completely live with a 50 line function that does _magic_ in a legacy
project, as long as I don't have to read through it.

'split it into pieces' is everybody's favorite argument, but nobody is going
to pay you to refactor it. DOCUMENT IT.

------
kasey_junk
I've found there are several topics that even qualified, experienced,
reasonable developers will always disagree on. dynamic vs static typing, YNGNI
vs future proofing, IDE vs no IDE etc. Usually, a given developers opinion on
these topics is informed by their specific experience and what has bitten them
in the past.

Code comments definitely fall into this category. I've worked with developers
who I greatly respect who are obsessive about code comments. I've even been
told that the comments are more important than the code and in that specific
context it made sense.

But my own experience and biases make me think code comments are a problem. I
like to refer to them as future lies. There is virtually no back pressure on
comments to keep them in sync with the code. There is no automated way to
verify them and refactoring tools on comments are rudimentary at best. To put
it simply, I no longer trust comments and will usually ignore them in order to
verify the code itself. I can't count the number of times I've found comments
that directly contradicted the code it was commenting. It isn't even uncommon
to find comments that are incorrect when they are written!

As to the folks recommending comments that document the "why" of a piece of
code, I'd counter that if you have a "why" you have a specification. If you
have a specification it should be verified in a systematic way. So performance
improvements, or specific client requirements should be encoded in tests so
that they don't regress. Comments do not provide that safety.

That's not to say I never comment my code. Just that it always feels like a
failure when I do. It is usually because it is cheaper to comment than to
provide cleaner code or better verified specifications.

------
callum85
It seems like no one here shares my opinion on this: I really like comments,
even if they just restate, in English, what the code does. I don't think
that's pointless. There is big value in it. I can scan and mentally process
English sentences much faster than code. With a heavily commented file you can
just skim through the comments until you locate the part you need to work on
(then slow down and read the code around it and edit it).

Look at the Backbone.js annotated source [1] (the stuff on the left is just
the comments pulled out from the original source JS). The comments make it
much, much quicker to grasp what's going on, even though many of them just
state exactly what the corresponding code does, which according to the Haskell
docs' advice is pointless and to be avoided.

[1]
[http://backbonejs.org/docs/backbone.html](http://backbonejs.org/docs/backbone.html)

------
krat0sprakhar
> I repeat: Try hard - very hard - preferably repeatedly - to remove
> unexpected behaviour from your program. Comments can never fix unexpected
> behaviour.

This is golden!

------
nodesocket
I've seen this many times:

        ...thus they (comments) tend to diverge from actual implementation.

It happens, you update/refactor code, and forget to update the comments. Thus
the comments are outdated or worse not applicable anymore. Common mistake by
less-detailed oriented developers. Begs the question, in this case is is
better to have confusing/incorrect comments, or no comments at all?

~~~
seanmcdirmid
No comments are better than bad comments. There is nothing worse than a
misleading description.

~~~
dspillett
I've always gone with the adage: if the comment and code do not agree, don't
assume that either of them are correct.

A bad description isn't just a problem in itself, it can indicate a worse
problem sat waiting to jump out and bite as you walk by.

~~~
rtpg
comments might diverge from behaviour but the code, almost by definition
(modulo some crazy magic happening/broken interpreter ) _is_ the behaviour.

~~~
seanmcdirmid
The best commenting system is a debugger stepping through the code.
Unfortunately, I've yet to see a commenting style that is able to really
document mental models about how the code works.

~~~
nirvdrum
SEURAT is a research project that attempted this. I was a test subject for it
a while back and found it pretty interesting. But its implementation at the
time was an Eclipse plugin that probably hasn't been kept up todate. You can
find a paper on it on the ACM digital library:

[http://dl.acm.org/citation.cfm?id=1368215](http://dl.acm.org/citation.cfm?id=1368215)

I'm sure the dissertation is available somewhere on cs.wpi.edu, too.

------
Nursie
I'm a big believer in function level comments in code, in a sort of doxygen-
ish style (I write mostly C).

It allows you to document the intended inputs and outputs of the function and
state its purpose. This increases maintainability and reusability.

Functions themselves should be short and written as a sequence of logical
steps.

I'm also a big fan of doing things right rather than just hacking until it
works, which seems to put me in a minority.

~~~
icebraining
But the thing is, in C a geocoding function would probably receive two ints
and return a string, while in Haskell you'd probably have a function of type
"Location -> Address". The type system obviates much of the need for those
comments.

~~~
Nursie
Indeed, a solid type system would remove some of that need, in C it can be
_very_ important to document what _precisely_ that pointer is pointing to. Is
it a provided buffer, something allocated and returned? Multiple or single
element? etc etc.

I'm guessing Haskell doesn't need that? A simple statement of purpose would
still help though?

------
yxhuvud
Comments are lousy for describing _what_ you are doing, but there are no
alternative to comments for describing _why_ something is done.

------
chiachun
Similar thoughts were seen in the SICP book.

"In this book we don't use many comments; we try to make our programs self-
documenting by using descriptive names."

[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-15.html...](http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-15.html#footnote_Temp_197)

~~~
_delirium
From the era when two poles were Lisp and C, I can sort of see that. In part
because of the preference for longer identifier names in Lisp, versus cryptic
abbreviations in C, _some_ kinds of comments prevalent in C aren't as
necessarily in Lisp. Instead of atoi() you'd have something like _convert-
ascii-to-integer_.

In modern Lisp, though, it's still considered good form to include both a
docstring, and internal comments explaining anything particularly tricky.

------
tibbe
Note that this isn't the "official" Haskell style guide. We don't have one
(although we probably shouldn't). This is one of the competing guides out
there.

------
dheera
I'd say the language design and language ecosystem has a LOT to do with it as
well. Here are a few lines of Java that I just had to write about 10 minutes
ago.

      PendingResult<MessageApi.SendMessageResult> pending = Wearable.MessageApi.sendMessage(mGoogleApiClient, mWearableNode.getId(), path, data);
      pending.setResultCallback(new ResultCallback<MessageApi.SendMessageResult>() {
          @Override
          public void onResult(MessageApi.SendMessageResult result) {
              ....
          }
      }

Okay, now suppose this were a Python-based API instead? Perhaps it could be
something like this, after some relevant initialisation:

      wearable.sendmessage(mywearable, path, data)

      @wearable.onresult
      def onresult(result):
        ...

Tell me which one is more in need of commenting.

------
skriticos2
I totally agree with this. I like to put a bigger comment block at the top of
my source files explaining the overall concepts and data structures used and
then put few actual comments in the code. Instead I think about my variables
and function names and make them talk for them-self. Commenting each and every
element of your code will just make people (possibly yourself) curse at you
when debugging your code and realizing that the comment was rendered obsolete
15 iterations prior and the code does something entirely different.

~~~
AlisdairO
I generally sympathise with your sentiment - I think this jives fairly well
with comments talking about 'why' rather that 'what'. I do favour function-
level comments quite a bit for more complex functions.

That said, I think some of the commenters in this thread should spend time
maintaining a MLOC+ sized code base before dismissing comments as 'code
smell'. Even in well-written code, if you're a maintenance programmer who is
unfamiliar with a particular functional area, a few comments talking about the
overall purpose of the code and why it works the way it does can save you
enormous amounts of time.

Finally, if people are letting comments go out of date, IMO they have a
quality issue. Either the comments are useless and should be removed, or
they're useful and should be kept up to date. If your developers are letting
useful comment areas go out of date, it should get caught by code review.

------
josch
Leo Brodie says in "Thinking Forth" in the style section: "The most-accurate,
least-expensive documentation is self-documenting code". I am sure there are
other prior examples.

------
kevinpaladin
I agree. Comments sometimes make it difficult to go through the source code.
That's why I always loved Java naming convention that suggests variables and
method names to be self-explanatory.

------
gaelow
I currently write docblocks for everything I code.

It's crazy how much time I spend on them and sometimes they are confusing
because the specs change and I keep forgetting to add/remove/update something
in a docblock when I rewrite some part of the code it documents (I'd say
between 10-20% of my commits are docblock updates).

I believe brief or even no documentation may be the best approach until you
are on the verge of releasing a stable version.

While you are on developing and testing mode, it seems a better idea to forget
about comments and focus on modularity.

After all, Why would I need comments if all the rest of my team sees is an
interface satisfying a previously established and well defined contract?
That's why docblocks should be only documenting public interfaces, some kind
of dump taken from the part(s) of the contract they implement.

I'd consider instead other top priorites on those phases:

\- Keeping an homogeneous codebase in regard of design and coding guidelines
and conventions.

\- Re-factoring before it becomes a problem

\- Writing neat unit and integration tests

And, the most important:

\- Keeping a channel open with the client, constantly feeding guided demos and
prototypes showing your progress to make sure you are on the right track and
you didn't get it backwards, updating specs and being realistic about what can
be done and what not in which time frames with the provided resources.

------
stared
> I've never seen a language's style guide recommend avoiding comments before

An official style guide? Maybe. But it is one of common philosophies. See for
example:

"If you need to comment something to make it understandable it should probably
be rewritten."

[http://kotaku.com/5975610/the-exceptional-beauty-of-
doom-3s-...](http://kotaku.com/5975610/the-exceptional-beauty-of-
doom-3s-source-code)

------
otikik
The stablished policy is: "don't use comments to replace proper names and
abstractions".

I wrote more about this here (it's Lua code, but it applies to any language):

[http://kiki.to/blog/2012/03/16/small-functions-are-good-
for-...](http://kiki.to/blog/2012/03/16/small-functions-are-good-for-the-
universe/)

------
bnegreve
This is not convincing to me because the examples are trivial:

        -- swap the elements of a pair
        swap :: (a,b) -> (b,a)

Yes this is redundant.

        let b=a+1   -- add one to 'a'

Yes this is also redundant

Does it mean that every piece of code can be expressed as clearly as in a one-
line comment in natural language? I don't think so.

~~~
lawn
The argument is not to never use comments, but rather to avoid bad comments.

~~~
bnegreve
I realize this, but the article doesn't provide any clear definition of what
actually is a bad comment. It only gives trivial examples of bad comments such
as "increment a by one".

Since I don't think anyone here would argue that "increment a by one" is a
useful comment, the part about duplicate/obvious comments isn't adding much to
the discussion about the usefulness of comments.

Nevertheless, it's true that comments cannot be checked by the compiler, and
that's a more interesting point, I think.

------
samuli
The article correctly advices against commenting the obvious. I think it is
often practice by novice programmers to assure themselves about what the
language expression actually does.

What the article omits is the suggestion of commenting the right way, i.e.
adding reasoning or the description of the high level logic behind the code.

~~~
timnic
Yes, obviously the examples given in the link are bad style of comments. But
sometimes you need to explain the reasons behind the (Haskell) equations, just
like one would do in a Math paper. So there's a use case for the literate
Haskell files *.lhs
([http://www.haskell.org/haskellwiki/Literate_programming](http://www.haskell.org/haskellwiki/Literate_programming)).

------
jabbrwcky
Code may explain _what_ your code is doing, not necessarily _why_ it is doing
what it does in the way it does.

Comments may be a code smell when it is necessary to explain what your code is
doing.

Anywhere where you have some freedom to solve a problem one way or the other
it may clarify why the implemented approach was chosen.

------
vince_refiti
Comment only magical code, but don't write magical code.

------
ilitirit
There are times when you absolutely want to comment something like an "Add" or
"Swap" function.

eg.

// The reason we use a custom swap function instead of

// the one that is shipped with the framework is because

// of an edge-case that occurs quite frequently in our

// scenario

// Refer to Change Request 345.

void Swap (Foo a, Foo b) ....

~~~
ricardolopes
I think you are missing the point there. Sure, I completely agree with you
that those comments are crucial, but they are not informing about the code
doing a swap, they are explaining the need of the applied workaround.

~~~
notduncansmith
That's precisely the point. In most cases, _what_ your code is doing should be
obvious; the _why_ , as others have stated, would be otherwise completely out-
of-band information, which explains the necessity for comments.

------
agumonkey
Comments I liked to write were when I found successive optimizations (lots of
symmetries in the algorithm) leading to very short code. Almost too factored
to be understood easily so I added a comment wall above telling the steps I
went through before hitting the final code below.

------
transfire
It is easy to spot (most of) the experienced coders from the newbie coders.
Any programmer who has written his salt worth of code knows that comments can
save your ass. Come back to some code ten years later and you can sit there
staring at a bit of code no bigger than your thumb wondering what the hell it
does and often it doesn't become clear until you shove some test samples down
its interface and see the result. Whereas a simple comment is all it would
have taken to clear it up from the start. People who argue that comments can
get out of whack with code, well, of course they can, but that's no excuse.
That's just a failure on the programmers part to always update comments when
the code changes.

------
nrzuk
Personally I have no problems with comments in code for complex functions etc.
But pointless comments like this below drives me insane.

// get the user $user = $this->getUser();

Times that by the thousands of lines in a project and you have one big
headache!

~~~
otikik
> Personally I have no problems with comments in code for complex functions
> etc

I hope you have a problem with complex functions. (They should be made as
simple as possible).

~~~
seanmcdirmid
Why fear complexity when its the only way to get something done, other than
not doing it?

~~~
krzrak
There is no such complex function that can't be decomposed to bunch of
simple(r) functions.

~~~
seanmcdirmid
Often only with a deep understanding of the complex problem to understand its
simplicity. But you have to ship in 4 weeks, so why not just get something
working first?

~~~
krzrak
> But you have to ship in 4 weeks, so why not just get something working
> first?

Of course, this sometimes happens, but it shouldn't be encouraged. This way
you are creating technical debt, which will be very expensive to pay off.

~~~
seanmcdirmid
I actually work on problems that haven't been solved previously (or why not
just get a dev to do it rather than a researcher). I get offended when some
dev who writes web apps connecting to databases all the time says "all code
should be simple." They really don't have a clue.

------
riquito
It's often a good idea to comment "why" the code exist, if it is non-obvious
(e.g. it's obvious to sanitize input parameters). The comment must be short
and possibly point to a ticket wrote somewhere else.

It may be a good idea to comment "what" the code does, if it isn't clear (the
code itself is "how" it is done, but "what" does it do may be hard to read,
e.g. sometimes you use a clever hack for performance reasons).

As always, handle with care :-)

------
MerreM
I was always told that if someone couldn't tell what your code was doing by
glancing at it, you'd done it wrong and should re-write it.

I know that's absurd in practice, we don't always have the time but I've
always used comments as a last resort.

If I need to comment code to make it understandable at a glance, so be it but
I'd rather avoid them all together and rewrite until it's clear enough without
them.

~~~
collyw
I disagree with that sentiment.

Using Python or Perl it is easy to go from a for loop to a map or list
comprehension. For many less experienced programmers it will make it less
readable and more difficult to comprehend. Using a more functional approach
will usually lead to less side effects and silly bugs, so I prefer to code
this way, and add a comment to explain what the line is doing if it is not
obvious.

------
daemonk
Write comments that explain why a certain line is there.

Let's say you are parsing a standard tab delimited file. You find that the tab
delimited file has some non-standard features, so you have to write some extra
lines of code to handle it. For people who thinks the code just parses a
standard tab delimited file, these lines will be confusing, so you comment
these lines and say why you included them.

~~~
auxbuss
Or create a function to handle that case, name it appropriately, and call it.
Thus, no comment is required. You can also test the additional method in
isolation, if you wish.

I appreciate that this type of thing is language dependent.

------
kelvin0
This style guide is NOT against comments. It is just stating the obvious best
practices which have always been around for all languages ...

------
tomp
This submission needs to have a different title. It's not very clear whether
the submitter is being genuinely surprised or sarcastic.

~~~
javert
I would say, never assume sarcasm is in play unless it's absolutely clear. So
I think this title is fine.

If the OP meant to be sarcastic, that's just like me saying "yes" when I mean
"no"\---my mistake, not yours, and you can't be blamed for assuming I meant
what I said.

------
bnelissen
This style guide DOES recommend avoiding unnecessary comments and is an easy
one to understand and remember. Good start for all novice coders.
[https://google-styleguide.googlecode.com/svn/trunk/shell.xml](https://google-
styleguide.googlecode.com/svn/trunk/shell.xml)

------
GazNewt
Linkbait title. Rolls eyes yet again.

------
wglb
Martin Fowler's _Refactoring_ says that, possibly paraphrasing here, most
comments are bugs.

I do favor putting a short comment on some methods/functions/procedures.

------
scott_karana
Articles about writing code without commenting sound like articles about
driving your car without using the brakes: theoretically possible, but
impractical.

------
LeicaLatte
Its quite common in coding communities and style guides.

------
igitur
Comments aren't necessary at all. If the code was difficult to write, it
should be difficult to read. :-P

------
judk
Read the linked page. This one doesn't either. It says to prefer fixing bugs
over documenting them.

------
viach
To rephrase - code makes comments understandable?

------
Myrmornis
The article is spot on. Comment as last resort.

------
warrenmiller
Good code should be self documenting.

~~~
aikah
> Good code should be self documenting.

Good code needs no test either,... wait no ,that's a stupid thing to
say,because nobody writes "good code",code isnt good or bad,it either results
in the expected behavior or not.

~~~
otikik
Depends on how you define "expected behavior".

If it means "the machine executes it and is able to produce the expected
outputs with the right inputs", and nothing else, then you are missing a key
concept about code.

You see, code is not written for machines. If that was the only reason, we
would all write direct binary. Code is written for _people_. More
specifically, _other people_. (Or you, in the future).

If no one (except a machine) is capable of understanding a piece of code, then
that code is indeed bad; it has failed its main purpose. The more
_understandable by people_ code is, the better it is.

I agree that once compiled/interpreted, these differences don't matter. Until
the next bug or feature request arrives. Then it matters quite a lot.

------
transfire
You want a good rule: Write More Comments! Comments are documentation and few
programs are ever documented enough.

------
vs2
how about a language that has no support for comments!?

------
VLM
A partial list of problems

Assume someone who can't write clear code can write clear comments. Also
search and replace clear with "readable" "literate" "concise" and last but not
least, "correct"

Assume a programmer has full authority over all 3rd party, supplier and
customer APIs, interdepartmental processes, and all business logic, management
selected fad technologies, such that its logically impossible to be unable to
always factor out weird confusing stuff resulting in clear code / clear
comments. My program is the world and none have dominion over any of the rest
of it and any other conception of reality is wrong. (And edited to add I've
gotten involved in some weird "EE" stuff and like it or not, the world itself
is plain old weird and illogical sometimes and if you don't like that, a
computer programmer can't fix it, only a physicist, or maybe a diety. This
isn't a big problem in the world of CRUD apps but it does happen)

Assume comments only exist as a inspirational descriptional prose tool.
Sometimes I use them as placeholders for something I know belongs there but
either I or the business are not ready. Sometimes I use them as a cheatsheet
because I'm personally really uncomfortable. Sometimes I use them as an
outline more like names on a map to orient myself than a travelogue.

Assume all programmers fit the management ideal of identical replacable cogs.
"How could someone work here without knowing by heart how to convert dBmW into
volts or the difference between S21 and S12 microwave scattering parameters,
so I have no need to comment this, but I've never actually used this corner of
matrix math while employed before so I'll make one of those laughable comments
that is a simple linear translation just to help me keep my head on straight.

Assume comments go thru the same code review process as code. If a comment in
file A tangentially relates to function Q in file B, and you modify function
Q, your code review process will probably examine file B and the comments in
it, but how do you ensure file A gets modified? This is especially bad with
those "because" style comments. (edited to add, at least date your comments?)

Assume no metrics exist WRT comments to be gamed. Your continued employment
and possible promotion exist because of a content free meaningless metric
number, perhaps lines of comments. Ask a professional to generate a number,
you'll get a nice number, but unprofessional work. Ask a professional to do
professional work, and you get professional results and who cares what the
number is. That requires a high caliber of management, usually unavailable.
Even worse a low caliber of management, the kind most likely to demand
adherence to meaningless metrics, is also exactly the type least likely to
successfully evaluate the professionalism of the code so they don't end up
with good code. So you get meaningless metrics resulting in meaningless
comments right next to bad code, if you enforce metrics.

Assume there exists a silver bullet for comments, just like this months silver
bullet fad for code also fixes all problems.

(edited to add) Assume there's one human language. I worked at a place where
outsourcing and H1B took complete control over corporate IT such that code
comments and even some internal documents were no longer written in English.
This makes comments rather hard to follow when engineering tries to cooperate
with IT. So... I'd love to follow your detailed internal process for dynamic
DNS for my spectrum analyzer, but you guys don't use English and we don't use
your India language, so...

------
michaelochurch
I disagree. You don't need to comment simple and _universal_ concepts like
this:

        swap :: (a, b) -> (b, a)
        swap (x, y) = (y, x)

or even this:

        map :: (a -> b) -> [a] -> [b]
        map f [] = []
        map f (x:xs) = (f x):(map f xs)

Those functions actually _are_ self-documenting. Trying to explain them
further is just going to clutter the page.

On the other hand, at 10,000 lines of code, a lot of that being parochial
business logic, I'm going to want high-level documentation of _why_ all this
code exists. My emotional impulse is going to be to throw out all this shit
code (in the business world, all code is shit) so please _tell me_ why that is
a bad idea. (I know it is, and I'm not going to do it, but please tell me
_why_ I'm not going to do it.) I'm going to want an entry point. I can't count
the number of days of life I've lost just looking for entry-points in gigantic
enterprise codeballs. Like, what actually runs?

Actually, 10,000-line single-programs should be rare-- Big Software is almost
always a mistake, see here:
[http://michaelochurch.wordpress.com/2012/04/13/java-shop-
pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/--)
but that's another rant.

------
bozhidar
There's similar advice in the Ruby Style Guide -
[https://github.com/bbatsov/ruby-style-guide#no-
comments](https://github.com/bbatsov/ruby-style-guide#no-comments)

Comments often go out-of-sync with the code, so I think it makes a lot of
sense to prefer writing comprehensible code instead of trying to explain with
comments something totally incomprehensible.

~~~
AlisdairO
It's weird to me how people will slate low quality code, but think it's okay
(or inevitable) to let comments go out of date. If your comments aren't
useful, delete them. If they are, keep them up to date. It's part of behaving
responsibly towards the rest of your team just as much as writing readable
code is.


You will know my name is the LORD when I exterminate all rational lambdacalculus - nsomaru
http://www.jwz.org/blog/2013/12/you-will-know-my-name-is-the-lord-when-i-exterminate-all-rational-lambda-calculus/

======
craftkiller
Similar chuckles can be sought at Erowid Recruiter:
[https://twitter.com/erowidrecruiter](https://twitter.com/erowidrecruiter)


Instant Apps for the Apple Watch with the Wolfram Language - trurl42
http://blog.stephenwolfram.com/2015/04/instant-apps-for-the-apple-watch-with-the-wolfram-language/
======
mavdi
It's such a shame the licensing of Wolfram Mathematica is so strict and
pricing is high. I get it, it's the fruit of a lot of hard work but sadly it
won't get the traction it deserves.

~~~
soofy
The Wolfram Cloud sandbox

[https://www.wolframcloud.com](https://www.wolframcloud.com)

and raspberry-pi

[http://www.wolfram.com/raspberry-pi](http://www.wolfram.com/raspberry-pi)

editions are free. I understand - low power - but still one can at least try
it out.

~~~
mavdi
With a non-commercial license.

------
spdustin
I had no idea the Wolfram Cloud had grown so useful. If you're here reading
comments to see if the article is worth it: It shows how small snippets of
code in the Wolfram Language get packaged as an "app" via a companion app on
iPhone (which seems like a runtime essentially). That iPhone app also has an
Apple Watch component to surface the packaged Wolfram Code app on the watch.
Tons of quick examples of pretty clever things.

------
eggy
I bought the Home edition of Mathematica, and have always enjoyed using it.
You can program in many paradigms, functional, rules-based, imperative, etc...
The hooks to the data and the notebook interface, far before iPython, iJulia,
Beaker and others came along, so it has a head start with integration, and as
another wrote below, a great standard library.

------
mastermojo
Who uses the wolfram language? It seems pretty expressive and powerful... but
I don't really see a strong case for adoption.

~~~
evv
I've only ever seen or heard of it being used by Stephen Wolfram. It must be
fun to have a huge engineering team to help support what is essentially a pet
project.

Maybe they will someday release something with general availability and
competitive pricing, but for now it seems to be behind a walled garden. But I
wouldn't worry. If Wolfram Language truly exposes any novel concepts, then it
is only a matter of time until the open source community implements those
features for everyone else to use.

It's a shame, but I'm skeptical Wolfram will ever see the inherent value of
getting real software into the world. From what I've seen, he would much
rather build proprietary toys that only he can use, rather than building open-
source tools that can be ubiquitous.

If Wolfram has cool toys and isn't willing to share, then so be it. The open
source community can build our own cool toys.

~~~
RootDynasty
The language part of the Wolfram Language is still really kludgy to use and
quite slow. Even doing simple things like writing a function or an if
statement is painful. What it does have going for it is the biggest, baddest
standard library available.

imo, the language would be much more compelling if the syntax was redesigned
from the ground up and made easier to debug (the error messages in Mathematica
are next to useless)

~~~
akater
I'm sorry but your comment will be grossly misleading to people unfamiliar
with the language. There's absolutely nothing painful about If and Function.
However, I must note that in a rule-based language both are used far more
sparingly than they would be in an imperative, or even functional language. I
found myself moving from If to Replace, for example.

------
panic
How does this get around the App Store Review Guidelines?

        2.7: Apps that download code in any way or form will be rejected
        2.8: Apps that install or launch other executable code will be rejected

~~~
jahewson
This is just a guess, but it looks like it could be running in a WebView:

> although the apps were designed for the Apple Watch, you can actually also
> use them on the web, or on a phone

~~~
reustle
I would love to see some of these on the pebble time or android wear as well

~~~
soofy
It is on pebble

[http://community.wolfram.com/groups/-/m/t/406359](http://community.wolfram.com/groups/-/m/t/406359)