Show HN: Vested Yeti – Social bookmarking app for busy people - <AUTHOR> http://www.vestedyeti.com <comment><AUTHOR> In September, I left my job in San Francisco and moved to Sacramento to work on a social bookmarking app called Vested Yeti. A user described it as "Pinterest without the Uggs".

Website: www.vestedyeti.com

Users can create flows which store web pages that they want to organize and share. In a nutshell, it's bookmarking that's more visual and shareable. Here's an example flow that I made out of the current top posts on HN:

[https://app.vestedyeti.com/flows/a32ca8e5-9114-4d40-88ba-28e...](https://app.vestedyeti.com/flows/a32ca8e5-9114-4d40-88ba-28e1a20d4180)

I'd really appreciate any feedback or questions.

Note: Posted last week, but flagged because of too many booster comments. Lesson learned :)

</comment><comment><USER2> Doesn't work with 3-rd party tracking (ravenjs.com, userreport.com) blocked.

And what about tags?

<comment><AUTHOR> Thanks for checking it out. Yes, there are certain tools that will block the Chrome extension from working.

Not sure I understand your question about tags - what would you want tagged / what would you want to be able to tag?</comment></comment>


Show HN: STARY – The World's Lightest Electric Vehicle - <AUTHOR> http://www.stary.io/

<comment><AUTHOR> Kickstarter here: [https://www.kickstarter.com/projects/staryboards/stary- world...](https://www.kickstarter.com/projects/staryboards/stary-worlds-best- electric-skateboard-get-yours-fo)

</comment><comment><USER2> I'm a little bit confused as to why the campaign prominently says "No Motor" when it obviously has a motor.</comment>


Self-driving bus involved in crash less than two hours after Las Vegas launch - <AUTHOR> https://www.theguardian.com/technology/2017/nov/09/self-driving-bus-crashes-two-hours-after-las-vegas-launch-truck-autonomous-vehicle <comment><USER2> A human bus driver would have used the horn and the incident most likely would have been avoided.</comment>


Modern Software Over-Engineering Mistakes - <AUTHOR> https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.txrola3hf <comment><USER4> He missed at least one: functions should be "small" and broken up for "testability."

No, functions should perform one task and perform it well. Not every conditional test inside the function needs to be its own function and have its own unit test. Sometimes a function that does just one thing and one thing well has more than one step to do that thing, and those steps don't necessarily belong in their own functions. Testability and composability are important, but that has to be balanced against locality of reference and context. When I see a colleague write in a code review that pieces of a function should be factored out of a larger function "just in case they'll be reused" I step on it hard. This is related to "over generalization" but not exactly the same.

<comment><USER5> Yes, yes! Having to locate and dig through 10+ different smaller functions that are called within another function is much harder to troubleshoot and work with. Especially when 95% of those are not re-used anywhere else.

I know it may not be the popular belief but I would much rather work with a larger well written 50 line function that does what it is supposed to do vs having to navigate around a bunch of smaller 5 line functions that are never re-used anywhere else.

<comment><USER6> If it's done right, though, you shouldn't have to navigate around all the smaller 5 line functions, at least not unless you're debugging. Each of the submethods should clearly describe what it does, and do that without any unexpected side-effects or implicit state changes. Effectively, what this does is raise the level of abstraction of the code, so that your 50-line function becomes a 10-line function, and you only need to read those 10 lines to understand what's going on. Sometimes when you're debugging, you might need to dip into these subfunctions, but when you do, you should be able to think through them as mostly independent units that just need to do what their name says they will do. This ideally limits the problem of having to load everything that your code is doing into your head all at once in order to reason through it. When you're just reading through the code normally, you should be able to gloss over the details of how the submethods work, just as you probably wouldn't feel compelled to dig into the internals of how a library call like Collections.sort works.

The problem is that method decomposition is not always done well, and when there is unexpected behavior or implicit state changes, it can make bad code even harder to navigate. I'd also rather read a well-written 50 line function than a poorly decomposed cluster of 10-line functions. With proper care, though, method decomposition is super helpful.

<comment><USER7> Part of the problem is that the abstraction of "a sorted list" will never change. But the abstraction of "twiddle my foobar" can change on a weekly basis based upon business needs. Because of this the abstractions we write will never be as strong or enduring as those found in the standard library.

<comment><USER6> Certainly true, but that's not a reason to give up on creating those abstractions, like the post I was replying to was suggesting. It's a reason to be judicious about when it's appropriate to create these abstractions, and in particular about when they should be shared. An abstraction that's used in just one or two places is still really easy to change. A bad abstraction used in a dozen places is a pain the ass to clean up. It's not an easy problem, and it ultimately takes some combination of experience and careful mentoring to learn to identify good and bad abstractions before they're built.

</comment></comment></comment></comment></comment><comment><USER8> Back in the days when I worked on a largish "classic" ASP site (each page is a file full of mixed HTML/VBScript) the senior developer insisted that the best approach for developing anything new was to copy a page that did something similar and then change it to fit the requirements.

There was no code re-use.

Sounds insane by today's practices but in reality it worked well more often than not. Business functional changes almost always applied to just one or a small number of pages. You could change those pages with impunity and be pretty confident that you would not break anything in any of the hundreds of other pages in the site.

Rarely this approach caused more work when a change did affect dozens of pages. But on balance it made most changes much easier to implement and test.

<comment><USER9> Yep, that is one of the reasons PHP and ASP got such a bad name. Projects like those take a few greps and minutes to get into and get you to productively make changes without much risk. And, outside HN, it is still quite common because of it.

<comment><AUTHOR> > without much risk.

The trick is to strike the right balance between repeating code and testing it. I've seen codebases become unmaintainable piles of almost repeating code that was never tested beyond a developer opening the page and checking the behavior manually.

To prevent such messes is one key responsibility of a developer.

</comment></comment></comment><comment><USER10> Those who forget history are doomed to be dogmatic software developers.

A lot of stuff we take for granted are either accidents of history, or powerful counter-reactions to the accidents of history.

There is a practice, and it turns out to be bad. Mild discussion of the virtues and vices would, in a world composed of Asimovian robots, be sufficient to update the practice to something better.

But that's not how humans work! Typically an existing practice is only overturned by the loudest, most persuasive, most energetic voices. And they _have_ to be. Humans don't come to the middle by being shown the middle. They come to the middle after being shown the _other fringe_.

So a generation changes its mind and moves closer to the new practice. Eventually, that is all the following generation has ever heard of. The original writing transforms its role from mind-shifting advocacy to the undecided to being Holy Writ. The historical context, and with it the chance to understand the middle way that had to be obscured to find the middle way, is lost.

My previous role was as an engineer teaching other engineers an XP-flavoured style of engineering. I often referred to our practices as "dogma", because we _are_ dogmatic. But if we aren't, less learning takes place. Dogma is most instructional when someone later finds its limits.

When I was learning to coach weightlifters, I was told something that has always stuck with me: "As a coach, you will tell trainees a series of increasingly accurate lies". You can't start with nuance. In the beginning, it won't work.

<comment><USER11> You can start with nuance and openly acknowledge the lie. This doesn't inhibit learning. Every modern textbook on Newtonian physics tells students that it is effectively a "lie", in that it's only an approximation that works reasonably well in most real world cases. But you have to start there before learning general relativity and quantum physics.

<comment><USER10> It depends. Each case is different, the safest place is the dogma.

<comment><USER12> You may have more experience than me, but at this point in my life, I find myself disagreeing with this. In fact, one of the biggest problems I had with education is teaching dogmas. On the other hand, when I did teaching, tutoring and lecturing, I always tried to make it clear and explicit that what I'm telling is a practical simplification, that it has limits here and there, but _within these particular constraints_ it's a good approximation. And the feedback I got was always that it made things much clearer to people - <USER2> felt it makes sense, because it had context.

<comment><USER10> I guess I am doing a bad job of explaining.

What I taught was a way of working. I didn't deviate from the practices, because the principles are easy to state but hard to truly grok.

Going back to what I said earlier, this is the difference between weightlifting drills for various parts of the movement, versus discussions of physiology, anatomy, anthropometry or physics.

You start with the drills.

<comment><USER12> Thanks for the clarification. So it's something like, first learn to do something in a decent way, and only then - when you're familiar with the subject matter - start thinking from first principles?

<comment><USER10> Sort of. It's mostly about instilling habits of thought -- eg asking "how do we test this?" before touching a keyboard.

Learning when and why to break the rule takes longer. It helps to first go through a bunch of concrete examples.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I think working on a large project in c89 made me better at writing in other languages.

When you strip all your useful tools and concepts away, you're forced to rethink how you can organize with just data types and functions. Surprisingly, you can do pretty well with just these.

It's the sort of thing that helps with recognizing when you're looking at FizzBuzz and when you actually need to use a generic factory.

<comment><USER14> When I started working with PHP over a decade ago I had some experience with Java so I thought it was funny that in PHP everything is an 'array'. Now that I'm working with JS and Elixir and getting into functional programming I'm realizing, that hey, maybe that _is_ the right way to go. Putting everything into structures like maps helps blur the line between code and data.

<comment><USER15> I have quite some background in OOP and switched to functional programming a few years ago, now working a lot with Clojure, where you actually have the "code is data" paradigm. And from my experience, it's way easier to model data with three simple structures; vectors (= arrays), maps and sets. There are other things, too, but most of the time these three types are sufficient. It requires some discipline in the beginning but it can give you a lot of benefits.

<comment><USER16> You are going to be lectured at length by the (OOP) static types crowd. And they have a point about using explicit types, _when_ it's easy.

That said, I wish the "strong types" crowd would take a look at all of the temporal coupling that their OOP designs are causing, with their update-at- will practices. Now that we have working garbage collector software plus adequate hardware support, why not make use of that?

FP needs to become a more widely used practice.

<comment><USER17> Some of the largest "strong types" advocates are FP folks

<comment><USER16> Some are, some aren't :-)

Some are just lost if autocomplete in the IDE doesn't enter stuff for them, and the more verbosely the IDE spews, the better, cuz it looks like "work".

</comment></comment></comment></comment></comment></comment><comment><USER14> I like this part: "Duplication is sometimes essential for the right abstraction. Because only when we see many parts of the system share "similar" code, a better shared abstraction emerges. The Quality of Abstraction is in the weakest link. Duplication exposes many use cases and makes boundaries clearer."

I just did this yesterday... copy/pasted some code from one function to another function, tested that the new function works and moved on, and then when I went back to work more on it, I wrote more generic code that can be called by either function. Don't have to overthink things before writing the first function.

<comment><USER18> I tend to see this when people try to pre-emptively abstract. Not "we seem to be duplicating 3+ blocks of code here" but "we _might_ want to do this again at some point so we need an abstraction to make it easier next time".

The former almost always works while the latter almost always fails.

The former gives a little dopamine hit and a boost to the ego because that's being "an architect" while the latter feels more like being a janitor. Ironic really.

<comment><USER15> Interestingly, the second approach is often recommended in functional languages, although in a slightly different way; compose complex/complicated logic of small pieces. You end up with a lot more functions but it allows for code reuse.

I am note quite sure, though, if we can already talk about an abstraction then.

<comment><USER19> There is no code reuse of small non-generic functions in practice, just duplication and thus ravioli code. And to make these small functions generic costs time.

What may make sense is to make something similar to lemma in proofs. This is strictly for ease of debugging or readability.

</comment></comment></comment></comment><comment><USER20> Point #7 are called non-functional requirements. Those are often implicit from non-technical people. Nobody will say: "I don't want to be hacked" or "i don't want this system to slow down and die"... This guy says "we don't need NFRs, focus in the functional requirements"... well, that's exactly the cause behind most engineers that get fired for technical reasons: causing one or more serious incidents by not caring about those requirements.

Point #2... seriously? Keep your code consistent, and if you identify opportunities for reuse for things that are related then do it. Copying and pasting code, which is what this guy is advocating for, is not good.

<comment><USER21> > Copying and pasting code, which is what this guy is advocating for, is not > good.

Well obviously this is why we have variables and functions, etc. And hopefully this helps enforce DRY ("don't repeat yourself.")

But, reusing a component leads to coupled code and that can also spell disaster. Sometimes it really is better just to copy stuff. Maybe this is a matter of taste; some people like to have the perfect design and if that makes them a happy coder then i guess you should let them do that. I find that, more often than not, the "perfect design" is not worth sweating over. My style is tracer-bullet: get it working today, write some tests maybe, and then refactor it.

<comment><USER22> I like the term "tracer-bullet." You should get that written up as a blog, if it isn't already.

Reminds me of an anecdote about getting people onto the moon. When that was their goal, the very first thing Nasa did was make sure they could hit the moon with a rocket. Then iterated from there.

<comment><USER12> > _I like the term "tracer-bullet."_

The term is actually from the book Pragmatic Programmer (a good book, though I'd say mostly for beginner-to-intermediate programmers, since a lot of software blogs are essentially just repeating the contents of this book ad nauseam).

I tend to do that too - get something working fast, and iterate over it. Focusing on perfect abstractions makes no sense if then you find out you're aiming in the wrong direction.

<comment><USER22> Embarrassingly, I should have known that. I just checked to make sure that wasn't where I heard the "just hit the moon" quote.

I find I have been terrible at obsessing over abstractions I could be proud of. I try to instead keep my eyes on solutions I can talk to.

</comment></comment></comment></comment></comment><comment><USER23> The most interesting takeaway for me is this: [...] The best quality of a Design today is how well it can be undesigned [...]

Aiming for design that's easy to refactor and/or replace bolsters application longevity at the expense of code longevity. I like that. It's like the ecosystem longevity is achieved at the expense of the longevity of individual organisms...

Now then, who has ideas, or best practices or even just anecdotes? I'm eager to hear those!

For my part, I follow design philosophy that revolves around persistent data structures. My code is supposed to be just an accessory to the data. I don't think I'm explaining this well, it's just where I put all my focus on. Another principle is to try capturing users intent rather than the outcome of users actions. This way I can redo the code that detived outcome from actions and fix some the earlier erroneous behavior.

<comment><USER14> _My code is supposed to be just an accessory to the data._

Fred Brooks: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."

</comment></comment><comment><USER24> Of all the 'maintainable' design pattern use I've seen over the past decade, I have never seen one prevent a continuously maintained code base being rewritten periodically. All that work is thrown away just as a simple to-spec implementation would have been.

It seems that just as in literature, in software engineering too, the essence of writing is _rewriting_...

<comment><USER23> Accepting what you said, there is still one pattern that's helpful - <USER3> code that's easy to rip out later. It's covered in the article as well:

[...] The best quality of a Design today is how well it can be undesigned. [...]

<comment><USER24> Agreed! Piecemeal rewrites instead of big-bang rewrites...

</comment></comment></comment><comment><USER25> Point #8 sounds great: reuse OSS, don't reinvent the wheel. However, this only applies to software that is maintained, now and in the future. Relying on obscure code-bases without knowledge on its inner workings is going to bite you down the line.

Examples? Grunt, Bower, Hibernate, Apache Commons. How long did it take the Apache Commons project to properly add generics to its libraries? How is backward compatibility and developer availability holding back projects down the line?

Additionally, in order to use a library, you need to have a good knowledge of the problem it tries to tackle. By overly relying on open source software, you might blunt the competitive advantages of your business. It's an example of exorbitantly relying on abstraction.

<comment><USER26> I like to think of this as a _dependency cost_. Adding a library may "relieve" implementation cost, but adds a dependency cost (ie. finding+evaluating dependencies, integrating and maintaining the dependency, testing the dependency and so on).

This cost varies a lot, for example a library to left pad a string may be easily replaced, but if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example.

In the more general case more issues are attached: choosing a deployment stack, a documentation or translation tool etc. can result in decisions that are essentially set in stone. These also tend to be composed from multiple tools, leaving more wiggle room. Deployment for example might be done with AWS and Ansible on the higher levels, but use in-house tooling for figuring out the details.

Similar arguments apply to code de-duplication and DRY: de-duplicating code isn't free, and not always the right thing to do.

See also: [http://blog.liw.fi/posts/dependency- cost/](http://blog.liw.fi/posts/dependency-cost/)

<comment><USER27> This varies a lot. Python generally has good libraries. JavaScript (in my experience) generally has far more fragile libraries and its a lot faster moving, so the dependency cost is more likely to bite you. Usually there are a few libraries doing the same things, so go for the mature ones.

</comment></comment></comment><comment><USER28> This is a great article, thank you very much for writing it.

I pretty much agree with all points, except number 9 could probably be "Not challenging the Status Quo" instead of "Following the Status Quo".

Breaking the status quo just for the sake of it would be a mistake, while healthy challenge of status quo with open mindedness to accept to not change anything is probably a better direction.

> Areas of code that don't see commits for a long time are smells. We are > expected to keep every part of the system churning.

Or it could be an indicator of mature features that were well designed and implemented to minimize future headache: they just work and have very few stable dependencies, if any.

</comment><comment><USER29> One of the (really sad) reasons I suspect is behind a lot of these practices - like pointless wrappers and pointless genericization - is that nobody will pay you to "understand something". You have to produce something, even if you don't quite understand what it is you're supposed to be producing. Sure, you can spend an hour reading a horribly written-by-committee "requirements document", but you had better be producing something that looks like a program by the end of the day. Since admitting that you don't quite yet "get" the DB layer is a fast-track to the unemployment line, some developers have learned to buy time by creating meaningless abstraction layers while they're trying to figure out the inner details of OAuth or Cassandra or whatever else was supposed to be "saving us time".

</comment><comment><USER30> Those things are not necessarily all that terrible. I can see how overeager coders might do any of those things in anticipation of some as yet unseen requirement. And it's not always clear why a code base evolved the way it did.

Also let's not forget the opposite. I've worked in places where everyone just wrote their own spaghetti, no concept of version control, and every time there's a small change it takes ages for the only coder who wrote it to untangle and modify it. Basically a steaming pile of turd, used to invest real money in the real market. The worst part about it is when you call them out it's YOU who doesn't understand the requirements.

<comment><USER31> The thing is that just because it's spaghetti code doesn't mean it's not successful and thus it can be fixed.

Premature optimization is the developers version of pixel perfection. They are both the enemy of getting anything done.

<comment><USER32> Spaghetti code is so frustrating to refactor, that you sometimes may as well rewrite to maintain your sanity.

<comment><USER31> Sure but then you do that. Its better than having spent an insane smount of time on something no one ends using.

<comment><USER19> Write a serious test suite before doing so. Otherwise you will miss a bug 31337 fixed in 19xx and will be sad later.

</comment></comment></comment></comment></comment><comment><USER33> Besides agreeing with the article on many points, I thought the examples were gold. Too often articles about best practices are too abstract.

I would love to read more practical articles like this. Any URLs people could share?

</comment><comment><USER34> 11\. You need Big Data.

<comment><USER35> Or "You have Big Data". Paraphrasing Greg Young's idea, "If you can put it on a Micro SD card that you can buy on Amazon, you don't have big data". So if your data fits in 128GB ($37.77 on Amazon right now) you don't need big data solutions.

<comment><USER36> I would say that the definition of what is big largely depends on the problem you try to solve. If that problem is finding keywords in text files, then your definition sounds about right. For other problems even a couple of KB might be big. To me, big is when your dataset is too big to solve your problem in reasonable time on one machine.

<comment><USER14> Right. I'm not comfortable with this idea of big data being dependent on the actual file size of the data. There really are problems where doing stuff like reading files or using a relational database break down and you need something else that's more specialized in solving a problem even if the dataset is just a couple GBs. (So in my mind big data is a reference to specific tools or approaches like map-reduce, etc.)

</comment></comment></comment></comment><comment><USER20> Here there is a more mature list anyways: [https://en.wikipedia.org/wiki/Anti- pattern#Software_engineer...](https://en.wikipedia.org/wiki/Anti- pattern#Software_engineering)

</comment><comment><USER37> Not modern software, just bad software, written by Java developers.

Not everyone thinks or codes like this, and those that don't are not all greybeards.

</comment><comment><USER38> _1\. Engineering is more clever than Business_

...I don't get it? This sounds like it should be saying we try to "plan ahead" too much, but then the description seems to say we don't do enough.

 _2\. Reusable Business Functionality_

I think this is arguing against doing too much design work up front? From what I've seen, incrementally growing a system tends towards the opposite problem unless I'm _aggressively_ looking for refactoring opportunities.

 _3\. Everything is Generic_

This isn't a case of too much vs enough, it's a case of correct vs incorrect. If you can guess how the business requirements are likely to change, making things generic _in the right way_ will make that change much easier to do.

 _4\. Shallow Wrappers_

Yeah. Unless you have actual advanced knowledge that you'll need to switch out a particular library, this should be done on-demand as a refactoring step before such monkeying around. Except for things where you need a seam to make testing easier.

 _5\. Applying Quality like a Tool_ and _5.1. Sandwich Layers_

...does anyone actually think this way?

 _6\. Overzealous Adopter Syndrome_

Maybe, but keep in mind these can also be used to clarify _intent_ or to intentionally constrain future changes.

 _7. <X>–ity_

The examples look like things where pursuit of whichever <X>-ity _didn 't actually work_, rather than cases where it wasn't needed.

 _8\. In House "Inventions"_

These tend to be a result of either very old systems that date back to before an appropriate reusable version became available, or organically grown systems that had parts gradually come to resemble some existing reusable thing (that initially would have been overkill and more trouble to use than it was worth).

 _9\. Following the Status Quo_

Or in other words, "don't fix what ain't broken" isn't actually good? How is this "over-engineering"?

 _10\. Bad Estimation_

How does this fit the theme? I thought the standard way to improve estimates was to put _more_ thought and detail into them, which means the problem here is actually _under_ -engineering (well, that and general noobishness).

.

.

Edit to add:

 _Important Note: Some points below like "Don't abuse generics" are being misunderstood as "Don't use generics at all", "Don't create unnecessary wrappers" as "Don't create wrappers at all", etc. I'm only discussing over- engineering and not advocating cowboy coding._

So... if you disagree you're wrong and misunderstanding the article? If it's that misunderstood, it's the article's fault for failing to communicate effectively.

<comment><USER12> > _...I don 't get it? This sounds like it should be saying we try to "plan > ahead" too much, but then the description seems to say we don't do enough._

My view may be biased by my experience, but I understand it that - no matter how beautiful logical structure you invent that makes all the requirements fit perfectly, the business will quickly come up with a new case that doesn't really fit anything. Business requirements are unpredictable because _they make no fucking sense_ \- they're combination of what managers think customers need, what marketing thinks it needs, what future visions your boss has that he didn't tell you (or that he doesn't himself even understand yet), all with a sprinkle of peoples' moods and the subtle influence of phases of the Moon.

See also the motto of American Army - "If we don't know what we're doing, the enemy certainly can't anticipate our future actions!" ;).

<comment><USER38> This is only the case if the business is incompetent and insane, and also not communicating effectively with development.

Or maybe things can _look_ that way, if the devs don't understand the business.

The business is doing something to make money. The requirements will somehow work to support that something, or will be something that your business contact _thinks_ will support that something. If they don't make sense, that means your mental model of the business is different than your business contact's mental model. And unless your company is unbelievably dysfunctional, that's an opportunity to talk and reconcile those models.

</comment></comment></comment><comment><USER39> Finally, some real talk!

<comment><USER25> Sorry, please comment on the article. No 'me too!' comments. If you like the article, there is the up-vote button.

</comment></comment><comment><USER40> This is a fairly well-written post with some good ideas and some generalizations that are going to get somebody in trouble if they follow all of them, e.g.

> TL;DR — Duplication is better than the wrong abstraction

Woah, horsey, hold on a moment!

While it's true that an abstraction can get you into trouble, that's not always true.

Over my many years I've heard a number of people say: "We have 100 copies of the same site, but slightly altered for each client, and we don't have time to go back and refactor them, we can't upgrade them, and we're three major versions behind. Want to come work for us? (Silence.)"

I've only heard one person say, "We refactored X and it bit us in the ass, because the developer didn't check when he/she was altering it and accidentally changed behavior for everything."

<comment><USER14> The trade-off isn't about the dangers of not refactoring v.s. refactoring. The trade-off is about time plus the aspect this article hammers, which is lack of knowledge about the future--i.e. if you made a multi-purpose multi-client framework to start with you might still be building things and rewriting them to fit them into even more unforeseen situations instead of having live code running for 100 clients.

<comment><USER40> Two things:

* It's vs. not v.s.

* If you want to copy a site 100 times, go for it. But I know very few that ever thought that was a great idea, and each time it was a very specific case. Yes there are client-specific features and multi-tenant sites, but that's not what he said. He said "copy vs. abstraction" which is the opposite of refactoring.

As an aside, I'm really having trouble understanding how people in the HN community could be thinking I'm wrong on this.

I think I need to go to a forum that's more grown-up if this is how things are here now.

</comment></comment></comment><comment><USER41> This only really applies to web-developers.... but I guess that is what is meant by "modern software"

<comment><USER42> I'm not sure about it applying only to web-developers. It might be more focused on application-developers, where business requirements hit the UI. Developers working on services, libraries, frameworks, and platforms have different engineering needs where some of these guidelines don't apply (and others might).

</comment></comment><comment><USER43> This is great. TL;DR of the whole thing? Don't do (almost) anything unnecessary ahead of time.

I have a small bone to pick with 4) Shallow wrappers. My design process involves ignoring existing solutions for problems and then finding things to match my desired design. Often, this requires absolutely no wrappers, sometimes it requires shallow wrappers, sometimes more involved wrappers, sometimes implementing it all myself.

I do agree that you should not blindly wrap anything.

All in all, a great article. I think this should be required reading for aspiring designers/architects.</comment>


The impact of $2k of new recurring revenue on a SAAS business - <AUTHOR> http://blog.aparicio.org/2013/02/08/recurring-revenue-impact-for-saas/

<comment><USER2> From the article:

> Every extra $1,000 in Monthly Recurring Revenue (MRR) contributes $78k to > the annualized revenue number. This is basic math

"Basic math" tells me that $1k in monthly revenue is $12k in annual revenue [1].

I ran some numbers and figured out that he's actually talking about $1k of monthly revenue _growth_ per month. I.e. if your plan costs $10/month and you get 100 new customers per month, then at the end of the year, you'll be making $78k / year more than you would have if you didn't have any new customers.

This is, indeed, basic math. (In particular the sum of an arithmetic series [2]; he comes up with 78 because it's the 12th triangular number [3] [4].)

[1] Plus a little bit if you're putting the money in an interest bearing account, but interest rates are very low right now.

[2] <http://en.wikipedia.org/wiki/Arithmetic_progression#Sum>

[3] <http://en.wikipedia.org/wiki/Triangular_number>

[4] <http://oeis.org/A000217></comment>


ZX Spectrum Next Kickstarter is now live - <AUTHOR> https://www.kickstarter.com/projects/1835143999/zx-spectrum-next <comment> jan-kleks This reminds me of the MEGA65 project ([http://mega65.org/](http://mega65.org/)). They're making a beefed-up version of the Commodore 64, and here we have a ZX Spectrum on steroids.

It's really cool to see that FPGAs are used to "enhance" old hardware. Check also FPGA Gaming reddit: [https://www.reddit.com/r/fpgagaming/](https://www.reddit.com/r/fpgagaming/)</comment>


Like Mixergy-style interviews? Check out this TechZing podcast ep. w/Amy Hoy - <AUTHOR> http://techzinglive.com/page/563/94-tz-interview-amy-hoy-how-to-build-a-product-empire

<comment><AUTHOR> I know, I know I'm late on the TechZing bandwaggon. Many of you nice folks here on HN have said good things about it before. But this was the first time I heard them, and they did a _great_ job. Maybe they're always this good :D

Also, props to Amy Hoy, who was honest about the tough stuff, and fun stuff (giving up the numbers, etc).

Props all around.</comment>


Facebook launches Messenger app for desktop - <AUTHOR> https://about.fb.com/news/2020/04/messenger-desktop-app/ <comment><USER2> I assume they are launching this due to the recent news about WebKit removing support for progressive web apps (PWAs) in the future. This is also probably a move to compete directly with apps like Slack that already have desktop applications.

I would be really enthusiastic about this and install it everywhere if I was a Facebook Workplace customer, but I don't see the appeal from a consumer standpoint. There's a lot of potential for undetected data collection that can be done with a desktop app with permission to access video and microphone. I guess you could say the same about Slack and Microsoft Teams, but they have a better reputation for how they handle data they collect from their customers.

Ignoring the privacy issues, the consumer market for Facebook Messenger has already installed it on their mobile phones and get notifications there. If you need to write out a longer response, go to the website to type it out.

</comment><comment><USER3> Mac app has keyboard shortcuts and adapts to system Dark Mode, neat. Since it's distributed through Apple and Microsoft's app stores, how much safer is this compared to a direct download?

</comment><comment><USER4> On the one hand, this is great because Native apps fit in better and work more nicely.

Unfortunately, due to Facebook's untrustworthy behavior in the past, I would be reluctant to install this because of the additional information that would be available to them through a native app.

</comment><comment><USER5> Only compiled for x64... Very frustrating as a user on ARM64 windows.

</comment><comment><USER6> Isn't Facebook messenger incumbered by ads?

I don't see that in WhatsApp, hangouts, signal, telegram...

</comment><comment><USER7> Both Facebook proper and Messenger were always available for Windows.

</comment><comment><USER8> And here is something I absolutely would not install.

</comment><comment><USER9> Any word on on the stack used to build it?

<comment><USER10> [https://twitter.com/wongmjane/status/1245719533723119617?s=2...](https://twitter.com/wongmjane/status/1245719533723119617?s=21)</comment></comment>


Real World OCaml - Public Beta - <AUTHOR> http://www.realworldocaml.org

<comment><AUTHOR> Some more info from the author on this release at:

[https://sympa.inria.fr/sympa/arc/caml- list/2013-06/msg00101....](https://sympa.inria.fr/sympa/arc/caml- list/2013-06/msg00101.html)</comment>


OO Side Effect Free Programming - <AUTHOR> http://www.programmersparadox.com/2008/08/27/oo-side-effect-free-programming/

<comment><USER2> I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually _increase_ your side effects.

Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly this reason.

<comment><USER3> Method arguments are a decent place to keep transient data as well. Local variables and object fields are not the only options for scoping your data.

<comment><USER2> You are correct, as long as you don't get too many arguments.

<comment><USER3> Then start using closures :)

</comment></comment></comment></comment><comment><USER4> Perhaps I've become an FP zealot, but I just can't agree at all with this author's suggestion. Small methods, "agile", unit testing, and _all that_ are fine and lovely, but none of them approach the kind of safety and composability you get from true FP.

</comment><comment><USER5> "It's the closest to side effect free programming you can get in OO."

No, you can still have side effect free programming in OO. All of the techniques for programming without using mutable state are language agnostic and should carry over to whatever OO language you are using. You might have problems in languages that lack tail-call optimization, but even that can usually be worked around by using folds.

Now, I'm not claiming that it's feasible to make an entire app in (for instance) Java purely functional, but you can definitely build the majority of your app/library/whatever without using mutable state.</comment>


Ask HN: What to expect when a completely new coder - <AUTHOR> A friend of mine is considering a career change, and after years of his programmer friends encouraging him, he's looking at coding.
He's taking it cautiously, but I pointed him at Python and suggested a few sample projects, and he's only got a few hours of coding under his belt but it's obvious he enjoys it and is a quick study.  Once he has the basics down we plan to expand his exposure so he can learn what specialties (web, backend, etc) might appeal to him.  This is all going very well.
My problem is that I have no idea what to tell him to expect going forward.  I have no idea how long it will take him (using his spare time) to advance from "I made a text-based simple calculator" to "I can talk to databases and spit out web pages" to "I am employable at a salary equal or better than my current salary (40-50k)".  I have no idea how a NEW coder finds work vs an experienced coder.  It's been 20 years since I was new to this, I had coded for years before I entered the market, and the industry has changed a lot since then anyway.
A few factoids:
* He has BA degree in an unrelated field * We are in Seattle, WA, USA * He is not currently looking at a bootcamp or other rapid training unless that is necessary * He is recently married and they are looking to start a family, so an amount of stability is required.
Has anyone had experience that is more relevant/helpful?  Any non-obvious pitfalls that it makes sense to avoid? <comment><USER2> Let his aspirations decide the language. Nobody ever got fired for learning C. Python is a great start for ML, JavaScript for the internet. Anything else is a plus.

He is lucky to be in Seattle; the only requirement is putting the time in and knowing what you want to achieve. The money will follow.

</comment><comment><USER3> The shortest path to a career would be if he could use Python proficiently, then applying for jobs that requires Python. An easy way to get proficient would be cheap online work that pays poorly but will have him solving diverse problems.</comment>


Best Buy to Acquire Napster for $121 Million - <AUTHOR> http://www.centernetworks.com/best-buy-acquisition-napster

<comment><USER2> Another acquisition that is most likely going to fail. They usually do. I love reading the empirical academic studies on them.

Edit: Changed "going" to "most likely going". I'm not an oracle although it would be fun.

<comment><USER3> Almost all acquisitions fail? Could you elaborate why you believe that? Will you not consider acquisition as an exit strategy?

<comment><USER2> With regards to your first question:

We plan on issuing dividends - that's it. We will not be acquired unless 1) We have a family and/or close friend emergency that requires ridiculous amounts of money crucial to someone's survival or well being; 2) Tom or I become sick of what we're working on and want to work on something else or 3) We're not making enough money to live off of.

We're already profitable so I'm not too concerned with #3 yet. Anything I've ever wanted I already have - more money is not going to make me any happier. Also, I worry that I don't have whatever is it takes to have gobs of money and _not change as a person_.

<comment><USER3> That's an interesting point of view. Apart from financial gains for founders, acquisition also makes sense for the consumers in many cases. E.g. it makes sense for the company building a spreadsheet app to get together with the ones building the presentation and word processing apps. The alternative is for every company to build everything (or at least everything in each app suite), and that's just wasteful.

That's just the product development side. There's also marketing, manufacturing (not in web apps), and distribution (also not in web apps) synergies.

I'm curious to understand your logic against acquisitions. Integrating 2 corporate cultures, creation of larger bureaucracies?

<comment><USER2> Sure.

The elimination or reduction of true work schedule flexibility (which we don't have entirely yet, but will have soon). A Boss. Red tape. Bureaucracy. Suits. TPS Reports. Worthless meetings. Sub committees. Work that isn't "work". And most importantly, corporate rules and protocol not in line with our philosophies of living & working.

TicketStumbler is a bit of a different animal than most startups & companies. I plan on writing about this extensively in the future (<http://intheteeth.com>). I'm not saying acquisitions never make sense or never add value or that I'll never have a Company that will be acquired...just that TicketStumbler more than likely won't be "that" Company.

</comment></comment></comment></comment></comment><comment><USER4> This just goes to show - if you build a strong brand name for a period of time, the amount of money you can milk from that name is really really large. Look at netscape. It has changed, but people know and recognize the brand, and they keep going back.

</comment><comment><USER5> does anyone actually use napster anymore?

<comment><USER6> "From the release, the proposed acquisition includes Napster's approximately 700,000 digital entertainment subscribers..."

<comment><USER7> $173 per subscriber seems a little high to me.

<comment><USER3> Really? They're paying a little more than 1x the revenue per subscriber, which sounds like a great deal. It's not an ad-supported web2.0 company.

<comment><USER8> agree. It is not an ad-supported company which make its subscriber more valuable because they actually paid.

</comment></comment></comment></comment></comment><comment><USER9> Why is MarketWatch.com saying the price was $54 million?

[http://www.marketwatch.com/news/story/best-buy-acquire- napst...](http://www.marketwatch.com/news/story/best-buy-acquire- napster-54/story.aspx?guid=){08814974-C2C6-4134-BAE6-AC9651B16AB8}&dist=msr_2

^ holy mangled URL, so much for pasting that here.

</comment><comment><USER10> Napster is so worthless right now that it is better to spend $1M (and save $120M) in a couple of seasoned developers and start from scratch with some new and fresh ideas.

</comment><comment><USER11> Ha Napster doesn't support OSX yet? I knew what I was getting into when I went to the site but... wow.</comment>


Open vs. Closed APIs - <AUTHOR> http://blog.apievangelist.com/2011/06/01/open-vs-closed-apis/ <comment><USER2> I agree with this article. More discussion about closed APIs and how to implement a good closed API would be great.</comment>


Exit to Community - <AUTHOR> https://www.noemamag.com/exit-to-community/ <comment><USER2> I am baking this feature right into my community-building software. Anyone can at any time export all the content and rebuild it into a new site with identical threads, thread IDs, parent-child structure, user IDs, and even allow the same user accounts to pick up where they left off. :)</comment>


A New Way of Voting That Makes Zealotry Expensive - <AUTHOR> https://www.bloomberg.com/news/articles/2019-05-01/a-new-way-of-voting-that-makes-zealotry-expensive <comment><USER4> Looks like this would favor highly coordinated groups to have outsized influence over poorly coordinated groups.

So people who vote in isolation have less influence than people who organize and vote as a bloc.

I think it also means that places where one party predominates would require the minority party to be highly coordinated in order to have any chance with one single silver "bullet" whereas the dominant party can expend multiple "bullets" to counter.

<comment><USER5> This is democracy though.

The idea of a majority having more power than a minority is, as another user puts it "a feature, not a bug". If your goal is to best represent your population, then you want a system that counts people's opinions equally, regardless of what group/s they belong to.

The problem here isn't the voting system so much as the structure. The way to "better represent" minority groups is to have different weightings to those groups. But then that's difficult because you have to specify which groups are more equal than others. Clearly we like racial minorities and don't like minority groups like white nationalists (at least as a public), but most lines aren't this easy to differentiate.

The goal of voting systems like this is not so much to tackle this majority vs minority problem but rather to reduce tribalism. In a first past the post voting style your optimal strategy is not to pick the thing you like the most, but to rather pick the thing that you think is most likely to win and more closely aligns to your beliefs. These voting systems are more about finding common beliefs. For example, republicans and democrats agree on many issues. These systems are about anti-polarization, not about weighted representation.

<comment><USER6> Majorities being > than minorities is an aspect of democracy in its natural state, for certain, but I would not go so far as to call it a feature. The bicameral legislature of the U.S. was designed precisely to avoid this "feature"!

<comment><USER7> > The bicameral legislature of the U.S. was designed precisely to avoid this > "feature"!

Not really, it was just made to weight the scales (in both houses, by different mechanisms) so that a particular set of interests[0] would be less likely be a political minority even if they were a numeric minority. It retained the feature that political minorities were easily suppressed by the political majority, so long as it was a political minority in both houses.

[0] The slave states of the South.

</comment></comment></comment></comment><comment><USER8> I always hate the framing as "polarized". There's tons of things Democrats and Republicans agree on.

Military spending goes up every year. Save for Dodd-Frank, deregulation has been common across presidencies for 30 years along with corporate tax cuts...

The establishment gets things done, they really do, it's just not things that help everyday people. I'm not sure how this would help that.

<comment><USER9> Basically they disagree on how to treat their fellow citizens.

Democrats are against outright hostility and blatant marginalization of certain classes.

But both have largely been ok with everyone being exploited by feudal trade economics, bombing other nations to satisfy global political norms, and swindling developing nations out of their resources, while emotionally coddling elites.

It means something to not be outright hostile to the truly marginalized, but the Dems have not exactly been labors friend. And most people are laborers. They've failed the majority plenty.

<comment><USER10> "Democrats are against outright hostility and blatant marginalization of certain classes."

There are tons of YouTube videos on college campuses that prove otherwise.

<comment><USER11> Reminder: having shitty ideas is not a protected class, and "free speech" does not mean you get to say whatever batshit crazy thing comes to mind without other people expressing themselves

<comment><USER12> Plenty of people on both sides have "batshit crazy" ideas, except one leans more heavily on mob mentality thanks to the self-righteousness that comes with the unshaken belief that you have the moral highground.

[https://www.youtube.com/watch?v=kMc8pczn- hs](https://www.youtube.com/watch?v=kMc8pczn-hs)

<comment><USER13> _except one leans more heavily on mob mentality thanks to the self- righteousness that comes with the unshaken belief that you have the moral highground._

Well, Goldwater _tried_ to warn the Republicans about what would happen if they kept sucking up to the evangelicals, and...

Oh, wait, were you talking about Democrats?

</comment></comment></comment></comment></comment></comment><comment><USER14> The greeks had two institutions we could use: ostracism and lottery.

We should be able to vote on those we want out of politics and the most voted would have to seat it out.

And a small portion of representatives should be chosen by lottery. Maybe 5% or 10%. These representatives, obviously, would not have to answer to their sponsors.

<comment><USER15> Actually, why not choose _all_ representatives by lottery?

I don't think representatives need to have any particular competencies beyond being representative of the interests of the population. Hired staff can take care of things that require particular abilities.

I reckon that a wholly random set of representatives would act like a direct democracy where every voter is free to fully focus on the issues, is allowed an entire staff to help them, and can consult and coordinate effectively with other voters. I think that could work pretty well.

<comment><USER16> Would this have a similar outcome as the "lottery" for jury duty? What happens if somebody who really doesn't want to do it is chosen?

<comment><USER15> That's a very good point. I currently lean towards requiring every citizen to register for the lottery once every ten or so years (for one year of service). If they are picked, they have to go, except for serious unforeseen circumstances, but at least they would be able to plan for it to some extent. This might also require a cultural shift for people to accept it, but maybe not a radical one.

<comment><USER17> For someone who doesn't want to do it, a year is a very long time to come up with 'serious unforeseen circumstances'.

There is no point in trying to force people to do things - the best way is to change the job in such a way that people will _want_ to take it.

Pay them well, in other words, in money, in prestige, or otherwise.

<comment><USER18> _> the best way is to change the job in such a way that people will want to take it_

This isn't a change, it's what we have now. The problem is that the _kind_ of people that want to take it are not the kind of people you actually want doing it.

</comment></comment></comment></comment></comment></comment><comment><USER19> This would be an interesting strategy to apply towards measuring how an open source community feels about difficult tradeoffs in design where there is no clear winner among many proposals, such as the recent survey meant to measure how people feel about the various async/await syntax proposals in Rust.

[https://www.reddit.com/r/rust/comments/biw1ic/asyncawait_syn...](https://www.reddit.com/r/rust/comments/biw1ic/asyncawait_syntax_status_update/)

[https://www.reddit.com/r/rust/comments/bju8di/asyncawait_syn...](https://www.reddit.com/r/rust/comments/bju8di/asyncawait_syntax_survey_results/)

<comment><USER20> I don't know about this particular issue, but in general there's something to be said for beneficent dictatorship. My hypothesis is that sometimes the choosing of individual parts that are measurably better on their own, when combined produce something that is less than if the parts weren't optimally chosen but were cogently chosen to meet a particular ideology or end.

</comment></comment><comment><USER21> The basic form of quadratic voting, with actual money, also makes trying to protect yourself and your rights against hostile voting blocks expensive. Are you black? Muslim? Transgender? The majority votes to screw you over in some way, and you spend to vote harder against them and so manage to stop them. And then you've spent quite a bit of money, which gets redistributed to all voters (ie, everyone in your group sees little of it back)...and then they vote _again_ to do the same damn thing you opposed before, and now you're fucked.

<comment><USER22> This assumes the majority would focus their energy on a narrow set of issues. Unless you have studies to back up that assumption, I would not believe it.

And if the majority actually did feel so strongly about a narrow set of issues, then it should be very expensive for a minority to counter that.

</comment></comment><comment><USER23> >>The purpose...is to determine "whether the intense preferences of the minority outweigh the weak preferences of the majority">>

Given this, apparently the problem is that strong minority preferences are being snuffed out by majority preferences? Of course, this is the inherent flaw in democracy.

In the US we have two guards against that - the first is the Electoral College and the second is the Constitution. The former ensures that even the least populated states have at least a minimum (as opposed to effectively none) effect on the outcome and the second ensures that the government can't be used for something evil just because a majority has voted to to use it for that purpose.

So if there's a "zealotry" problem as the title implies, why can't these tools be used to manage it? What is wrong with them such that we need this new, additional layer?

<comment><USER24> >Given this, apparently the problem is that strong minority preferences are being snuffed out by majority preferences? Of course, this is the inherent flaw in democracy.

That's not the problem Quadratic Voting tries to solve at all. The increased cost of additional votes actually reduces the voting power of certain minority groups, such as one-issue voters. The system tries to fix the opposite - <USER2> strong minority preference winning a vote where it is not the first choice of the majority.

<comment><USER23> Ah yes, got it. I missed that, thanks.

</comment></comment></comment><comment><USER25> In the US where the parties cling to stupid and outdated viewpoints and agendas in order to differentiate themselves from the other party. Legislators have to vote with the party if they don't want to find the party funding an opponent in the next election cycle. This is an improvement insofar as it allows legislators to nominally vote with the party while voting more strongly in favor of things they actually care about.

This would probably work well in two party states because it would allow lawmakers to vote as weakly as possible for stupid things just to say they're towing the party line while not actually voting strongly for them. In single party states this is probably a bad thing because it gives the people who ran as the other party just to get their name on the ticket to only weakly vote the way their platform says they should be voting.

If this system were used outside of the legislature (i.e. to actually elect legislator) it would probably be a total shitshow because as other commenters have mentioned it rewards coordination which basically just favors the status quo. If there's anything we need it's less status quo in general elections.

So yeah, this might work in a legislature but I don't see it working well to elect the actual politicians themselves.

<comment><USER26> The more that politics become local the more this all goes away. States need to be at the foreront again

<comment><USER27> I'd go further and argue that city-states make the most sense in today's world, with a federal government to arbitrate resources and defense. US state boundaries are quite arbitrary with respect to how actual communities are organized on the map.

<comment><USER26> But you have an option to move to a new state that fits your beliefs. Much harder to do when it is a Federal system with a single law for all thr lands.

</comment></comment></comment></comment><comment><USER28> It's clever, but it doesn't solve the problem.

Because the problem isn't with _strong_ preferences -- it's with _extreme_ preferences.

If there were 7 versions of a bill (A,B,C,D,E,F,G) ranging from ultra- conservative (a "A") to ultra-liberal (a "G"), in a polarized community people could still be spending the minimum 1 point each on the A's or G's and none on B-F.

The problem with politics today isn't that people are single-issue voters (because they generally aren't -- it's not a problem that needs to be solved)... it's that the natural evolution of the two-party system has forced us into choices that are more _polarized_ than ever before in the history of the US -- in a two-party election, we're often only _given_ options A and G, or maybe B and F, but rarely C through E.

<comment><USER29> > the natural evolution of the two-party system

The US has a long history, almost all of it with a two-party system. Only sometimes is there extremity. To my mind, 1860 is even more extreme than today.

(My opinion is that an important common thread between then and today is a class of people with a great deal of money who are deliberately driving the political atmosphere. But in any event a claim that it is a natural outcome of a two-party system needs to account for the historical fact that the US experience is typically not extreme.)

<comment><USER28> Slavery was a particularly and uniquely intractable problem where a "moderate" or "centrist" solution was particularly unappealing.

There's extensive literature on what's been driving polarization, but it really is a new "era" for it and not a cyclical thing. Factors include:

\- More democratic/open primaries, which select extreme candidates

\- More statistically targeted media (including social media) to take advantage of extreme views (including social media)

\- Increasingly partisan news media made possible by more fragmented media (first cable, then the Internet)

None of these show any signs of going away, and all three are phenomena that are fundamentally new in the past few decades.

<comment><USER30> > _Increasingly partisan news media made possible by more fragmented media > (first cable, then the Internet)_

Isn't the entire mainstream media owned by only like 6 corporations[1]?

[https://www.google.com/amp/s/amp.businessinsider.com/these-6...](https://www.google.com/amp/s/amp.businessinsider.com/these-6-corporations- control-90-of-the-media-in-america-2012-6)

<comment><USER31> There used to be literally three channels. We've doubled!

<comment><USER32> Well 4 if you count PBS.

<comment><USER31> We've 1.5x-ed!

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Since the link to the paper, at the end of the article, is subtly broken (at least for me), here are the links to the abstract and directly to the PDF:

[https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)

[https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID3092895_cod...](https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID3092895_code1186331.pdf?abstractid=2003531&mirid=1&type=2)

Doi:

[https://dx.doi.org/10.2139/ssrn.2003531](https://dx.doi.org/10.2139/ssrn.2003531)

</comment><comment><USER34> Let's say Alice only cares about proposition A. And Bob only cares about B.

Alice can spend all her 100 tokens on A, and she gets 10 votes on A. Ditto Bob can spend all his 100 tokens on B, and he gets 10 votes on B.

But if each of them spends 50 on A and 50 on B, then A and B both get 2*sqrt(50) ~= 14 votes, so both Alice and Bob win by colluding.

What's to stop them doing this?

<comment><USER35> Oh no lawmakers actually cooperating to achieve their goals. What a tragedy!

<comment><USER36> But does not support "across the aisle" cooperation, which is where the concern is.

</comment></comment></comment><comment><USER37> This actually looks like it could be applied very effectively to open source communities on a single project when setting priorities for future feature development. For example, you have 20 features in the backlog and you're going into a two month sprint in which you can only focus on 3. Might be an interesting way to open up voting to everyone. On larger projects this would be useful even if it's only the developers working on it that are voting.

<comment><USER38> I'm skeptical about why volunteers should work on anything other than whatever they feel like working on? Voting on free labor seems presumptuous.

</comment></comment><comment><USER39> If I were a politcal group with lots of members up for reelction, I would be sure to flood the ballot with things the other side wants to vote against so they'd have to spread out their tokens whereas my group could clump them on a single issue/candidate.

<comment><USER40> The other party(ies) could do the same, so I don't see how this is any worse than the current system.

</comment></comment><comment><USER41> I have had so many discussions with people about finding better ways to vote and hold elections.

It's nice to hear when there's a new approach that is actually being used, even if it was only in a small community, although I would be interested in seeing something like this used in large scales elections.

</comment><comment><USER42> This is just deciding the order of business - not voting in the sense a civilian understands it.

The other way this can be done in parliamentary systems is to have a lay member body sort through and produce a draft order of business.

This body also decides which motions are in order which are duplicates and which need to be composited (ie a merge in tech speak) and also works out any conseqensionals (eg if Motion A passes then Motions G X and Y fall)

<comment><USER43> Yes the usual situation we're familiar with is picking a candidate in an election (which is what millions of Brits were doing yesterday) but it's the same for all these decisions. The key ingredients are more than two options (if there are only exactly two options we can solve this nicely and if there's only one option it's trivial) and wanting to incorporate preferences from many different people (ie let's not have a dictator or use sortition)

Neutral arbiters (your "lay member body") are very expensive because they can be captured so you need to defend against that, and even when they aren't captured you'll have to put up with accusations that they /were/ by sore losers who didn't get what they wanted from the neutral arbiter. For a sovereign government you can't impose the neutral arbiter on them, so they'll have to agree to suffer it, and such agreement is necessarily conditional. You can do it (that's how the Speaker of the House of Commons in the UK works) but it's fragile and I wouldn't advise it.

<comment><USER42> They are normally elected and yes it is like the Speaker of the HOC though normally a bit more crunchy that the old softy that's currently in the position.

</comment></comment></comment><comment><USER44> What if we took this idea, applied it to wealth instead of votes, and called it something like "progressive marginal tax rates"? Seems like it would be a more effective way to fight zealotry than to attack the democratic principle of all people getting the same amount of votes.

<comment><USER45> Every voter has the same number of tokens, so it is fair.

The quadratic progression is _per candidate_ (or issue or whatever object is being voted on).

If you have 91 tokens, you can vote once for each of 91 competing choices. Or you can vote 6 times for one option: 1 + 4 + 9 + 16 + 25 + 36 = 91. Or twice each for 22 options, with three tokens left to vote on three more.

<comment><USER44> But tokens aren't votes. A person whose ideology aligns with 100 options has 10x the ability to influence the outcome of the election towards their preferred outcomes than someone whose ideology aligns with only one option.

<comment><USER24> But "votes" with tokens aren't votes either. Claiming that a spread of 100 votes has 10x the effect of 10 votes requires some model of the vote - <USER3> don't know that 10 votes on a single issue doesn't have an outsized effect on swinging a decision where 100 single votes just bump a number up across the board.

More than anything, the system just places power in compromise, which is nothing new - in a one-vote system, a person who is willing to vote for a centrist politician has more political power than me, a fringe voter, because their influence on the election result is better-felt.

<comment><USER45> There is a problem if there are 99 items to vote for, which are all aligned with each other, more or less, ideologically, and 1 item that is diametrically opposed to these. Someone casting 99 votes for those 99 items has political power over someone trying to concentrate on that one, only able to cast 6. This system works best if all the choices are very distinct.

If numerous choices are really just minor variations of the same choice, that tends to undermines the system with a rather gaping hole. The cynical observer might note that in fact that's the idea behind it: entrench the power of the bland, indistinct choice in leadership.

</comment></comment></comment></comment></comment><comment><USER46> Not so much zealotry, as N-way decisions. There's no perfect way to make N-way democratic choices. Yet sometimes you need to make an N-way choice.

Brexit needs something like a ranked-choice vote. As in, rank these options - a) no deal Brexit b) Theresa May / EU plan c) no Brexit, revoke Article 50 d) Northern Ireland independence, border in Irish sea. None of those can get an absolute majority in Parliament. They've tried and are deadlocked. A ranked- choice referendum would provide a way out.

</comment><comment><USER47> It's nice to see other ways to vote. One of the other newcomers is STAR Voting ([https://www.equal.vote/starvoting](https://www.equal.vote/starvoting))

Ka-Ping Yee's analysis showing odd discontinuities in Ranked Choice aka Instant Runoff from 2005 is an interesting read [http://zesty.ca/voting/sim/](http://zesty.ca/voting/sim/).

<comment><USER48> STAR voting has the added benefit of simplicity and being possible on paper ballots. This quadratic system has neither and would be rife with errors, confusion, and likely fraud when used among people who don't vote for a living.

</comment></comment><comment><USER49> Does a fixed token count work when the voting is iterated and future bills are not yet known? It seems challenging.

For instance, you could incentivize your opponents to spend their tokens early on things they care about, and reserve your voting block for a later bill. So while it does cost you considerably more to spend your tokens this way, you've already weakened your opposition so that you might be able to pull it off.

</comment><comment><USER50> "Success" seems to be defined unclearly here. "Held and election and got a result" seems to be the only outcome.

"Quadratic voting was invented not by political scientists but by economists and others..."

Not much of a point here, this is clearly within the domain of economics.

It worked with 41 lawmakers, it seems like an interesting voting method for small scale. Can it scale up?

<comment><USER51> > Can it scale up?

A long while ago when I was in college we attempted to implement a less complicated version of this system for allocating budgets to student organizations and it was nothing short of a shit show. I'm not confident in the voting public's ability to understand the process.

</comment></comment><comment><USER52> > An intriguing new tool of democracy just had its first test in the real > world of politics, and it passed with flying colors.

how can you even measure if a voting system is a success?

<comment><USER40> Specifically, how does one measure _democracy_? I hadn't thought about this before, but I'm intrigued and no good answers are springing to mind.

<comment><USER52> there is a democracy index: [https://en.wikipedia.org/wiki/Democracy_Index](https://en.wikipedia.org/wiki/Democracy_Index)

there is something similar for voting systems but it isn't as elegant: [https://en.wikipedia.org/wiki/Comparison_of_electoral_system...](https://en.wikipedia.org/wiki/Comparison_of_electoral_systems)

</comment></comment></comment><comment><USER53> It's unclear to me if this addresses the spoiler effect which I see as the single, biggest issue in US elections right now.

<comment><USER54> 1\. End "winner-take-all" allocations of electoral votes

2\. Any party that gains the minimum population/electoral vote (Wyoming puts that at ~200k) in any state is guaranteed at least one electoral vote in that state

3\. All remaining electoral votes are allocated proportionally based on general election votes

4\. If no majority winner exists, the party with the least number of electoral votes casts their vote to other party/ies and this repeats until a winner obtains 270.

Wouldn't this remove the spoiler effect, function within the current voting system, and off-set any perceived _difficulty_ in rank voting to the actual parties?

</comment></comment><comment><USER55> Seems like a recipe for horse-trading.

As an abstraction, say we have a group of 400 fairly development-minded people who are mostly indifferent or OK with projects A, B, C, and D, with the exception that each 25% of this group _really_ likes one of these projects (the classic single-issue voter). Without horse-trading we get them spending their 100 points on their pet issue, getting 10 votes per voter, yielding 1,000 for each. With horse trading, they agree to split their votes with all 4 of the cabal's issues, which means that they can each contribute 25 points to 4 different projects, or 4x5 votes per voter, yielding 2,000 total.

So a disciplined party 'bloc' can exert outsized control in this scheme. Of course, the usual problems of maintaining discipline arise, especially with secret ballots where you can't prove that you kept faith with the cabal.

Another element of this (and any scheme where people's ability to express preferences is "rationed") would be the issue of what makes it on to the ballot to begin with - there's obviously some real prospects for mischief and vote-splitting. If you have the resources, the idea of creating a lot of moderately trivial proposals to draw away votes from things that you're opposed to might be effective - so if you want to get some huge development through that's opposed by environmentalists, you might attempt to jam the zone with a gazillion minor environmental proposals (all of which look fairly good) to try to suck away voting power from your political opponents.

</comment><comment><USER15> Couldn't this sort of incentivize efforts to polarize the public? If I want to get my way on issue X, but I don't care about issue Y, a good strategy for me would be to rouse everyone else about Y so that they waste their tokens on Y and can't oppose me as effectively on X. For example, I could push abortion as the most important issue of all, even though I really don't care either way, and then put all _my_ tokens towards tax cuts for the rich.

</comment><comment><USER56> The Polarity of Brexit throws up some interesting results, depending on how a possible poll is conducted.

Would be interesting to apply this methodology to the problem.

Here's a good write-up: [https://www.politics.co.uk/comment- analysis/2019/04/23/the-c...](https://www.politics.co.uk/comment- analysis/2019/04/23/the-crazy-polling-of-soft-brexit)

</comment><comment><USER57> "intense preferences of the minority" are enshrined in the constitution. The senate, the electoral college, and the states themselves are designed to protect the minority of property onwers. It's designed to slow progress. Read Madison.

Also, I'm sure Bloomberg writers LOVE attempts to replace Democracy with some weird economic neo-market model.

Coins...get a grip, man. EDIT: Sorry. "Tokens". Whatever.

<comment><USER58> I quite understand that there is a tendency to marketise decision-making in an unhelpful fashion, but I'm not entirely sure how this scheme is too much of a problem, beyond using the word "tokens". Could you elaborate as to the specific problems of this scheme as opposed to those of general attempts to marketise?

And "quadratic voting" may have uses beyond the areas governed by the US constitution. Even within those areas, there are minorities other than property owners. Blacks, for example, do not seem to have been very successful as a minority in preventing the various things that the state does to them that are plausibly unhelpful (though the quantification thereof may well be intractable). The particular use case here, however, seems to be to make the specific institutions you describe more effective, as opposed to relying on their being pitted against each other to make things work. I think that it is more desirable to have a single institution that works well, where possible (which it generally isn't) than multiple institutions that operate against each other in an attempt to avoid pitfalls, because one generally falls into more pitfalls in the process, even if the balance of advantage lies with the latter case.

<comment><USER57> I'm not sure how to put this in a way that won't sound offensive. Please cut me some slack in that regard, because I'm honestly not trying to be offensive. I think your description of this is naive in a very serious way.

Here the "marketing" is a big part of the point. Proposing solutions to democratic problems with something derived from economics provides theoretical cover to people who are seeking to undermine democracy in service of capital. The idea that democracy needs to be "more effective" because of some structural issue, not with society but with democracy itself, is incredibly dangerous.

EDIT: I'm rambling, but I think that the article was a type of propaganda. I was also trying to point out that the constitution enshrines some very extreme positions for at least one minority that actually benefits from things like what are described by this article. I don't take it's claims seriously because I believe that it actually exists to present aspects of capitalism as superior to democracy.

</comment></comment></comment><comment><USER59> The book this is from, Radical Markets[0], provides a unique perspective and is worth a read. It contains some very creative solutions to real problems and helped me to realize how small the box is for current policy debates.

[0] [https://press.princeton.edu/titles/11222.html](https://press.princeton.edu/titles/11222.html)

</comment><comment><USER45> I have a much better, simpler idea: you can't vote for the same candidate twice in the same election, period.

Another better algorithm is to have a single ballot with, say, ten blanks on it. You can fill it however you like, possibly with ten duplicates.

The blanks are weighted: the top blank carries more weight than the bottom, according to some geometric progression, like:

      1> (mapcar (op expt 0.8) (range 0 9))
      (1.0 0.8 0.64 0.512 0.4096 0.32768 0.262144 0.2097152 0.16777216
       0.134217728)

This quadratic concept requires too many tokens. If you actually want people to be able to vote for one candidate half a dozen times, you need to give them 91 tokens. But that then allows people to vote 91 times for different choices. If there aren't anywhere near that many choices, then people have tokens remaining which encourages them to vote for duplicate choices. It's just a mess where people get wrapped up in the token accounting and lose sight of the issues.

<comment><USER60> Do you really think some variant of lisp along with the op function is the best way to communicate with a wide audience? For normal people, that code is printing the result of 0.8^i for i=0..9.

<comment><USER45> I think that, well, HN comments aren't a good platform for someone looking for a wide audience.

<comment><USER60> And by wide audience, I mean people who don't program in lisp 100% of the time.

</comment></comment></comment></comment><comment><USER61> This approach is the direct opposite of what we need societally, which is _less_ of the feeling of "throwing your vote away" from voting a strong preference, as in Instant Runoff.

Political division is a symptom, not the root problem. It is being driven by people already being made to cede to the "center", where "center" really means authoritarian warmongering surveillance as pushed by the press. Discouraging "zealotry" is just quashing dissent even harder.

Left and Right are merely two different manners of reasoning (inductive versus deductive, open world versus closed world, etc). Reacting against the totalitarianism, people try to escape in whichever direction they tend to think in. Parties then herd them into blaming the "other side" by focusing on the most outlandish of that groups's conclusions, which of course are totally alien.

</comment><comment><USER62> What we need isn't necessarily centrism, but lowered emotions. Emotions are what skew reason and then catch like wildfire. It happens that they tend to push people to the extreme ends of the political spectrum, but that itself isn't really the problem. It's not about sheer distance from the center, it's about voting based on anger and hatefulness and fear. Anti-fascists in Nazi Germany would've been "extreme" relative to the center at the time, but they wouldn't have been "extreme" with regards to how hate-based their stance was.

Edit: Or more accurately - since many of them probably did develop hatred for the nazis - the anti-fascists' stance made the most sense when hate and fear are removed from the equation; were a person in that context to consider things stoically, there would've been little motive to side with the fascists.

To summarize: fear and anger warp your decision-making. It happens that they lead to polarization, but that's a red herring. What we need is to reduce the inflammation of society (largely thanks to social media), instead of tackling the symptom.

<comment><USER58> It's tempting to think that we can operate politics without emotion. However, it is unclear what the foundations of our political beliefs are if not intuitive reactions of the sort that emotions are as well. For example, most people who oppose torture oppose it because they have an intuition that it is unacceptable and value that intuition. We can construct "objective" methods to derive political claims from other claims, but ultimately they involve a value judgement—politics without value judgement has no way to decide between competing objectives. "Reason" does not provide a coherent morality, as the failure of the Enlightenment project shows; "emotion" is quite capable of justifying a centrist view—I should imagine most have negative emotional reactions to the Leninist and Hitlerite states. I imagine that one reason for the decline of the liberal order is its abandonment of emotional claims and pretence to objectivity as if that were possible. Those who continue to use emotion, to appeal to our intuitions as to what is right, instead of simply referring to empirical concepts whose connexion to such intuitions is severely dulled, appear to have the most success; unfortunately they do not seem to be particularly constructive at the moment. Anger and fear are not entirely unreasonable as emotions go: we fear and are angered by the spectres of poverty and dictatorship, and those are not unreasonable positions to hold.

Attacks on morality and value judgements in politics often take the form of, to take an example, Sir Humphrey's utterances in Yes Minister. Government, in his view, is about order, and the prevention of chaos. Hacker, the minister, suggests that it is about doing good. Why is Sir Humphrey so scared of chaos? His fear thereof is the same sort of fear that drives morality; we might even call it a moral belief. It is not an implausible belief—chaos has its problems. Most of the time what seems "objective" is no longer on demanding a further reason. "Lowered emotions" should not really be the end; a sensible method of dealing with competing emotions is the need of the hour.

</comment></comment><comment><USER63> A really excellent 2-hour podcast on the topic of voting:

 _Politics is so much worse because we use an atrocious 18th century voting system. Aaron Hamlin has a viable plan to fix it._

[https://80000hours.org/podcast/episodes/aaron-hamlin- voting-...](https://80000hours.org/podcast/episodes/aaron-hamlin-voting- reform/)

</comment><comment><USER64> Say I have a party/club/whatever. We're going to handle all sorts of decisions by voting and/or similar means.

Is there an app we can use that'll handle voting, and do a good job?

<comment><USER65> doodle.com

</comment></comment><comment><USER66> Within a caucus I think this makes sense.

I do worry about any wider use though. California has shown with its proposition system that issue voting can get really messy / absurd. A political caucus can maybe recognize that voting to (just an example) dedicate %60 of all revenue to X while understanding that they can't then dedicate ... %60 of all revenue to Y too. The general electorate is not so inclined or consider things past step 1 of governance (or really think about governance at all).

</comment><comment><USER67> Sounds like just a new name for cumulative voting, which has been a thing in closely-held corporations for decades. From a (U.S.) Securities and Exchange Commission Web site:

<quote>

Cumulative voting is a type of voting system that helps strengthen the ability of minority shareholders to elect a director. This method allows shareholders to cast all of their votes for a single nominee for the board of directors when the company has multiple openings on its board. In contrast, in "regular" or "statutory" voting, shareholders may not give more than one vote per share to any single nominee.

For example, if the election is for four directors and you hold 500 shares (with one vote per share), under the regular method you could vote a maximum of 500 shares for each one candidate (giving you 2,000 votes total—500 votes per each of the four candidates).

With cumulative voting, you are afforded the 2,000 votes from the start and could choose to vote all 2,000 votes for one candidate, 1,000 each to two candidates, or otherwise divide your votes whichever way you wanted.

</quote>

[https://www.sec.gov/fast-answers/answers- cumulativevotehtm.h...](https://www.sec.gov/fast-answers/answers- cumulativevotehtm.html) (extra paragraphing added)

More analysis: [https://en.wikipedia.org/wiki/Cumulative_voting](https://en.wikipedia.org/wiki/Cumulative_voting)

</comment><comment><USER68> If you're a developer and you're into voting, we're working on building an open source app for Ranked Choice Voting with a nonprofit called FairVote. The old version is at rankit.vote.

Angular app, Firebase, couple different voting mechanisms.

It's an attempt to help people understand how alternative voting systems can make the world a better place.

Email me if you're interested in contributing!

</comment><comment><USER58> Is there any reason that 2 is the best of all possible indices? It sounds, prima facie, reasonable, but it is unclear whether it is the best, what the best is, or even whether it can reasonably be calculated given that people behave irrationally in different ways.

</comment><comment><USER69> If the results showed people voting normally, spreading their votes across their options, isn't that a failure? What's the point of switching to quadradic voting when you get the same results as the old system of selecting 15 bills?

</comment><comment><USER70> > Quadratic voting "is the one vote pricing rule under which voters who intend > only their own gain are led, as if by an invisible hand, to advance the > interests of society,"

What's so special about n^2? I'd suspect n^phi is optimal.

<comment> dane-pgp Why phi?

</comment></comment><comment><USER71> Sounds like approval voting only with limited votes - [https://en.wikipedia.org/wiki/Approval_voting](https://en.wikipedia.org/wiki/Approval_voting)

</comment><comment><USER72> Isn't this basically the world congress system from Civilization V?

</comment><comment><USER73> Link is broken; gives fraudulent error message:

> We've detected unusual activity from your computer network

> To continue, please click the box below to let us know you're not a robot.

Does anyone have a link to the actual article?

</comment><comment><USER74> In a real election, couldn't you just run multiple candidates with identical positions and then have all but one drop out during the runoff?

</comment><comment><USER75> Get ready for regulatory capture on steroids

</comment><comment><USER76> I _fundamentally "_ believe in democracy and think that the way forward might be to experiment with these at the local level.

Either city/state elections or your own political parties.

If they REALLY work we would be HIGHLY competitive.

For example, instant run-off / ranked choice (or other voting systems) could be used in the Democratic primaries WITHOUT having to convince Republicans.

If they really work the Dems will have much better candidates better representing the people and should win more elections.

</comment><comment><USER77> This can be gamed easily by running N-1 clones of any given candidate, where N is the total number of votes allotted.

<comment><USER78> For some loose definition of "easily", assuming human candidates.

</comment></comment><comment><USER79> This is a huge misrepresentation of this voting system. It makes zealotry possible, not expensive...

</comment><comment><USER80> Simple approval voting works. Pick only one outcome? Sure, but you lost the chance to pick others.

</comment><comment><USER81> And people complain that ranked-choice voting is too complicated for the average voter...

</comment><comment><USER82> I first heard this described in a book written by Eric A. Posner and E. Glen Weyl. The book has a lot of other cool reasonably doable ideas.

[https://www.amazon.com/Radical-Markets-Uprooting- Capitalism-...](https://www.amazon.com/Radical-Markets-Uprooting-Capitalism- Democracy/dp/0691177503/)

</comment><comment><USER83> if voting was mandatory in america for all adults you would get more competent people running and third parties carrying elections until the major parties shifted away from extreme positions. you don't need to feed into madness, americans are sane people who want unity and common sense.

it's not hard to do, make voting day a public holiday or put in on a weekend, use stamps on peoples hands or use name-residence registries and discount multiple votes.

this would make american elections harder to buy, and the dollar doesn't buy you what it used to anyway...

<comment><USER84> 3rd parties actively hurt progress towarss their goals by splitting votes between them and the larger party with platforms closer to theirs.

The 1st past the vote system, will always end up in a 2 party system. Unless that gets replaced by a ranked choice voting or another decent alternative

</comment></comment><comment><USER85> I propose something better than any voting method: try to achieve perfect information

</comment><comment><USER86> The only problem with elections right now is Citizens United. Does anyone honestly believe that the Democratic nominees on the left are all running because they think they can win? Or can we agree that the ability to raise endless money and garner publicity under the guise of an election could be what they're after?

<comment><USER87> Is this exclusive to the Democratic candidates? I think this was the case for the Republican candidates of 2018 as well.

<comment><USER86> I'm saying this more in regard to the current crop of candidates because it's more obvious and egregious that there are some running for President right now that are doing it for attention and money.

Although you're right. This is by no means exclusive to one side of the aisle.</comment></comment></comment>


Wikimedia looking to change to a CC license  - <AUTHOR> http://meta.wikimedia.org/wiki/Licensing_update <comment> andrewl-hn Well, it's not really unexpected: when FSF updated their Free Documentation License they made a change to allow a transition to CC just because Wikimedia Foundation asked. Personally I like Creative Commons more for non-software content just because the license text is easier to read, besides the diagrams they show on their site are very helpful.

Their CC-GPL badge is broken, though. Here: <http://creativecommons.org/license/cc-gpl> they wrote 'GPL 2 or later' and if you click through to human readable version the 'or later version' clause disappears: <http://creativecommons.org/licenses/GPL/2.0/>

</comment><comment><USER2> It's a vote. So if you've got an account and have edited more than 25 times then go take part.</comment>


Facebook using Content Security Policy headers for Webkit. - <AUTHOR>

It looks like Facebook is using the experimental CSP headers today.  I am kinda amused by some of the whitelisted domains and apps.
I have provided here for your amusement.

    x-webkit-csp:default-src *;
     script-src https://*.facebook.com
                http://*.facebook.com
                https://*.fbcdn.net
                http://*.fbcdn.net
                *.facebook.net
                *.google-analytics.com
                *.virtualearth.net
                *.google.com
                127.0.0.1:*
                *.spotilocal.com:*
                chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl
                'unsafe-inline'
                'unsafe-eval'
                https://*.akamaihd.net
                http://*.akamaihd.net;
      style-src * 'unsafe-inline';
      connect-src https://*.facebook.com
                http://*.facebook.com
                https://*.fbcdn.net
                http://*.fbcdn.net
                *.facebook.net
                *.spotilocal.com:*
                https://*.akamaihd.net
                ws://*.facebook.com:*
                http://*.akamaihd.net;
 <comment><AUTHOR> For the less informed CSPs are a new web tool to help websites defend against cross site scripting.

Here is a definition of the spec, although this is only implemented for chrome, and safari. [http://people.mozilla.org/~bsterne/content-security- policy/d...](http://people.mozilla.org/~bsterne/content-security- policy/details.html)

</comment><comment><AUTHOR> I also find it interesting that they define allowed websockets, but don't define which iFrames are allowed.</comment>


Isabella – a voice-computing assistant built in Ruby - <AUTHOR> http://www.rubyflow.com/p/mq1pmi-voice-computing-in-ruby

<comment><USER2> Looks interesting. DIY voice recognition still seems to be in its infancy tho. I guess this is another problem to be solved with mass data.

Jasper [http://jasperproject.github.io](http://jasperproject.github.io) looks like another contender in this area.</comment>


Does the appendix serve a purpose in any animal? (2001) - <AUTHOR> https://www.scientificamerican.com/article/does-the-appendix-serve-a/ <comment><USER2> From a structure-function perspective, the human vermiform appendix is simpy the terminus of the tiniae coli: the cords of smooth muscle have to end somewhere. Similar "I gotta end somwhere" constructs are the gubernaculum and the platysma. Appendices tend to have lots of lymphoid aggregates, but the entire gut has lymphoid aggregates. The fact that more are in the appendix per square inch of epithelium, is probably due as much to its dependent location (everything in the right colon tends to fall down) as any developmental specialization. I am also not aware of any appendix-specific transcription factors (I think most pathologists would agree such a thing would be useful if it existed, see Krukenberg tumor).

At a histologic level, there is nothing special about the appendix. The cell types in the appendix are found throughout the colon: colonic epithelium, smooth muscle, lymphoid tissue, vessels, nerves.

I think the term "vestigal" is being misinterpreted by many as a suggestion that it had some more important function earlier in evolution. I rather doubt it. They assert that an appendix hasn't been described in some species. Ok, but have you positively described the absence of tiniae coli as well?

The association with the Bursa of Fabricius may hold water, because the bursa apparently develops from the avian hindgut, however, unlike birds, when we amputate the appendix of a baby human, it doesn't develop an immune deficiency. Also, the bursa seems to be further down the gut than that appendix, although I have not done a careful examination.

<comment><USER3> > From a structure-function perspective, the human vermiform appendix is simpy > the terminus of the tiniae coli ...

Are you an anatomist/pathologist ? Your post brings back memories of my med school years :) I tend to agree with you - the appendix may be a vestigial organ in the sense that it has a common derivation and serves an immunologic purpose in evolutionary relatives, but we can posit that it may never have done so in man

<comment><USER4> You cam posit so and you would be very wrong. See first reply.

Also look up side effects of appendectomy on pubmed to see what functions it has.

<comment><USER5> Care to provide a link? I did a search but the only results I found specified stump appendicitis (infection of any leftover bits) and bowel obstructions.

</comment></comment></comment></comment><comment><USER6> This question has been answered many times through numerous studies since 2001

TLDR: Yes

[http://www.sciencedirect.com/science/article/pii/S1631068316...](http://www.sciencedirect.com/science/article/pii/S1631068316300653)

[http://dujs.dartmouth.edu/2008/04/a-bacterial-safe-house- a-n...](http://dujs.dartmouth.edu/2008/04/a-bacterial-safe-house-a-new-role- for-the-appendix/)

[https://www.sciencedaily.com/releases/2007/10/071008102334.h...](https://www.sciencedaily.com/releases/2007/10/071008102334.htm)

[http://time.com/4631305/appendicitis-appendix-gut- bacteria/](http://time.com/4631305/appendicitis-appendix-gut-bacteria/)

</comment><comment><USER7> The appendix protects good bacteria in the gut. [https://www.wired.com/2013/02/appendix- revolution/](https://www.wired.com/2013/02/appendix-revolution/)

</comment><comment><USER8> It does for Koala's. There's probably better articles. This was the best of a bad lot on a quick search:

[http://www.abc.net.au/news/2007-10-10/scientists-discover- tr...](http://www.abc.net.au/news/2007-10-10/scientists-discover-true- function-of-appendix-organ/693946)</comment>


Icons of the Web, by Nmap - <AUTHOR> http://nmap.org/favicon

<comment><AUTHOR> YCombinator is under the left-bottom corner of the MSN butterfly.</comment>