How Academia Resembles a Drug Gang (2013) - <AUTHOR> http://blogs.lse.ac.uk/impactofsocialsciences/2013/12/11/how-academia-resembles-a-drug-gang/ <comment><USER2> As some one who managed to succeed in the academic rat race (tenured professor) and who quit to do more productive things, my feeling is academia is more like cult. When inside it you believe you are doing important things, and on occasion you actual do (i.e. teaching and research), but the important activities are basically a hobby you fit around your full-time job of administration and politics. Once outside you realise you were wasting your life on trivia of the most meaningless kind. While I miss some parts I have to say I am glad to be out.

<comment><USER3> My experience was very similar. While I was in the land of postdoc fellowships and part-time teaching, it was a great job where I gladly accepted low pay in return for freedom to work on my own projects and structure my time independently. By the time I was a few years into a tenured post (at a European university), the amount of administrative drudgery, committees, useless meetings and other BS entirely unrelated to my skillset as an academic had grown tremendously - enough to make it quite easy to quit when I saw opportunities in the software industry. When I look back at it now, I still bristle a little at how much worse it got over the years, almost feels like a bait-and-switch. I have several other friends who've since left their tenured positions while still young, all of us with this feeling that we were stuck in a type of work we really hadn't signed up for.

<comment><USER4> Out of curiosity, how old were you when you left ?

<comment><USER3> 34\. other profs i've known who quit academia were in their late 30s/early 40s. (and of course a ton of grad students and undergrads who stopped much earlier, and people who never got jobs and eventually worked outside academia, but that's much more common)

</comment></comment></comment></comment><comment><USER5> Interesting - some important points overlooked:

\- They assume that for everyone doing a PhD there is an equivalently attractive job waiting for them. However, many young people going doing PhDs (especially in the countries highlighted, Portugal, Greece, Slovakia) aren't choosing between a steady job and the uncertainty of PhD - there are often either no jobs available or very unattractive ones (e.g. working well below your skill level, poor working conditions, etc). A PhD offers an interesting hybrid of employment and training while offering more intellectual freedom and stimulation than your average desk job (note to Americans - most PhDs in Europe come with some form salary/scholarship/stipend).

\- They seem to assume that everyone going into academia from the PhD level up is aiming to remain there. Many people do PhDs and then go to industries - certain industries (e.g. biosciences) pretty much require a PhD if you want to get anywhere interesting.

Both these significantly weaken the drug gang analogy, since it rests on the premise that there is a big pool of people joining at the bottom of the pyramid with the principal aim of clawing their way to the top. The motivations for doing a PhD however are far more diverse, from being simply a more interesting (or simply available) option that regular work (flexible hours, intellectual freedom, and a prestigious title at the end of it) to being a requirement to work in a particular industry. Certainly in my experience, only a minority of people starting PhDs do so with the explicit goal of attaining tenured professorship.

<comment><USER6> PhD programs in the sciences (e.g. bio, chem, phys) in the US also come with a salary/stipend that one can live off of.

<comment><USER7> And any professor will tell you that if you have to pay for your PhD yourself, you shouldn't be doing a PhD in the first place.

</comment></comment></comment><comment><USER8> I think this article is reaching a bit. There are some interesting things about this drug dealer model though. Why do the bottom rungs agree to play this game? I think the dynamic manifests in a lot of highly aspirational industries. The money, prestige and such going to the slim top layer can act in lieu of benefits going directly to participants.

Many one-on-one sports are examples. Floyd Mayweather might make close to $500m in career prize winning. The "contenders" who fight him (apart from big names like Manny Pacquiao or Oscar De La Hoya) under him will earn ˜1% of that. Beneath them, "journeymen" (maybe the top 25 in a weight class) fighters often make something like that $3 an hours wage.

I suspect acting is often similar. Music, stand up comedy and arts in general. The possibility of attaining the prestige and earning of Tom Cruise keeps aspiring actors in gyms and auditions, trying to climb the steep ladder.

Apart from all that, there is definitely something in the zeitgeist about universities and academia. I think they are in for a tsunami of change sometime in the next generation. This is just one example. The weird entanglement of research and education. The trading on Prestige. The dynamism of competition under them (non academic education, bootcamps, online learning, etc.).

<comment><USER9> All the arts have brutal power law income distributions, with a handful of winners making $$$$$ while most people don't break even.

People who do well in the arts have a rare combination of charisma, marketing/networking skills, existing social contacts, persistence, location, luck, and talent - which often belongs at the end of the list, unfortunately.

Ironically, academia is one of the few places where you can work in the arts and do better than average. You can get real funding for arts research, especially if there's a technical angle.

Of course you don't usually have an audience - unless you count other academics - but not everyone loses sleep over that. And there's often a special policy niche for academic art. It's a kind of "Look at us as a country - we totally do serious difficult art" cultural brag.

It seems to be important to fill that niche. What it gets filled with isn't so important.

</comment></comment><comment><USER10> >The reason for this is that the prospect of future wealth, rather than current income and working conditions, is the main driver for people to stay in the business: low-level drug sellers forgo current income for (uncertain) future wealth.

That's description of statups.

<comment><USER11> With startups, you can pivot (with academia you can too, but it's rather 3-5 years).

With startups, you can fail (and try again); in academia, if you fail, you fail.

In short: with startups, if something is not working (or you totally lost belief in it), you can quit a project without quitting startups for good. In academia, if you want to stay, you often need to stay in a miserable conditions 1-3 more years (e.g. to finish PhD, postdoc, etc), just not to get kicked out for good.

Moreover, with startups, you can start your group being 20, without anyone's blessing.

<comment><USER12> I have several friends who have successfully navigated switching research groups and even departments in the middle of their PhD work. I also know a few who didn't manage such a graceful transition, but it's definitely possible to pivot during the PhD without giving up on the degree and research career.

<comment><USER11> Perhaps it's possible under some circumstances. But I spent 3 years more than I wished to (as I see it now, I should have quitted, but by that time I thought that academia was the only intellectually stimulating option).

Change universities (Europe) would cost me at least a year, plus scrapping all previous progress. Plus, with getting a poor recommendation letter (more than likely when resigning) I would need to go a tier down.

I envied software engineers, who (if things do not work) could change their place in mater of weeks... and have money to support them for much longer, if there were need.

I know people who change, but it was never a trivial thing. (Maybe except when within a department.)

Now (living as a freelancer) I lover the freedom and flexibility. And, curiously enough, I get more of intellectual inspiration.

</comment></comment></comment></comment><comment><USER13> "There is an expanding mass of rank-and-file "outsiders" ready to forgo income for future wealth, and a small core of "insiders" securing incomes largely at the expense of the mass. We can call it a winner-take-all market."

Interesting. If I didn't know any better, I thought he was describing the situation with many tech startups. The investors have all the money, the founders are the only ones with any hope of making good money, and the rest just serve as cannon fodder in the investors' and founders' games. This actually seems to be a common pattern in quite a few other industries as well, and from the perspective of an established business owner, is the ideal structure of __any __business.

<comment><USER14> The difference is the power law chart of the incomes. Yes, the potential for the really big wins in startups is mostly with the investors and the founders. But most of the "cannon fodder" as you call them are still making what most would consider respectable salaries. There are exceptions certainly but, by contrast, most would-be actors who haven't hit a relatively high level of success are waiting tables or the equivalent.

</comment></comment><comment><USER11> Previous submission: [https://news.ycombinator.com/item?id=6825534](https://news.ycombinator.com/item?id=6825534) (100+ votes, ~2 years ago) with a different address: [https://alexandreafonso.wordpress.com/2013/11/21/how- academi...](https://alexandreafonso.wordpress.com/2013/11/21/how-academia- resembles-a-drug-gang/)

</comment><comment><USER15> So now every organisational structure that has more people at the bottom than at the top resembles a drug gang?

I blame Levitt.

<comment><USER16> Just to let others in on the reference, Levitt is the co-author of Freakonomics, a book that popularized, among other concepts, research showing that the average drug dealer gets terrible payment for the risk they take, and only stays in the business due to unrealistic hope of one day becoming one of the few drug lords that make insane amounts of cash.

</comment></comment><comment><USER17> How Academia does not resemble a drug gang:

1)Drug gangs don't have an excess of lazy administrative support staff.

2)Drug gangs actually have to deliver some drugs at some point.

3)The politics of drug gangs are less vicious and there is better teamwork.

</comment><comment><USER18> I left after being continually relegated to low-academic value technical support work for established academics. Last year I turned down four opportunities to participate in NSF grants, and this year three so far. It is impossible to advance in an academic career on the basis of the technical skills you used to help your colleagues. Academia is winner-take-all. I decided it was pointless to compound my losses by supporting the winners.

</comment><comment><USER19> The article claims a problem is that there aren't enough mid-tier positions, for those who have just acquired a PhD but aren't yet suitable for a professorship.

What sort of solution could one imagine? Outside of post-doctorate positions, there's neither funding nor desire for the kind of research that you need to further an academic career.

<comment> barry-cotter Reduce the number of graduate programme places so the over supply is less, either by reducing the number of places reasonably evenly across the system or by closing marginal doctoral programmes altogether. There are a lot of universities that graduate Ph.D.s who have virtually no chance of a decent academic position. The first tier universities graduate more than 5 times as many Drs. each year than are necessary to replace their own staff, some much more than that. You need to be an extremely strong second tier graduate to have a chance of getting a position at the same level, never mind going up. Third tier or below are basically exploited for teaching and research labour and then gradually eased out of the system. People should not enter these programmes expecting to get an academic job. Those who enter those programmes would be better off getting a J.D., which is damning. A J.D. is a horrible idea for most people but at least it only wastes 3 years and less than $200K. Most people who enter a Ph.D. programme drop out, in most disciplines, and some people who do graduate take up to ten years.

<comment><USER18> This is correct. In retrospect my math Ph.D. was a waste of time. There have been proposals over the years on how to address the overabundance of PhDs. One approach seems to have been widely and independently adopted: advise those responsible for easing out the exploited to read Erving Goffman's _On Cooling the Mark Out: Some aspects of adaptation to Failure_ [1, 2].

1\. [http://www.tau.ac.il/~algazi/mat/Goffman-- Cooling.htm](http://www.tau.ac.il/~algazi/mat/Goffman--Cooling.htm)

2\. [http://kieranhealy.org/blog/archives/2002/10/31/cooling- the-...](http://kieranhealy.org/blog/archives/2002/10/31/cooling-the-mark- out/)

</comment></comment></comment><comment><USER20> To be fair, a similar pattern might be present in other industries as well, e.g. finance, food services, manufacturing, etc. I think the point the author is trying to make though is that academia is _uniquely_ like a drug gang, but I'd don't see anything to justify that. My guess is that you'd find something like this in every large and hierarchically-organized system. That's not to say this is a good way to do things though...

</comment><comment><USER21> I am both an aspiring graduate student (though, maybe not after reading this) and grew up with many friends who were/are still in organized crews, plus did some delivery for a few years myself when I was a foolish 17 yr old.

Most delivery driver jobs here pay $150-200/day depending on how busy the line is, and the people that work them usually aren't looking to move up instead they want cash wages for easy work, since most have records and can't get decent paying jobs anywhere else. The article is correct almost all these guy's still live with their parents. There were only 2 guys I knew that actually thought they could move up and make big money while the rest of us accepted we were only ever going to make $200/day and were essentially contractors, we were never privy to any gang internal business.

Gangs no longer hold drugs when corner selling (where you make the most money, selling by the point at full street value), they pay an addict in drugs to do this while they run security watching over the operation to prevent robberies. Street enforcer is where you start if you want to move up since you are essentially managing operations instead of just a delivery boy. You also hang around the top people as they call on you to come along to jack rival operations. These thugs get a lucrative percentage when they steal drugs off other crews and pass them down to the delivery lines to sell so are making real money, since it seemed every enforcer in my little dope crew was bombing around in a Porsche Cayenne customized to be bullet resistant with hidden compartments installed to hide their handguns, lived in huge houses by themselves and were always decked out in latest heatbag designer clothes. I don't remember any of these guys being broke, and technically they are the lowest rung on the gang hierarchy since the drivers are just contractors.

That was back in 2005 though, and now the vast majority of gangs are not handling any product here. Their income model is intimidation and extortion. It's far easier to wave a gun around on the street and tax everybody in the drug business than it is to put in work building up a line or managing operations. They don't even steal each other's lines anymore, just demand a percentage of the profits. As a result street violence has actually declined, since jackings and hits decreased and most beefs are now solved by passing money over a table. These independent dealers are also way better at selling drugs than gangs, so bring in much more money and the dominant gang that taxes them also offers protection from robbery (we are robbing you to offer our robbery prevention services).

This gangster method is more profitable, has almost no startup costs besides needing vehicles and guns, is much harder to prosecute since they never are directly involved in narcotics trade, and has an endless recruitment pool inside prisons to replenish ranks faster and with tougher recruits. It's also how all those Mexican border cartels operate. They are merely taxing the smuggling routes into the US skimming the shipments of Gulf and Sinaloa cartels. Those cartels have to build manufacturing, supply chain and retail while paying off politicians and police while the thug at the border just needs a gun, and is impossible to get rid of since they hold down their territory hard.

tl;dr Stepping into a gang as the new lowest position pays much more now, and is almost a guaranteed ladder to better positions since narcotics handling has all been outsourced as drug dealers are good at being drug dealers, and gangsters are good at being thugs.

<comment><USER22> Very underrated comment, by far the best in the thread. Sounds like drug gangs are borrowing the business model of governments.

<comment><USER21> I guess they are like a government, in that they can afford to wait out disputes while the drug businesses can't. Every once in a while these other groups will try and get rid of the dominant extortion gang but since they live off skimming, and their business model is a vehicle and a gun, they can afford to go to war while the drug dealers and cartels all will be losing money and cannot sustain a lengthy conflict. The narcotics businesses have extensive bribery networks they need to keep operating to survive and any interference in the income will threaten to unravel it all. Some of them have minimum wholesale they need to buy every month in order to keep up supply, and customers will also start calling competitor lines if deliveries are stopped.

Even worse, when the heat on the streets is so hot during a war from all the shootings and police are everywhere, not much business can happen so the extortion crews turn to contract hits for income. For $10-15k you can pay them to kill off one of your rival drug dealers, potential informants or even people in your own delivery crew so you can move up and take their place. So while they are fighting off a rival takeover they are also open for local business dropping bodies all over the streets and blaming it on the invading gang, which police then turn their attention to, and are getting paid while the rivals/cartels are bleeding money. Eventually they have no choice but to give up the dispute to save their own business from extinction, much like how businesses have to settle in court when defending against government lawsuits and can't afford too much delay.

What is really surreal about the black market is after these violent outbursts everything is simply settled by a payment of back taxes owed and you just go back to work like nothing happened. One of the enforcers who managed us was shot at repeatedly by somebody he knew living in the same immediate neighborhood during one of these wars and next week it was all cleared up above us by whoever was in charge and beefs squashed. He'd still see the guy on a regular basis, no hard feelings, only business.

</comment></comment></comment><comment><USER23> Multi-level marketing schemes are similar, in that they exploit people leveraging those people's desire to improve their situation (or dream to get paid while doing nothing).

The film industry is similar, you work for low wages, hoping you will make it to the big time.

So is athletics, work for free at college, hope you make it to the NFL or wherever.

This pattern may be more common than most realize.

</comment><comment><USER24> One thing that should also be emphasized is that there is a great number of PhD candidates that never actually finish, in some universities that number is more than half. Many of these, before quitting, teach to help pay tuition and do all sorts of tasks for their department/supervisor that are not related or help them finish their PhD.

</comment><comment><USER25> "The reason for this is that the prospect of future wealth, rather than current income and working conditions, is the main driver for people to stay in the business: low-level drug sellers forgo current income for (uncertain) future wealth. "

May be true but also could be that the person who decides to sell drugs for less than they could make at McDonalds couldn't even land a job at McDonalds or any other traditional employment. Similar to how many people go into business for themselves because they are not cut out to work for anybody else. It's not all about money and future prospects.

</comment><comment><USER26> Isn't medicine like this to a degree? The interns and resident make very little per hour, work long hours and have little control over anything.

Sounds like apprenticeship as well.

Why do people put up with it? Because its very difficult to leave and start a competing enterprise. There's either a contract that locks you in or licensing that locks you out.

Or you need government funding to compete with those who have government funding, so you must suck up to the powers that be, who are all in bed together.

<comment><USER14> Not at all. Interns and residents have a reasonably high probability [1] of becoming fairly well-compensated licensed physicians if they choose to follow their program through to the end. This isn't an argument about long and even grueling apprenticeships with modest compensation. It's about how even those who make it through such an apprenticeship in some professions will mostly not find a job at the end--which isn't the case with doctors.

BTW, I'm not sure I believe the drug dealer/actor/pro athlete thought really applies to academia--even if it's true that PhD degrees in many fields probably don't have a great ROI and aren't likely to result in a tenured position.

[1] I don't know the numbers but I have no reason to think a lot of people, especially from better programs, are forced out during internship or residency.

</comment></comment><comment><USER27> every company resembles a drug gang

</comment><comment><USER28> Please update the title, article is from 2013.

<comment> barry-cotter Nothing of note for the analysis has changed.

<comment><USER29> Is that an official reason?

</comment></comment></comment><comment><USER30> If someone comes up with a better system, it will be adopted. It is very hard to determine who has the capacity to be a Professor. The current system works fine most of the time. It is true that crackpots get through on occasion, but the vast majority of professorial appointments are reasonable.

<comment><USER31> "If someone comes up with a better system, it will be adopted."

Academia moves very, very slowly. Stuff remains unchanged for _centuries_ , just because that's the way it's always been done.

For instance, the lecture model was adopted when books were hand-written and very expensive -- basically the lecturer (in some institutions, actually called "reader") would read the text very slowly and distinctly, while the students would copy it down verbatim. At the end of the term the students would have their own copy of the text.

We've had printing presses for quite some time now, but the lecture lives on.

Law and religion are similar. Note that those institutions also still retain many medieval trappings, both intellectual and physical (robes, funny hats, etc.)

<comment><USER32> Thanks for enlightenment. I used to wonder about the title "Reader" in commonwealth countries. Now your elucidation makes sense.</comment></comment></comment>


A long view of globalisation in short: The agricultural revolution (2018) - <AUTHOR> https://voxeu.org/content/long-view-globalisation-short-agricultural-revolution-part-3-5 <comment><USER2> There isn't a good option in the UI to view the next or previous entries in this five-part series, so here are the rest if anyone is interested:

[Part 1]: [https://voxeu.org/content/long-view-globalisation-short- part...](https://voxeu.org/content/long-view-globalisation-short-part-1-5)

[Part 2]: [https://voxeu.org/content/long-view-globalisation-short- huma...](https://voxeu.org/content/long-view-globalisation-short-humanisation- globe-part-2-5)

[Part 4]: [https://voxeu.org/content/long-view-globalisation-short- grea...](https://voxeu.org/content/long-view-globalisation-short-great- divergence-part-4-5)

[Part 5]: [https://voxeu.org/content/long-view-globalisation-short- new-...](https://voxeu.org/content/long-view-globalisation-short-new- globalisation-part-5-5)

</comment><comment><USER3> Reading through the article there were a few things that irritated me: referring to the Indus valley civilization as India/Pakistan, the city of Kolkata didn't exist until the 17th century and Kochi on the Western coast of India gained in prominence only after the earthquake of 1341. The map shows both those places in the year AD 1.

<comment><USER4> That does seem a bit weird - especially as Mesopotamia is also included in that list rather than the modern countries in that area.

<comment><USER3> He does mention the Fertile Crescent and the modern-day countries but seems to suggest that agriculture then moved to Mesopotamia. Not true.

</comment></comment></comment><comment><USER5> It would have been nice to see a bit more inclusion of what was happening in the Americas during this same period, since they were already fairly populated. He also mentions the impact of Bubonic plague, but neglects to mention the early initial impact of smallpox in the Americas - some estimates are that it killed roughly 10% of all human life on the planet in less than 100 years.

>"Our new data-driven best estimate is a death toll of 56 million by the beginning of the 1600s — 90 percent of the pre-Columbian Indigenous population and around 10 percent of the global population at the time. This makes the "Great Dying" the largest human mortality event in proportion to the global population, putting it second in absolute terms only to World War II, in which 80 million people died — 3% of the world's population at the time."

[https://www.pri.org/stories/2019-01-31/european- colonization...](https://www.pri.org/stories/2019-01-31/european-colonization- americas-killed-10-percent-world-population-and-caused)

Given that the "discovery" of the "New World" was a pivotal feature of the period alluded to in the article, the fact that it had just been massively depopulated and was then taken over by new settlers seems hugely relevant to a "long view on globalization".

In addition, there is good evidence that agriculture was independently invented in the Americas, in addition to its advent in the fertile crescent and early china.

<comment><USER6> I don't know if the incredible agricultural diversity coming out of the Valley of Mexico has an equal[1].

1\. [https://en.m.wikipedia.org/wiki/Domesticated_plants_of_Mesoa...](https://en.m.wikipedia.org/wiki/Domesticated_plants_of_Mesoamerica)

<comment><USER7> Raw calories matter a lot more for development, though.

</comment></comment></comment><comment><USER8> "Climate scientists don't know why, but, starting 20 millennia ago, the earth's climate began to warm."

Maybe it's just something the Earth does.

<comment><USER9> While true, I would recommend reading this comic, showing the different rates of warming.

[https://xkcd.com/1732/](https://xkcd.com/1732/)

<comment><USER10> that was a long post but amazing

</comment></comment></comment><comment><USER11> Don't forget about amber road that moved amber to other side of the world. They didn't go back with empty hands.</comment>


Rails Rumble Winners - Gem Teardown - <AUTHOR> http://www.dwellable.com/blog/Rails-Rumble-Winners-Gem-Teardown

<comment><USER3> Very interesting information. Definitely going to have a look at a few gems after this. Thanks for sharing.

On a side note, HAML is the best example of technology for technologies sake. It adds a small amount of value while adding the complexity of a new language. I've never felt the "juice was worth the squeeze" so to speak. Curious as to why it has the following that it does.

<comment><USER4> Never making invalid markup is handy, and if you have easy access to attributes you can:

      .a_class{ attrs } some text

which can save a lot when you would otherwise have to write:

 some text

The never-invalid markup is probably the bigger win, though. Primitive type checking for your HTML is arguably better than none. What I would _really_ like is something similarly terse but faster - HAML can get pretty slow.

<comment><USER3> I cannot say I have had many problems with incorrect HTML. Since using HAML, I have had tabbing issues, inline javascript issues, a new syntax to learn (and translate). The last one is my main issue. 80% of your time spent with HTML is in the browser, the mental translation is more of a tax than anything.

I have used HAML on three projects and it always feels like it gets in the way more than it helps.

<comment><USER4> On a couple big projects, I've generally liked it - since there's less boilerplate ("<>" and closing tags in particular) and the primary identifying bits (- or %ul or .class) are at the far left of each line, I can generally read things more quickly and more easily than e.g. straight HTML or ERB's <%= %>.

But that comes from rather extended use, I'm definitely not claiming it's the best. There are plenty of things I dislike about HAML, but it does mean I read _less_ , and I spend quite a bit of time reading and writing view code.

Mind if I ask if you've done PHP programming? If you have, ERB's <% would seem to be a tax you've already paid.

<comment><USER3> I am from a dotnet background originally, only created one php app back in my school days. For me, it is less about liking ERB and more about preferring the medium I am working in (HTML). If I could pick anything, it would be razor. It is similar to ERB in that you use HTML, but the painful percent brackets are replaced by a single @. Code blocks are as follows:

@{

      // code

}

another example:

@user.Name

It feels very natural to write and is simple to read/pickup. Now that microsoft has open sourced it, someone should make a version in ruby. Might be a good side project for me actually :)

</comment></comment></comment></comment></comment><comment><USER5> Nice breakdown. Just a critique, I'm willing to bet that people were using therubyracer to compile CoffeeScript.

<comment><USER6> Actually, the twitter-bootstrap-rails[1] gem requires therubyracer[2] in order to compile LESS -> CSS.

[1] <https://github.com/seyhunak/twitter-bootstrap-rails>

[2] <https://github.com/cowboyd/therubyracer>

<comment><USER7> It depends on how you integrate bootstrap: there's a SCSS conversion of Bootstrap that avoids the dependency on therubyracer, (it just requires sass): <https://github.com/anjlab/bootstrap-rails>

</comment></comment></comment><comment><AUTHOR> I put this together yesterday, with help from the ten winning teams. It's kind of like the occasional HN post that looks at hosting decisions made by YC companies. Maybe I'm just a gems geek, but I find this sort of thing fascinating.

<comment><USER8> I would also throw out that the Rumble provided a server setup script that automatically used Capistrano and MySQL, so it would hurt your time a little had you not used what they provided. That may have skewed the deploy/database usage results a bit. The only reason I used MySQL was that I essentially got it for free through the setup script.

</comment></comment><comment><USER9> Seeing it listed in this way reminds me of all the moving parts in actually getting an app online.

I'm glad I finally (mostly) have a grip on it all but boy did it take a while.

</comment><comment><USER10> I'm an organiser of Rumble. If the writers are reading this, I am sure we could try and work out more if they ever want to play with more metrics. :)

<comment><AUTHOR> Author here. Sounds like fun, drop me an email (in my profile).

</comment></comment><comment><USER11> Nine out of the ten winning teams wrote their JavaScript in CoffeeScript? Wow, that's pretty incredible -- I would never have expected it.

<comment><USER12> The CoffeeScript gem is included by default in new rails installs, and some js.coffee files are created, so you'd have to explicitly remove it - <USER2> people won't bother even if they are writing most of their js without it. The following gems are included by default, which perhaps makes the usage in these apps (done in a hurry) not very surprising:

      gem 'sass-rails'
      gem 'coffee-rails'
      gem 'jquery-rails'

</comment></comment><comment><USER13> Rats. I was rooting for Uptilt:

<http://uptilt.r12.railsrumble.com/>

<comment><USER14> You and me both! But there were some fantastic entries this year.

</comment></comment><comment><USER15> Why is beanstalk often looked over? Has anyone ha problems with it before? Or is it just marketing problems..

<comment><USER16> I used Beanstalkd for a few years and I can testify that it's an awesome piece of software.

That said, that was before Resque and Sidekiq existed. I now use Sidekiq for my new project since I'd rather not reinvent the wheel. I suspect most people think the same way.

<comment><USER17> It is an awesome piece of software. If you like it, I would love for you to check out <https://github.com/nesquena/backburner> which is a resque inspired project powered by beanstalkd. There is a great sinatra admin tool as well <https://github.com/denniskuczynski/beanstalkd_view>

</comment></comment></comment><comment><USER18> This is great. I am putting my own list of gems from all the participants, I will list it once done.

</comment><comment><USER19> jquery and bootstrap are great for putting together a rails app really quick, but I wish there was a better way that didn't add bloat. I find that jquery and bootstrap add significant download latency to a webpage even if they are gzipped.

</comment><comment><USER20> Isn't Devise older than OmniAuth?</comment>


Turmeric - eBay's SOA Platform, now open source - <AUTHOR> http://ebayopensource.org/

<comment><USER2> Neat, seems like the site is getting slammed, and what I really wanted to know was a summary of what it's about, here is for the benefit of others:

"Turmeric is a comprehensive, policy-driven SOA platform that you can use to develop, deploy, secure, run and monitor SOA services and consumers. It is a Java based platform, and follows the standards (WSDL, SOAP, XML, JSON, XACML, etc.). Eclipse plugins help with the development of services and consumers. Other important features include:

Various Quality of Service (QoS) features such as authentication, authorization, and rate limiting, which you control by defining respective policies. Monitoring capabilities. A Repository Service that enables service registration and governance. The Type Library, which provides the ability to define and manage reusable schema type definitions across services, and hierarchically organizes them. The Error Library, another useful capability that lets you define and re-use error definitions across services. Local binding, which lets you locally bind services to consumers as a deployment time option, for optimization, without loss of any generality or changing code. The Turmeric platform is highly extensible and customizable. For example, you can easily plug in additional protocol processors, data formats, handlers and various other capabilities. The platform is also highly optimized for large-scale environments. eBay uses this platform internally. Most parts of it are now open source, replacing functionality dependent on commercial products with equivalent, open-source implementations. It also has new package names to match the open-source spirit. This is the first version of the open- source release of Turmeric, and might have some rough edges, so please provide feedback and contribute as you see fit."

<comment><USER3> Looks like a very extensive platform, great to see another major company open- sourcing their product. For me, the key question now is what level of support will be offered (by Ebay and/or the general developer community). Once this project achieves a bit of momentum from other companies' implementations I can see it presenting a very viable option for larger-scale deployments.

</comment></comment><comment><USER4> For anyone like me who didn't recognise the term:

<http://en.wikipedia.org/wiki/Service-oriented_architecture>

</comment><comment><USER5> Please remember that SOA is an approach to development and to architecture. Having a "SOA platform" is nice but, without the service oriented thinking, it gets you exactly 0% of the way towards having an actual service oriented architecture.

</comment><comment><USER6> Can someone explain this to me? Assume I'm clueless.

<comment><USER7> Service Oriented Architecture in short allows companies to compose new web services or re-use existing web services. eg: A check-driving-history module in an auto-insurance company software can be externalized as a web service.

Various SOA platforms provide tooling via eclipse plugins or standalone IDEs and run time environments (as application servers) to compose web services in different programming languages like BPEL, Java etc.

You can manage versions of your web services using the platform (eg: webservice_v1.1 talks to A and webservice_v1.2 talks to B).

You can add access control to your web services.

You can monitor your web services, start and stop them using the monitoring tools provided.

I've worked on a team that built a SOA platform. I am not sure if any existing platform delivers half the things it promises. It sure helps management feel that they are agile and can compose services quickly to changing business needs.

</comment></comment><comment><USER8> Reading the pages makes me die a little inside with each line. My favourite has got to be:

'[Tumeric] follows the standards (WSDL, SOAP, XML, JSON, XACML, etc.)'.

What a delightfully vacuous phrase.

I would hope that no-one sane will ever have to use this outside eBay. Seems an odd choice to be open sourced, probably someone very proud of the years they wasted architecture astronauting to support a bunch of stillborn standards.

Sorry to be so vitriolic, but this project seems to mention every poorly conceived enterprise programming idea I have ever had the displeasure of coming across.

<comment><USER9> You don't have to be sorry. I work at eBay and use their web service framework. I understand what you mean.</comment></comment>


How Mobile Is Your Industry? - <AUTHOR> http://blog.getlua.com/2013/05/30/how-mobile-is-your-industry/

<comment><USER2> For those who confused this site with something related to the Lua programming language:

        Lua is a digital communication and collaboration platform for mobile
        workspaces. We help teams work better, together.

I really wish people would stop overloading the same names with wildly different meanings. Seeing Go (programming language) results when I'm looking for Go (board game) resources is bad enough. Now I have to deal with the same phenomenon with Lua as well?

EDIT: Reading the infographic, this is pretty blatant blogspam. I've flagged the link.</comment>


Twitter Verification - <AUTHOR> https://xkcd.com/1914/ <comment><USER2> That Julian Assange isn't verified yet is an absolute joke.

Whatever else you think about him, he is still a person of significant influence in the world, and there are dozens of fake accounts pretending to be his that regularly fool news outlets.

This is the very use case that the verification system was designed for, and yet still no verification.

<comment><USER3> Twitter doesn't verify people - people reach out, then get verified. It's likely he just never tried?

<comment><USER2> Nope, he's tried (and has been trying for a while [0]), and he regularly calls Twitter out for it and the trouble it causes him due to news outlets getting confused by impersonators.

0: [https://twitter.com/JulianAssange/status/841636931666612225](https://twitter.com/JulianAssange/status/841636931666612225)

</comment></comment></comment><comment><USER4> Ive noticed _a lot_ of random business people seem to be verified. It's become a meaningless (or negative) signal for me. Basically it says: I know someone at Twitter!

</comment><comment><USER5> Eh, I understand why it made sense to denote official accounts of well-known people and organizations in Twitter's early days, and also why it doesn't make sense anymore.

The culture of the platform and the world it exists in have changed, why shouldn't policy change to reflect that?

<comment><USER2> > and also why it doesn't make sense anymore.

Why doesn't it make sense anymore?

<comment><USER5> People understand the platform better, no need to lure famous people to the site, there are other ways to verify (e.g., link to twitter account on web page), many more people across the spectrum of "famous" so it's hard to button down who/what is famous enough for the checkmark, global audience means famous in one place != famous in another, no consistency in how verified actually works, verified accounts became Star-Bellied Sneetches, etc.

<comment><USER2> The verified system isn't about luring people to the site, it's about making sure certain accounts can't be impersonated.

The problem is that Twitter doesn't verify consistently, but it's is still an important feature, e.g. Imagine the mischief that could be caused if there was no way to tell which of several accounts was the real Donald Trump.

<comment><USER5> Except that you would know which account was the real Donald Trump, because Donald Trump would be on TV telling you so.

Extremely well-known figures have other ways to let you know which account is theirs. The harder set of people are the sort of low-to-medium famous. Or locally famous, not globally famous. The verified system has never worked well for that group anyway.

<comment><USER2> And yet every other week there's another news outlet publishing tweets from "Julian Assange" that aren't actually from Julian Assange (here's one from last week [0]), because twitter refuses to verify him and the people copying his account do it very well.

Now imagine that at the presidential level. No thanks.

0: [https://twitter.com/JulianAssange/status/927671065379262465](https://twitter.com/JulianAssange/status/927671065379262465)

</comment></comment></comment></comment></comment></comment><comment><USER6> The historical problem with the Twitter verified system is they used it as the database of accounts you may want to follow when you joined. Those are really two different things.</comment>


Toward an AI Physicist for Unsupervised Learning - <AUTHOR> https://arxiv.org/abs/1810.10525 <comment><USER2> The computer program BACON (1987) of Nobel Prize winner Herbert Simon was given the distances of planets from the sun together with their period of revolution and it independently rediscovered Kepler's third law, illustrating how far the positivism at work in "AI" can go. But Kepler's achievement was not determining a - straightforward - relation between two rows of numbers: it was to figure out which numbers should be related, and Kepler's real achievement was actually finding the right question. Incidentally, Kepler stated a fourth law relating planets to perfect polyhedra, and one wonders why this fourth law has not been rediscovered by computer yet...

\-- Jean-Yves Girard: Locus Solum

<comment><USER3> Bacon was the dissertation project of Pat Langley under Herbert Simon. It was one of several dissertations exploring rational reconstruction of previous discoveries. [https://www.ijcai.org/Proceedings/81-1/Papers/025.pdf](https://www.ijcai.org/Proceedings/81-1/Papers/025.pdf)

</comment></comment><comment><USER4> So I'm still trying to grok this, but this could be a very important result if it could be generalized to the problem of meta-learning and model selection.

In that setting, the model selection oracle could access a shared knowledge pool of learned theorems that are biases about what kinds of models are better. e.g. convolutional nets are better than fully connected nets for vision tasks.

This could break us out of the diminishing returns we have seen with deep learning, by allowing us to better explore the space of compact model architectures, and develop shared biases about what is better. For example, learning the programmatic generation of Inception-like networks.

Bonus points if you want to add a blockchain connection, to decentralize the accumulation of the shared theorem base: Proof of work is figuring out what biases are true over some benchmark, which can be stored to a distributed ledger. Competing annotations lead malicious and noisy results to be penalized.

</comment><comment><USER5> I got introduced to Max Tegmark's work last year. Got his book - Life 3.0 and Our Mathematical Universe</comment>


CSS Grid Garden – a game to learn CSS grid by watering plants - <AUTHOR> https://cssgridgarden.com <comment><USER2> See also discussion from 4 months ago: [https://news.ycombinator.com/item?id=18753358](https://news.ycombinator.com/item?id=18753358) (128 comments)

And from 2 years ago: [https://news.ycombinator.com/item?id=14041367](https://news.ycombinator.com/item?id=14041367) (131 comments)

</comment><comment><USER3> Just as fair warning, the last one of these to come around on HN, Flex Zombies, collected email addresses and either promptly sold them or was compromised. The nature of the email indicates being sold. I have proof of marketing mail being sent to firstname.lastname@example.com.

<comment><USER4> Grid garden doesn't require a sign up.

The creator of flex zombies does have a grid game but it's paid. That said I think they just released a service workers game so I guess good to know.

</comment></comment><comment><USER5> > grid-template-columns: 20% 20% 20% 20% 20%;

Shouldn't this be repeat(5, 1fr);

I thought we were done with percentages and the fractional unit was the new way.

<comment><USER6> guess you didn't finish the tutorial before you commented ;-)

fr is introduced later.

<comment><USER5> I went through to about 28.

The problem is that you should never educate people with the wrong stuff first. It is harder to unlearn than it is to learn. Plus people like me come along with some knowledge of the subject and get put off by the wrongfulness of the starting point.

</comment></comment></comment><comment><USER7> Apropos of CSS grid learning games, had anyone here used Grid Critters[1] and want to share their experience? It looks pretty slick, but the price tag makes me hesitate.

[1] [http://www.gridcritters.com](http://www.gridcritters.com)

</comment><comment><USER8> Is there anything like this for more advanced css?

All tutorials seem to be for complete beginners or advanced hacks / tricks. I can't find anything for an intermediate level.

<comment><USER9> There is [https://cssbattle.dev](https://cssbattle.dev) it's not a tutorial, but seems to be a nice way to play with css. (I've only done the first puzzle, so can't say too much about it)</comment></comment>


Did a broken random number generator in Cuba help expose a Russian spy network? - <AUTHOR> https://www.mattblaze.org/blog/neinnines/ <comment><USER2> TLDR; maybe

A very interesting read !</comment>


Rowhammer-like attack on SSDs can provide root privileges to attacker - <AUTHOR> http://www.myce.com/news/ibm-researchers-rowhammer-like-attack-ssds-can-provide-root-privileges-attacker-82386/ <comment><USER2> The full paper is here: [https://www.usenix.org/system/files/conference/woot17/woot17...](https://www.usenix.org/system/files/conference/woot17/woot17-paper- kurmus.pdf)

I am unconvinced. They have not demonstrated an attack on any real-world SSD; instead they have attacked their own FPGA-based design.

The attack assumes that you can control or predict the physical location of data on an SSD, which is unlikely on a system that is doing other I/O.

But worst of all, the "attack" assumes that if you can target the right physical block/pages in flash, you can somehow hit that location with sufficient read-disturb that the result will decode successfully, AND pass ECC checks, meaning the resulting bad data will be returned to the host system.

I am highly skeptical that this could ever work on a real SSD. The combination of BCH/LDPC error-correction codes combined with a final checksum should make "random bit flipping" impossible to leverage.

Oh, and there's one more thing: SSD firmware keeps counters, to ensure that read disturb can't corrupt data. Any read pattern that hammers a particular location will trigger garbage collection or data rewrite to a fresh location.

<comment><USER3> Author here, I would like to set the record straight.

We do not claim to have an attack on SSDs. The journalist seems to have misunderstood and not read the paper. The attack demonstrated is not on an FPGA or SSD.

The main point this paper makes and demonstrates is that if you can cause corruption of a full block (i.e., completely garble contents of a chosen block), then you can elevate privileges (with some assumptions, like using ext3). Note that this result does not depend on whether you are using an SSD, a disk, or any other storage for your filesystem.

<comment><USER2> Are you claiming that a random-bit-flipping attack such as targeted read disturb can cause corrupted data to be returned even through data scrambling, a first-level LDPC check and a final CRC check on the output?

From your paper: "We assume that the victim system runs a filesystem on top of MLC NAND flash-based SSD."

It seems very naive to be surprised that people would assume this is an attack on SSDs.

<comment><USER4> The flash weakness is clearly documented as just being part of their threat model, not part of their research. They say that their contribution is in the filesystem part of the attack, to build on a weakness proposed by a previous flash layer focued paper. So this is completely OK.

If you want to critique the flash paper, or how this paper represents that papers findings, you should turn your attention to:

Yu Cai, Augata Ghose, Yixin Luo, Ken Mai, Onur Mutlu, and Erich Haratsch. "Vulnerabilities in MLC NAND Flash Memory Programming: Experimental Analysis, Exploits, and Mitigation Techniques". In: 23rd IEEE International Sympo- sium on High Performance Computer Architecture . 2017.

I found a PDF link too: [https://pdfs.semanticscholar.org/b9bc/a3c9f531002854af48de12...](https://pdfs.semanticscholar.org/b9bc/a3c9f531002854af48de121cdcc8e0520c7f.pdf)

<comment><USER2> I agree the earlier paper shares the same misconceptions.

I don't agree that the authors of the present paper are exempt from criticism for this reason.

</comment></comment></comment></comment></comment><comment><USER5> This is idiocy. Modern drives AES encrypt data to provide whitening. You do not have the key nor do you set it or care for it. Without it you'll not be able to pull this off. Their attack will only work on very old SSDs that do not whiten data. All modern MLC/TLC chips REQUIRE whitening and AES is often used since it whitens well and is fast.

<comment><USER6> This would be a much more productive comment if you took out the first sentence.

<comment><USER7> I think the meme of "never say anything harsh lest you make someone sad" is counterproductive. It's very important to productive discourse that people are able to express the entire range of _intensity_ with which they may feel an opinion. In particular, if something is stupid you should be able to say so.

<comment><USER6> You can be as harsh as you need without being a dick. Just address the content and what's wrong with it, not how stupid you think the author is. On the very rare occasion that it's useful to talk about someone's intelligence, you should say more than "you're an idiot".

<comment><USER8> Maybe you're not aware that in English there is a difference between saying "You're an idiot." and "This is idiocy."

<comment><USER6> I don't want to get into an argument about definitions or semantics. Those phrases are different, but they come across similarly to me and many others, at least in this context. That's really all that matters in a casual discussion like this.

I understand not everyone will have the same reaction. I don't pretend to speak for everyone, but I suspect I speak for the majority.

</comment></comment></comment></comment></comment></comment><comment><USER9> Mods, please change URL to original source: [https://www.usenix.org/conference/woot17/workshop- program/pr...](https://www.usenix.org/conference/woot17/workshop- program/presentation/kurmus)

<comment><USER10> This really needs to be done. The journalist's article has nothing to do with the paper (I do not think the journalist read the paper)

<comment><USER11> They may have read but they clearly did not understand. Looks like they realized it now:

> Update: Our reporting was incorrect, here is a comment from the author of > the report: "Author here, I would like to set the record straight.We do not > claim to have an attack on SSDs. The journalist seems to have misunderstood > and not read the paper. The attack demonstrated is not on an FPGA or SSD. > The main point this paper makes and demonstrates is that if you can cause > corruption of a full block (i.e., completely garble contents of a chosen > block), then you can elevate privileges (with some assumptions, like using > ext3). Note that this result does not depend on whether you are using an > SSD, a disk, or any other storage for your filesystem."

</comment></comment></comment><comment> X-Istence Google cache as it seems to be offline for me: [http://webcache.googleusercontent.com/search?q=cache:LREtpAA...](http://webcache.googleusercontent.com/search?q=cache:LREtpAAixkMJ:www.myce.com/news/ibm- researchers-rowhammer-like-attack-ssds-can-provide-root-privileges- attacker-82386/+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER12> If such an attack were able to reliably set data in a flash device, could this be defeated by whole disk encryption and block checksums? Whole disk encryption would be to counter the ability to set precise values (checksums would be no use if you could just set a correct one in your attack) and then checksums to detect, well, data corruption?

</comment><comment><USER13> I couldn't get access to the video. How do they work around the error correction and wear leveling algorithms?

<comment><USER14> They don't. I was at the presentation. It assumes that the target FS is ext3 and one has bypassed the mitigations you mention and any others that get in the way. Mention is made of previous generation SSD tech that was vulnerable to charge leakage during IO to adjacent cells.

<comment><USER15> Assuming a spherical SSD...</comment></comment></comment>


ШП - <AUTHOR> http://store.steampowered.com/app/727640/_/ <comment><USER2> This feels like some of the ancient applications our team still have to maintain and I work for a Fortune 500 company.

Sigh.

<comment><USER3> I do feel like I've played plenty of the hard mode where after figuring what the UI currently does, you have to debug the VB6 source, find the right edge case, and make it even edgier based on some semi-sensical business decree.

"How hard would it be to add another checkbox here, when this radio button is both shown but not selected, but only on the third Wednesday of Fall months when the Accounting Winds howl, that when checked pops up this other spreadsheet we need?"</comment></comment>


Claude Lévi-Strauss: Science, myths and the mystical - <AUTHOR> https://www.the-tls.co.uk/articles/public/claude-levi-strauss-science-myths-mystical/ <comment><USER2> Is there a version of this article that does not require javascript in order to read it?</comment>


Redux – Not Dead Yet (2018) - <AUTHOR> https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ <comment><USER2> One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the _exact things that caused a screen to render_. And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched (<with this data>) -> FrozenUser. One can rewind the actions and iterate with the stakeholders _why_ that screen appeared. This is huge and I miss this a lot.

1\. Note that most of the time the stakeholder is yourself and/or another developer. But can also definitely be a non-coder.

<comment><USER3> Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

<comment><USER4> _In the vast majority of React apps you do not need this._

I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's _a lot_ of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps don't need to trace actions, but when you do you definitely won't think it's overrated.

<comment><USER5> Can you give me an example how you got to 400 actions? Just enumerate like 5 or so, I'm assuming you are building features where groups of actions are just necessary based on the patterns you are using.

I'm genuinely curious because I feel like this kind of inflation of actions/reducers in Redux is what makes it nightmarish.

<comment><USER6> For one thing they do encourage a lot of tiny actions. A frequent pattern I use requires three actions for every server call: one to trigger a saga, one when it succeeds, and one for when it fails.

The standard form is incredibly verbose, I've started to shift away from it.

<comment><USER7> Note that the new `createAsyncThunk` API in Redux Toolkit handles generating and dispatching the promise lifecycle actions for you [0]. Also, while sagas are a great power tool, most Redux apps don't need them [1].

[0] [https://redux-toolkit.js.org/api/createAsyncThunk](https://redux- toolkit.js.org/api/createAsyncThunk)

[1] [https://blog.isquaredsoftware.com/2020/02/blogged-answers- wh...](https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux- toolkit-uses-thunks-for-async-logic/)

<comment><USER8> Awesome! It's great to finally have some links to share.

The company I'm currently working with is the first time I've used sagas / observables / "anything async is through side effects". I've constantly been saying "this is madness, this giant block of code, all these concepts, all this room for things to go wrong, just to do a `fetch`?". It's also the first time in a few years of using redux I've had to deal with race conditions.

Edit: Oh, and you can even `await dispatch`! All the things I've been doing in Redux for years and told I shouldn't, now being officially endorsed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Oh hey, that's my post.

I first wrote it back in 2018, and just updated it yesterday with some additional links and comparisons.

(Actually was considering retitling it after getting some feedback last night, but given that the link just got submitted here, I'll leave it as-is for now.)

A few quick notes:

\- If you haven't looked at Redux in a while, please try out our official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, and the React-Redux hooks API [1]. We're going to be teaching both of those as the default approach for using Redux going forward.

\- We have a new "Style Guide" docs page that gives our official guidance on suggested usage patterns [2]

\- On that note, I'm working on an ongoing major rewrite of the Redux core docs [3]. My current task is creating a new "Quick Start" tutorial, which will be a "top-down" intro to using Redux to stand alongside the existing "bottom- up" tutorial sequence. The goal of the Quick Start section is to quickly introduce Redux concepts, and show RTK and hooks as the "right way to write Redux code", without going into the details of how it works under the hood, so that folks can get started now and learn the underlying aspects later. I've an early partial WIP draft PR up [4], and hope to finish the first draft in the next few days. Once the Quick Start page is done, I'll be turning my attention to rewriting the main tutorial sequence in order to remove outdated terms, clarify explanations, and teach simpler patterns (like using "ducks" files instead of splitting code across multiple files).

If anyone's got questions on anything I wrote in the article or otherwise Redux-related, ask away!

[0] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[1] [https://react-redux.js.org/api/hooks](https://react- redux.js.org/api/hooks)

[2] [https://redux.js.org/style-guide/style-guide](https://redux.js.org/style- guide/style-guide)

[3] [https://github.com/reduxjs/redux/issues/3592](https://github.com/reduxjs/redux/issues/3592)

[4] [https://github.com/reduxjs/redux/pull/3740](https://github.com/reduxjs/redux/pull/3740)

<comment><USER9> Do you, or anyone else in the team or community, have a good resource you would recommend to people complaining about "too much boilerplate" in redux code? It is likely the most common complaint I see, that I understand to come from a place of people not understanding it this a tool best used for _scaling_ and/or already _big_ projects. Whenever I have worked with Redux in a large project, that "boilerplate" is minimal and the benefits obvious.

<comment><USER10> I think that complaint usually comes from people who try to put _everything related to state_ in Redux, and not just the parts of it that need to be.

Also the 'reducks' pattern of splitting the Redux state into separate files, each containing a reducer and the related actions and selectors helps keep things simple to understand (although I guess it is a bit more overhead, actually).

<comment><USER5> I've read articles about how the Ducks pattern in practice also become untenable.

</comment></comment></comment></comment><comment><USER11> I found I was just using Redux as a data caching layer and ended up using SWR hooks instead [https://swr.now.sh/](https://swr.now.sh/). This has resulted in way less boilerplate (which increases even more with a type system) and a better development and user experience for the product I was working on. For everything else I use context like managing modals, auth, errors, and firebase connections.

</comment><comment><USER12> I love Redux but I am very frugal about what I put into the store and have come up with a strong set of design patterns with my team to know what should and should not go there. That, in conjunction with hooks for any other stateful concerns we have, makes for a sane and pleasant dev experience.

IMO the biggest and best draw of Redux is how it allows you to completely separate your business logic from your UI layers. Your components only know about props and state and are rather trivial to test. Hooks are great for re- usable logic as well but my team made the choice to have hooks deal only with localized state concerns and have a robust Actions => Services => Reducer layer for everything that speaks to things outside that constraint. Its worked out wonderfully so far. Tests are a breeze and logic is highly portable. Our UI layer is thin and easy to change.

Its not all roses of course. The Redux store can turn into a rats nest of keys and values with no obvious structure (or worse, duplicated structures). It's something that requires actually sitting down and modelling out your data structures. Sadly that's something I don't see very often (and I am just as guilty as anyone else). The Redux team came up with some good guidelines on this point (too lazy to track the link down but its on the main site) and I think they have some really good ideas. I think more than anything its important to consider your store in the same manner you would a database and approach it with that kind of mindset. As with all things JS, its easy to dive in, hard to untangle yourself! :)

<comment><USER13> > I think more than anything its important to consider your store in the same > manner you would a database

Yes and to keep it normalized. IMO, Redux is incomplete without some sort of selector layer, which acts as the metaphorical database views.

[https://github.com/reduxjs/reselect](https://github.com/reduxjs/reselect)

<comment><USER7> We've recommended normalizing data as a pattern for years [0], but never had any official tooling to support that use case. Redux Toolkit 1.3 now has a new `createEntityAdapter` API that can help with the process of inserting and updating normalized data [1].

[0] [https://redux.js.org/recipes/structuring- reducers/normalizin...](https://redux.js.org/recipes/structuring- reducers/normalizing-state-shape)

[1] [https://redux-toolkit.js.org/api/createEntityAdapter](https://redux- toolkit.js.org/api/createEntityAdapter)

</comment></comment></comment><comment><USER14> So many great things about redux that are hard to mimic...

\- the ability to create a middleware that is your analytics listeners. Analytics will listen to actions and spit out analytic info when those actions trigger. Because of this there is literally no analytics code anywhere in your codebase, except encapsulated in that one analytics middleware and sub-tree.

\- Ability to just see every state update in dev tools which is AMAZING for tracking down what caused a non-obvious problem. For example: Was it a bad api request? Was it a bug in the reducer? etc. Hard problems suddenly become easier with good debugging tools.

\- Ability to persist a part of the store to local storage. This is actually quite nice.

<comment><USER15> One thing I like is that it's really easy to put a client library (for, say, some REST service) behind a combine-reducerable Redux store and a few exposed "action creators" (event emitters). Especially if you're using TypeScript so all that stuff's easy to find and understand. Anyone familiar with Redux will be able to use it immediately, and it'll work just fine anywhere JavaScript does (provided whatever other packages the client lib depends on will work on a given platform) including places you might want, for good reasons, to use JavaScript but lean on some UI system other than React (Apple TV, say, or maybe Electron).

</comment></comment><comment><USER5> I don't like the structure Redux forces my apps into. This might be a good opportunity to see what simple solutions people are using to avoid stuff like Redux. I remember reading about this:

[https://hookstate.js.org/](https://hookstate.js.org/)

<comment><USER16> I am inclined to agree. At first I thought Redux was awesome, but eventually discovered that there is a lot of boilerplate and just a general overhead to doing certain things.

However, I definitely fall into the cluster of people that were "just told to use Redux". For my next React project I will certainly evaluate other approaches.

</comment></comment><comment><USER17> I taught a course on Javascript in undergrad with a unit on react as well as redux (cis.upenn.edu/~cis197, check it out!). To this day, I still think people learning JS should know about redux because of the design pattern it encourages (note that when people are first learning CS, this is probably the first-ish time they're coming across the concept of a reducer and "functional" state that isn't mutated directly).

I think it's even more important for people self-learning react to be exposed to redux in some way; yeah, there's boilerplate, but it's just beautiful when all put together and isn't a Blackbox (I love dan's tutorial on egghead explaining redux from the ground up precisely because it breaks down exactly what's working and why it is).

This blog post does an excellent job of convincing newcomers in the JS world to consider learning redux. I'm definitely forwarding this to the current instructor of the course!

</comment><comment><USER18> I've recently tried using Redux for a side-project. While it solves the problem (organizing state), I feel there is too much boilerplate for my small project.

Are there any popular alternatives which don't use reducers?

EDIT: thanks for all the responses, I'll check them out :)

<comment><USER19> You can use a React Context and have simple global state in your React app. If you like reducers, throw in a useReducer hook and you have a large part of what people use Redux for.

<comment><USER20> I've done that recently, and I had many performance issues. I have a long-ish list of very simple components that are in a sorted order. So when I change the value of one, I re-sort the list. I was hoping React would only rerender the changed items (remove old, insert new). But no, it rerenders the whole list, which takes 500ms. I made sure object references in the list stay the same, that didn't help.

I can implement this thing in vanilla JS, and it would not take more than a few milliseconds. React is cool, but so damn hard to optimize.

<comment><USER7> It's important to distinguish between React "rendering" (asking components what they want the UI to look like), and actually applying updates to the DOM.

React's default behavior is that when a component renders, React will recursively re-render _all_ of its descendants. it then diffs the VDOM render output to see if you've asked for any changes to the UI since the last time it updated. If the two VDOM trees are the same, React says "nope, nothing to do here!", and ends the render pass. _If_ you requested changes, it then gathers them up and applies them all to the DOM in one step.

You can optimize the rendering behavior in some ways if needed. The `React.memo()`, `PureComponent`, and `shouldComponentUpdate` APIs [0] allow you to tell React to skip re-rendering if you know that a component's props haven't meaningfully changed, and thus would result in the same UI output as the last time. This does require that the child components be separate component types (ie, `<MyComponent />`), not just the parent rendering a bunch of plain elements (like `<div>`).

For lists in particular, React needs to know how to identify which items are which. React doesn't care about object references, but you can pass a special prop called a `key` when rendering items in a list. That way, if you move a list item up, swap a couple others, delete one, and add a couple more, React knows what existing list items ended up where, and can update the DOM efficiently in response. Otherwise, changes to lists without good use of keys can result in more DOM work being done than actually necessary.

[0] [https://reactjs.org/docs/react- api.html#reactmemo](https://reactjs.org/docs/react-api.html#reactmemo)

[1] [https://reactjs.org/docs/lists-and- keys.html](https://reactjs.org/docs/lists-and-keys.html)

</comment></comment></comment></comment><comment><USER21> I agree ... I recently went back to using Redux in a project and I'm loving it. Redux at its heart is just a state manager, but because people tie it to React I've gotten people tell me all sorts things about how you don't need it anymore with all its new features.

I think the addition of React's hooks and context api actually make Redux easier to use, and I like the purity of its role as a state manager. I personally find that its cleaner to keep the overall application state in redux than to hold onto it inside of React, and leave react to manage its own component's state regarding ui level interactions.

</comment><comment><USER22> I don't like how this article moves the goal posts of whether redux fits our use case or not. It has some valid arguments (dev tools) but the overhead of the boilerplate and tooling around redux is just not worth it IMO.

Much better to break your app state into various custom hooks that leverage Context API and the `useReducer` hook.

<comment><USER7> Not sure what you mean by "moving the goalposts" here.

I'm trying to make a few specific points:

\- Redux is not "dead" in the sense that it is still widely used and is continuing to be adopted

\- There are definitely many other tools in the React ecosystem that overlap with how you'd use Redux, but the Venn diagrams for the use cases don't entirely match up, and the other solutions don't necessarily have all the capabilities of Redux

\- Redux _has_ been over-used and put in apps where it didn't fit well, and I want people to only use it when it makes sense to do so

\- Our Redux Toolkit library and React-Redux hooks API make it a lot easier to use Redux

<comment><USER5> A lot of the pushback is coming from this:

' - Redux _has_ been over-used and put in apps where it didn't fit well, and I want people to only use it when it makes sense to do so'. '

There are developers working day in and day out in these Redux codebases so our feedback is coming from a real place. There's a million articles that pushed Redux to the top and got it used in just about everything. Articles just like this one.

This article is literally pushing back against all the reasons why Redux might not be a good fit. There's very little in it that goes 'yeah you know what, for this scenario, don't use Redux'.

<comment><USER7> That's because:

\- I have no control over the millions of other tutorials that have been written. I can only control my own blog, and the actual Redux docs.

\- The question of "When does it make sense to use Redux?" has been answered numerous times already [0] [1] [2]

\- I wasn't trying to address the "when?" question in this article. I was trying to answer "is Redux still a viable choice, and how does it compare to other alternatives?"

I've written plenty of 6-10K word blog posts about Redux before that delve into how and when to use it. That wasn't my goal for this post.

[0] [https://medium.com/@dan_abramov/you-might-not-need-redux- be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

[1] [https://redux.js.org/faq/general#when-should-i-use- redux](https://redux.js.org/faq/general#when-should-i-use-redux)

[2] [https://blog.isquaredsoftware.com/2017/05/idiomatic-redux- ta...](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux- part-1/)

<comment><USER23> There is an odd dynamic that happens in tech: A framework or approach exists for a specific purpose; that framework is used badly or inappropriately by devs who don't fully understand it; those same devs spread the idea that said framework is bad/difficult/insecure and people who use it just don't know what they're doing; some of those devs happen to be "thought leaders" and use their platform to broadcast their misunderstanding as gospel

CSS, SASS, redux, array.reduce, webpack are examples that come immediately to mind from the javascript world. There have been so many throughout the years

<comment><USER5> So it's difficult to parse what your observation is providing insight into.

So let's see how this blame game works, because I have a hunch you want to aim it at people that think Redux is a bad choice.

You are suggesting that people that really don't like Redux actually don't know how to use it properly, misuse it, go down that rabbit hole and come out completely jaded by it. They then go on to provide their feedback, to which the obvious dismissive response is 'well maybe you don't know what your're doing'. So the bad mouthing is actually occurring from the other side, no?

For the last few years, any job post you saw related to React, Redux was a prerequisite for probably over 90% of those posts. In other words, Redux was gospel, not the the feedback of naysayers. The mass broadcasting was happening by the framework adopters to the point said framework became ubiquitous.

Lastly, there's very little feedback about Redux that has to do with people's understanding of it. Almost the entirety of feedback is coming from usage of Redux and noticing by-products of using it (bloated code base, needless complexity - and this needless complexity criticism is ripe for being sniped by the framework advocates as a symptom of essentially incompetent developers who can't see the elegance of Redux. The feedback is that it's not elegant ).

The thought leaders are not the people providing negative feedback in this thread and elsewhere. The thought leaders, the gospel creators in this case are these Redux based articles/advocates that prolifically spread Redux throughout the React ecosystem to the point it became a standard dependency for every app.

In this case, this is a very real situation where it needs serious push back because it spread untethered and unexamined.

One thing I also want to point out, the same way the developer community has a responsibility to evaluate the proper usage of a technology, those who partake in pushing certain technology also have a responsibility of analyzing the impact of what they are evangelizing. One could argue it is irresponsible for influential subsets of the Javascript ecosystem to push a layer of complexity for apps that do not need to make the trade offs for a few features.

<comment><USER23> @runawaybottle, with sincere respect, you projected a lot of meaning into what I wrote: "You are suggesting that people that really don't like Redux actually don't know how to use it properly, misuse it, go down that rabbit hole and come out completely jaded by it."

Nope. Neither implied nor intended.

The article is a reasonable reaction by a redux maintainer to the dynamic I describe. "I don't like using Redux" is a totally valid opinion. "Redux is terrible" is, frankly, not a valid opinion. Neither is it valid for CSS, javascript, React, Vue, Pascal, COBOL nor what-have-you, and yet here we are yet again, letting fickle winds of fashion and facile opinion dictate what should be engineering decisions.

Use redux if your use case applies. Don't use redux if it doesn't. If you find it unwieldy, dont use it. I wish the tech community could leave it there, but they don't.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Redux is great, and I'm glad to see all this cleared up, to some extent. Especially the bit about the new context API somehow eliminating the need for Redux. I know some people don't like redux and that's fine - don't use it. But it's still super-useful to many, many people.

<comment><USER5> We all don't get to waltz into a new job and say 'Hey remove all this verbose Redux code and app structure, it's slowing down velocity. Plus this crud app is too simple to add this annoying layer of boilerplate'.

</comment></comment><comment><USER25> Redux always had to much boilerplate for me to prefer it.

The last couple years I have been using the new Context API and spliting my app state out by creating a global context, and many domain specific contexts where the context contains both the data and functions used to work with that data. Typescript + state with data and functions created a great api per domain. I found this approach just as clean but with less boilerplate.

Though redux does have some performance and tooling benefits.

<comment><USER26> I disagree... I use useSelector, and now all my actions.js files export a default useActions method with a wrapper I wrote...

Yeah, the boilerplate setting up the middleware and initial reducer isn't fun... but it's been really rewarding and the react-redux hook has been a godsend.

[https://www.npmjs.com/package/react-redux-actions- hook](https://www.npmjs.com/package/react-redux-actions-hook)

<comment><USER7> Note that with Redux Toolkit, that store setup is now a single line:

        const store = configureStore({reducer: rootReducer})

[https://redux-toolkit.js.org/usage/usage- guide#simplifying-s...](https://redux-toolkit.js.org/usage/usage- guide#simplifying-store-setup-with-configurestore)

<comment><USER26> Cool, but I tend to use sessionStorage as a backup to the store to re-hydrate on reload... I also use the thunks plugin so that I can have actioncreators that do multiple dispatches.

<comment><USER7> Right, and `configureStore` automatically adds the thunk middleware by default [0], as well as the Redux DevTools extension.

You'd still have to pass in options for whatever persistence addon you want to use, but that would be something like:

        const store = configureStore({
            reducer: rootReducer,
            middleware: [...getDefaultMiddleware(), myPersistenceMiddleware]
        })

Which is still shorter and easier to read than having to mess with `applyMiddleware` and `compose` yourself.

[0] [https://redux- toolkit.js.org/api/getDefaultMiddleware#includ...](https://redux- toolkit.js.org/api/getDefaultMiddleware#included-default-middleware)

</comment></comment></comment></comment></comment><comment><USER27> The most overrated tool I've ever had to misfortune of having to wrangle. Talk about bloat and lasagna code.

I've used mobx and it's better. Now I use apollo, and it's even better.

Just thinking about having to use redux and sagas and all that bloat makes my stress levels rise. I can't believe it became as big as it did.

"muh time travel" is a meme of epic proportions.

<comment><USER28> Amazing how many downvotes all the redux critical posts get. Redux is indeed horrible and leads to all sorts of bloat and bugs.

<comment><USER27> Sunk cost, these people have spent hundreds of hours learning something that ultimately is going to be discarded even more. That's why people are downvoting.

<comment><USER29> No, I downvoted because all the comments amount to X bad Y good. What they are posting has nothing to do with the article. The article even specifically talks about most of the Ys that are getting commented about and address what use-cases they are for that Redux isn't for. It's clear those people are not here to talk about the thing they are commenting on, they are just here to tell everyone they don't like Redux.

<comment><USER28> I have yet to be given a good usecase for Redux. All I see is code that ends up causing issues:

\- redux pollution (not cleaning up state and things leaking)

\- because you can't access redux state directly, components have to copy redux state and store them as props (which makes 0 sense, its state not props). But now you run into the issue where the local prop is not in sync with redux since redux updates are correctly done in chunks.

<comment><USER7> What do you mean by "can't access Redux state directly" and "copy Redux state"? Neither of those sounds correct.

Components have always been able to extract whatever data they want from the store using the `connect` API, and now our new `useSelector` hook. Those APIs return whatever values _you_ want for use in the component, and that generally is the actual object references to the real data that's in the store.

Both `connect` and `useSelector` subscribe to the store and re-run the logic you've provided whenever the store is updated, and force a re-render of your component with that fresh data. If I have:

        const user = useSelector( state => state.users.entities[props.userId])

Any update to that specific `user` object in the store will cause this component to re-render. Same goes for `connect` and `mapState`.

So yeah, your statement confuses me, because it doesn't seem to describe how React-Redux actually works.

<comment><USER28> Most redux users use mapStateToProps and rely on it to notify you when a redux change has happened.

<comment><USER7> Right, and I'm saying that both `mapState` and `useSelector` perform the same behavior: allowing your component to subscribe to portions of the Redux store state, extract that, and update the component when that data changes.

So, I don't understand what points your parent comment is trying to make, because the whole point of React-Redux _is_ to keep your components in sync with the data in the Redux store state.

<comment><USER28> We have run into several issues where a user clicks a button (which updates redux) and then quickly clicks on something else and the 2nd component has not been updated yet as it used the mapState prop (the update is being batched by redux and hasn't gone out yet to the listeners).

Switched to using a shared model class instance - the value is changed immediately and anyone who needs to know the latest version can do it easily. Much simpler, faster and easier to debug since there is truly only one source of truth, not copies everywhere.

<comment><USER7> That sounds very surprising. Yes, React-Redux does batching and cascades updates through the UI layer, but that process should happen extremely quickly (far faster than the amount of time needed for someone to click on another button).

I'm also not sure why you keep using the phrase "copies". The Redux store has the only actual copy of that data, and your `mapState/useSelector` functions typically return the actual references to that same data. The only copies made are if you make them yourself. Also, the value in the store _is_ already updated before any of the UI subscribers are notified.

Can you put together a sandbox that reproduces this problem and file an issue? I'm very curious what you're actually seeing.

<comment><USER28> Pretty easy - component that stores a redux computed value and a setTimeout that calls an action with the value. If the settimeout (or a websocket event, etc) fires before the batched update, you are out of sync.

Most people have simple applications so redux works fine, but once you get complicated async work things just break down.

<comment><USER7> tbh that doesn't sound like a Redux-specific problem. That sounds like a general async / stale-references problem. If you've captured a value and try to use it later, then yeah, you're probably going not going to be using the latest version.

<comment><USER28> Which is a design flaw of redux. Proper systems allow you to access the current state value at all times, without having to worry about batching.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> I find the hook API cleaner for most common use cases. It is also better for things like forms, which redux wasn't intended for.

[https://redux.js.org/faq/organizing-state#should-i-put- form-...](https://redux.js.org/faq/organizing-state#should-i-put-form-state- or-other-ui-state-in-my-store)

</comment><comment><USER31> I can't justify redux usage apart from legacy support. Mobx (preferred) or hooks for some apps/components.

</comment><comment><USER32> I like redux but what could be achieved with an a tag and another HTML page now needs 700 lines of code due too react, redux, webpack, router, server rendering, partial loading................................................. Yeah I don't want to make my life harder for no reason

</comment><comment><USER33> I've used redux many times and the amount of boilerplate code is large. What Redux does is cool, but it complicates the app and is a pain to update. I feel this is going to go the way of Java Enterprise Beans as React continues to mature.

</comment><comment><USER34> That quote "if you're explaining, you're losing" applies here.

<comment><USER7> Trying to clarify FUD on the internet is certainly a fool's errand, but at least I've got a writeup to link to when I see people ask these questions.

</comment></comment><comment><USER35> [https://cerebraljs.com/](https://cerebraljs.com/)

</comment><comment><USER36> Worth noting this is from 2018...

<comment><USER7> As I noted at the start of the post, I updated it literally yesterday with some additional information and links and then tweeted about it, which is why someone else apparently decided to submit it today.

</comment></comment><comment> tren-hard > Is Redux dead, dying, deprecated, or about to be replaced? No.

Reading through the comments it sounds like it's struggling, even positing the question sews doubt. I thought redux was still one of the 'must have' tools for building react apps now.

What has everyone been migrating to? Is there a consensus successor to Redux?

<comment><USER37> It depends on your use case, but he mentions some alternative solutions in the article.

1) React's Context API

It's straightforward to use, and it solves the issue of passing data to deeply nested components, but that's all it does.

2) GraphQL Apollo Client

I used this on a recent project for managing client-side state, and to me, it felt like I had to do a lot of work to achieve what should be basic functionality. It was my first foray with Apollo Client, so take my opinion with a grain of salt, but I found myself wishing I was using Redux instead for the duration of the project. Also, Apollo Client has some bugs related to cache invalidation (look on Github). These may be solved now, but they bit me pretty hard.

3) The new React "Hooks" API

Looks nice. Have not used it.

</comment></comment><comment><USER38> previous comments, when this may have actually been news: [https://news.ycombinator.com/item?id=16918003](https://news.ycombinator.com/item?id=16918003)

why post it again?

<comment><USER7> I updated the post yesterday with new links and information, and tweeted a mention of having done that. Apparently someone thought it was worth submitting.

(tbh I'd forgotten it actually hit the front of HN when I wrote it the first time!)

</comment></comment><comment><USER39> i propose updating the title to include something about this being (revised 04-2020) or [updated]

i've been wondering the state of things as im jumping back into react projects after a couple years off.

</comment><comment><USER40> Four letters: V, U, E, X.

<comment><USER41> Or MobX which is also neat.

</comment></comment><comment><USER42> I really think it should die, from a DDD perspective EDA should be handled as backend tasks with CQRS. If your api server isn't handling that then you really should stand up a BFF. I get that Redux is designed to handle all of that on the front end but it just doesn't belong there. I have seen too many projects devolve into garbage because they are trying to shoehorn too much crap into reducer patterns when it just doesn't belong there.

<comment><USER43> How do you update the front-end state after the backend task is complete other than reload the whole page?

<comment><USER42> websockets or any stream service such as kafka</comment></comment></comment>


Instead of elections, let's use lotteries - <AUTHOR> http://aeon.co/magazine/society/forget-elections-lets-pick-reps-by-lottery/ <comment><USER2> The article seems to miss the main reason why elections are a terrible way to designate representatives: you are voting for people who _want_ to be in charge, who will do whatever it takes to be in charge, and remain in power.

Elections != democracy. Elections force us to elect our masters. We elect the people who are supposed to write the rules they have to follow. I mean... come on. A 4th grader would see the paradox in that.

The Republic in Athens was based on the lottery and it lasted literally for centuries.

<comment><USER3> I'm certainly no expert on ancient Athenian history, but this:

 _The Republic in Athens was based on the lottery and it lasted literally for centuries._

Does not appear to be correct. It does appear that a lottery was part of the Assembly/Ekklesia process[0]. Specifically, the Assembly elected the Boule by lottery[1]. The original Boule (established by the statesman Salon[2]) was established in 594 BC. However, the lottery for these positions was not introduced until 508 BC, and initially only allowed for the top 3 "property classes" and only to those over 30. It wasn't until the mid-5th century that all 4 property classes were allowed to attend. Additionally, they were chosen by lot, but only from those who chose (or were able) to attend. This left the poorer citizens out of luck until pay was instituted for these positions[4]. Also, unlike a true lottery, it was still left to "people who _want_ to be in charge" since the lottery was only for those who attended. Then in 322 A.D, Macedony put the kabosh on democracy in Athens. So the lottery was only in place for about 180 years, didn't enitirely replace the existing Areopagus and made up a part of the Ekklesia, and was limited to 400.

I don't really see that as a good basis for the conslusion of "The Republic in Athens was based on the lottery and it lasted literally for centuries.". It was certainly a nice research exercise as I know little about ancient Greek forms of democracy.

[0] - [http://en.wikipedia.org/wiki/Athenian_democracy](http://en.wikipedia.org/wiki/Athenian_democracy) "The officials of the democracy were in part elected by the Assembly and in large part chosen by lottery."

[1] - [http://en.wikipedia.org/wiki/Ecclesia_(ancient_Athens)](http://en.wikipedia.org/wiki/Ecclesia_\(ancient_Athens\)) "The ecclesia elected by lot annually the Boule or council."

[2] - [http://en.wikipedia.org/wiki/Athenian_democracy](http://en.wikipedia.org/wiki/Athenian_democracy) "In 594 BC Solon is said to have created a boule of 400 to guide the work of the assembly."

[3] - [http://en.wikipedia.org/wiki/Boule_(ancient_Greece)#The_Athe...](http://en.wikipedia.org/wiki/Boule_\(ancient_Greece\)#The_Athenian_Boule) "Under the reforms of Cleisthenes enacted in 508/507 BC, the boule ... were chosen by lot at the deme level,"

[4] - [http://en.wikipedia.org/wiki/Boule_(ancient_Greece)#The_Athe...](http://en.wikipedia.org/wiki/Boule_\(ancient_Greece\)#The_Athenian_Boule) " At some point in the late 5th century, pay was instituted for those serving in the boule; this may have been a way to encourage poorer citizens to volunteer, who would otherwise be reluctant to serve."

<comment><USER2> " initially only allowed for the top 3 "property classes" and only to those over 30" so? The pool of candidates was restricted. Isn't it the same to vote? Should we let 10 years old be elected?

"only from those who chose (or were able) to attend." makes perfect sense to restrict the candidates to those interested in politics and the governance of the city.

" the lottery was only for those who attended." Again, those involved in the governance of the city. But was there any way for them to give priority to their name? No, no campaign, no 'communication specialist', no POTUS twitter account.

"So the lottery was only in place for about 180 years" So 2 centuries, what I said.

The thing is the lottery was only one aspect of the athenian republic, how laws were voted, how leaders were held highly accountable were also important corner stones.

<comment><USER3> _The thing is the lottery was only one aspect of the athenian republic, how laws were voted, how leaders were held highly accountable were also important corner stones._

There appears to be a lot to like about the Athenian democratic process (again, not an expert). However, your argument about elections vs lotteries literally had only one thing to say about the Athenians which was "The Republic in Athens was based on the lottery and it lasted literally for centuries.". I find this a weak argument specifically because it's not really true (for the reasons stated above). After all, Athens the Republic (as a democratic process after the reforms of Salon, as compared to just Athens the city) was already 86 years old by the time the first lottery was in place. This reduces the power of the first part of the statement ("was based on the lottery"). How could it be based on the lottery if the lottery did not exist at the time the Republic was formed. Then, the lottery only lasted for 186 years (close to, but not quite "centuries"), but that too loses it's effectiveness as an argument because the US (based on elections) is about 227 years old (counting from the first Presidential election).

So in the end, the argument (as presented, and specifically with regards to Athens), was something to the effect of "Elections are worse than the lottery. The Republic of Athens was based on a lottery. The Athenian lottery lasted for centuries. This should strengthen the initial point that lotteries are better than elections.".

However, in analysis, the statement about Athens is not good evidence for that argument because the Athenian Republic was not based on a lottery, and while it did last for nearly 2 centuries, it still lasted for a shorter amount of time than the system the US is currently using.

</comment></comment></comment></comment><comment><USER4> How about let voters make their choices through an election, but then the winner is chosen through lottery with a weighting towards how the voters voted? So if 40% voted for A and 60% voted for B, A would still win the lottery election 40% of the time.

This could help marginal candidates, since voters wouldn't feel like they're throwing away their votes... any vote COULD win the election.

</comment><comment><USER5> > Elections are flawed and can't be redeemed

Elections _in the US_ may be flawed, but there is quite a bit of evidence that other electoral systems -- particularly, ones where the main legislative body isn't elected by FPTP in single-member districts -- work much better at providing meaningful democratic accountability, which is where the article sees the failure of elections.

So, while I accept the conclusions that _US elections_ are flawed, I don't accept the more general claim, or the claim that even US elections can't be redeemed.

Sortition is interesting, and may be useful, and is certainly something that it makes sense to try on a smaller scale. But better election systems are both a less radical change and one more supported as effective in the modern world and conditions by evidence which provides a clear idea of how to structure them.

</comment><comment><USER6> Check out: [http://www.le-message.org/?lang=en](http://www.le- message.org/?lang=en)

<comment><USER2> I really like M. Chouard's work. I wish he was more present on TV to detail hid theories. Unfortunately people in power can't allow that, they don't want to see their best tricks exposed.</comment></comment>