Too Many Tools and Frameworks (2015) - <AUTHOR> http://mrmrs.io/writing/2015/07/27/too-many-tools/ <comment><USER2> The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them.

Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the other end of the spectrum, the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time.

I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).

Of course, I have no numbers to back any of this up - it's just an observation (one skewed by personal experience, no doubt).

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

<comment><USER3> You can spin it this way if you like. However, a big part of this framework and Tool epidemic is ego. The trick is to take a dominant framework or tool, find a deficiency, and then rewrite it again with that deficiency fixed. Why? Because if it takes off, your career takes of.

What developers should really do is contribute and make the existing projects better. Everyone will thank you for it.

<comment><USER4> Nope they won't, because then your are just another contributor.

There are thousand working on linux (the kernel). How many of them do you know?

<comment><USER5> Which is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?

<comment><USER6> From what I can tell, something.js if the amount of code is equivalent.

Having a patch or two in angular doesn't seem to move the needle.

<comment><USER5> No. Because nobody knows about your something.js

Getting something on Angular means you were able to get your changes approved and merged (team work)

Situation is better if you can have a bigger project or more people using your something.js

<comment><USER7> Well, left pad was quite famous. And especially famous when the author removed it. You never know.

<comment><USER8> Was it famous before the author removed it?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> For side projects, it can be a little daunting, but ultimately represents a healthy eco-system.

But the issue for me is how employers handles it. No, I don't know Angular. But I have used Backbone, Ember & React. So do you really need an Angular expert, especially when Angular is only a few years old and is completely changing in Angular 2?

Should employers insist on extensive trade knowledge in a specific framework, or should they be able to hire based on understanding of development and architectural principles, and give a new employee a little bit of leeway to get up to speed on their stack.

If it's the latter, then you can relax, and focus on reinforcing good practices and understanding the theory about what you're working on, and your resume will continue to build.

If it's the former, then you have to constantly pad your resume with skunkworks projects simply so it doesn't seem like you're getting "left behind." And that is exhausting, and not very useful to anyone.

<comment><USER10> (This isn't a personal attack on you or your ability, I don't know you)

I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible.

Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing.

If you take an ember / backbone / whatever expert and give them a few weeks angular training they'll rock a todomvc but full apps often end up with controller-as-a-god-object.

Genuine experts would be really nice to find, but it's really difficult because frameworks aren't given time to mature before the smartest people have moved on to other frameworks.

You're right that employers should hire on general understanding and give time, but the required time is typically 6 months and a failed project or two. Many employers don't make and don't want to make that kind of human-capital investment anymore.

The "rockstar" who knocked something up pads their resume with another project with a hot new framework, got experience with another new set of tooling and can leverage that to move somewhere else to produce more working but hard to maintain code in another hot new framework because their CV is padded with experience showing they're a quick learner, but the company left behind pays the cost in maintenance.

A genuine angular expert will likely be well employed for a while come helping troubleshoot and clean up the mess left by the cool crowd.

p.s. I am not an angular dev, this complaint can be leveled at a lot of hot new tech, particularly but not just the javascript front-end world, it equally applies to people who knocked up go microservices at a .Net shop, or hastily introduced mongo to replace oracle, etc., etc.

<comment><USER11> > I think yours is a dangerous attitude, I've seen a lot of mess produced by > people who come in to angular knowing other frameworks and their output is > terrible.

Outside of a hire-an-expert consulting gig, I really would say the problem here lies almost exclusively on the engineering management, or lack thereof, and broader staffing decisions. I don't think it's necessary to have a project fail for someone to understand a tool[1] but the ability for someone to get up to speed is a function of the time invested in things like mentoring and code- review.

Yes, many companies make the short-sighted decision to skimp on that investment but that needs to be recognized and fought as a management problem – any project is going to suffer in those conditions even if your entire team is staffed with experts because understanding the actual business problems is as hard as the tech stack and if you can't carve out time to think about a few controllers, there's no way that the rest of the problem doesn't have problems which are at least as bad.

1\. If true, that would be a huge sign that the tool has major design failures and is not suitable for production use rather than an argument against hiring people who aren't already experts.

</comment></comment></comment><comment><USER12> As a back-end developer, I find it interesting that the default answer is a _framework_ — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it can be done as a library than as a framework. We look for libraries that humbly strive to coexist with whatever other libraries we need. The few times I've dipped into web UI Javascript, I've felt like the developers of UI "frameworks" share this mindset much more than the people using their work; often they'll explicitly point out that the tool they've built (such as backbone.js) is a _library_ rather than a framework, while the people recommending it to me will say "no no, it's a _framework,_ " meaning "no no, it's way better than just a library." Is that an expression of a real difference between back-end and web UI code, or is it just different phases in the tide of opinion?

<comment><USER13> I'm pretty sure you're just playing with words here.

One of the most common complaints is that the biggest web tools are libraries, _not_ frameworks. React, for example, is very emphatically _not_ a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).

<comment><USER12> It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design.

I think it's very interesting that even though the expert and experienced programmers who create things like backbone.js and React have openly and explicitly designed them _not_ to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a _way,_ a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it.

But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?

<comment><USER14> First you can use reactjs alone without a flux architecture.

> Why are frameworks considered such a good thing

The only thing nice about framework is that they make the main workflow obvious. But things becomes scary when you walk on the wild side (backed by experience with Django and Django RESTframework)

The problem with reactjs is that facebook was using reactjs and its "architecture" for big apps and now they try to make it work in a more general context.

> in web UI programming that widely used and admired libraries end up being > called "frameworks" as a term of respect?

Backbone is framework, saying it's a library because you can use only the collection model and use whatever method you want to fetch your data or whatever template language or bind events yourself is like saying you can replace the URL routing or template language of Django on your own. Doable but not recommended.

</comment></comment></comment></comment><comment><USER15> I think the complaint about too many tools is really just a euphemism for complaining about peer and employer pressure to always be up-to-date with the latest tools and styles. Developers live in constant fear of falling behind.

But is this pressure justified? I see two possibilities:

a) The latest crop of the top 10% tools really makes us much more productive than last year's crop of the top 10% tools. So the best developers will always filter through a lot of new tools to find the best 10% and benefit from them.

b) After accounting for productivity losses incurred by constantly relearning and rewriting everything, the lastest best tools have no productivity benefits. They are just a distraction from the product we're supposed to be working on.

I don't think there is ever a time in history when this question can be answered unequivocally, and therefore it is never possible for good developers to stop looking for better tools completely.

However, I feel that at no time in the past quarter century has the pendulum swung so far in the direction of (b) where front end development is concerned. I realize this is very subjective.

</comment><comment><USER16> The tools + framework for webdev are javascript, html and css (and assets i.e. images/data). Everything else is an abstraction that has trade-offs.

Frameworks can help teams create a baseline standard. A custom framework can be something that you need to educate other developers with, better to have an external framework at times. But at the rate of churn, depending on the team and product, some frameworks makes sense and some don't. Monolithic frameworks are harder to change, micro can swap more easily.

Really in the end, all frameworks and tools are abstractions to help accelerate development, but sometimes they don't, and one case of that is constant churn. New frameworks are a healthy sign for active development but they also have a cost associated with them. Frameworks can also abstract away too much and shroud the real platform/standards which leads to lock-in. Each project and product has needs that some frameworks fit and some don't, real development/engineering is deciding what a product/project needs.

</comment><comment><USER17> The only way we are going to build better tools is to keep building them. Complaining about the sort of cambrian explosion going on right now on web development is short sighted. Ideas need to be discovered, explored and improved. Everything needs to be challenged. This is unknown territory in many ways. It does get a little hectic and tiring at times but that's the price we pay.

<comment><USER18> The tools need to be better than what came before, rather than just _different_. So far I've dealt with grunt, then gulp, then webpack. None of these are appreciably better than make, they are just different and newer...

<comment><USER19> You don't understand what webpack is. It's a module bundler. You use webpack in conjunction with make, grunt, gulp, or any other task runner or build system.

<comment><USER20> What do you use make, grunt, or gulp for in that case? My frontend build command is just "webpack". Everything necessary is handled in webpack.config.js.

</comment></comment></comment></comment><comment><USER21> I think the problem isn't "too many" \--- it's the fact that they're all reinventing the same things and adding significant complexity in doing so. It's an enormous waste of resources both on the part of the developers and the end-users who ultimately have to "bear the bloat".

Web development seems unusually prone to this trend, but I've seen it happen with software in general. I hypothesise that the reason for this happening to web development in particular is largely because the basic problems have already been solved long ago, so all this churn is created by people who are "oversolving the problem", having nothing else to do than to think of new --- but not necessarily better --- ways of doing it.

Introducing complexity must feel productive to a lot of people, and I suppose some derive pleasure from being able to learn about, build, comprehend, and modify such complex systems. But I don't. Making websites that require several MB of JS and the latest browser features to display a few KB of static text? I just don't see the point.

Related: [http://countercomplex.blogspot.com/2014/08/the-resource- leak...](http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of- our.html) and discussion [https://news.ycombinator.com/item?id=8679471](https://news.ycombinator.com/item?id=8679471)

</comment><comment><USER22> I've been building UIs for 20 years, and the tools we have now are the best I've ever had the pleasure to work with. It's more fun now than ever. More please.

<comment><USER23> Except now we have to target 3 different mobile platforms, the web, and possibly 3 different native desktop environments.

Where is the progress in that?

<comment><USER24> You develop for large and small screens, with either keyboard/mouse or touchscreen inputs. That's all.

The specifics are supposed to be automatically handled by preprocessing and deployment tools, or only cared for in the optimization/final polish phase.

</comment></comment></comment><comment><USER25> > "Using the same standards that categorize 90% of science fiction as trash, > crud, or crap, it can be argued that 90% of film, literature, consumer > goods, etc. is crap."

90% is also roughly the failure rate of startups. Pareto principle?

<comment><USER26> Yep, you just very concisely explained a comment I just wrote (I didn't see this one).

</comment></comment><comment><USER27> The problem with "don't re-invent the wheel" approach to software development is that, IMHO, software engineers are yet to invent the wheel in the first place.

</comment><comment><USER28> Ultimately the responsibility to pick reliable tools lies with the carpenter

<comment><USER29> The problem with that is that there are accepted standards for tooling for carpentry. Sure, there are 900 different kinds of tools, but they all solve a minimal subset of measuring, cutting, drilling, holding, joining, and smoothing.

There's no equivalent of the basic problems of carpentry in the profusion of javascript libraries. Many of the libraries written in the last year _solve problems created by other libraries_.

People forget that the reason Rails was such a revolution is that it took all the fifty kinds of crap that people used to build an application and made it available in one package with good defaults. The good defaults part of that is absolutely critical.

The problem is not "bad libraries", it's a complete lack of curation and direction.

<comment><USER30> Right, which we need to solve through better ways of curating projects as a community. Browsing through 20 different options in npm trying to guess which ones are good is not a scalable way to build software.

The long term answer isn't to have fewer options or barriers to entry for new frameworks. The right solution is to make better ways to browse and select between all the options we have available.

Can we curate libraries algorithmically? Or do we need people to do it? (And if so what should _their_ tools look like?)

<comment><USER29> > The right solution is to make better ways to browse and select between all > the options we have available.

I think you're missing the point. The problem is not "which library is best at x y and z", the problem is that nobody agrees on what X, Y, and Z are.

It's a definitional problem, not a curation problem. Curation is easy once you have a yardstick to measure things with (pun intended).

Again dropping back to the metaphor of woodworking, one can clearly evaluate the results of using any given tool against a thousand years of physical history - no such comparison is possible with current libraries, especially in the rat's nest of javascript, and that's fundamentally the issue.

</comment></comment></comment></comment><comment><USER31> I totally get what you are saying but it seems to be to be increasingly difficult to find the good frameworks, especially since the badness of some frameworks only manifest on larger scales.

</comment><comment><USER32> Looking at the long term life of an application, the abundance and volatility of the tools and frameworks is a nightmare. Who will find developers for ZZZZ framework in 3 years from now?

Also the fragmentation of efforts to improve the tools is a waste of resources. Instead of choosing a few directions and delivering, everyone knows better and it's doing his own version of different, but usually not better, tool. That will help anyone else? "Yes!", they will say. "I don't care", they think.

<comment><USER33> Yes then at some point we all end up using ML, Lisp or C, and then it all starts again :)

</comment></comment><comment><USER34> I've been a coder and have watched coders for a long time. I consistently see two trends.

As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile/to-do list tool.

It seemed that programmers were unable to grok the agile story concept without making their own tool to use it.

But I saw the same kind of thing in the code I wrote. I wouldn't just solve a problem; I'd solve a class of problems. Generalization was awesome! The more I generalize and account for edge cases, the more value I am creating! Woo!

Many of us programmers, myself included, are constitutionally incapable of just solving the exact problem we have using the minimal amount of code and then moving on. _We confuse coding with value creation, so we build frameworks and tools out of everything._ If you build a list sorter, that's okay, but if you build a 30KLOC list uber machine, that's better, right? After all, it does more. You worked harder at it.

The second thing I saw, which was even more painful to realize and accept, was that it was very easy to get "upside down" in a toolset or framework and not even be aware of what's going on.

The first time I saw it was when I was teaching a mainframe team Visual Basic, back in the 90s. We were building a simple form with a textbox and button. I had showed them the concepts and they were a smart bunch. I started the exercise, but a couple of developers were stumped.

Why?

When I walked over, the problem they had was the properties page. Sure, they got the concept of drag-and-drop. But once the button was dropped? There were like a million options in there! What was the right font size? What did this thing mean? And so on.

I thought that was pretty silly and tried to forget it. But then I noticed in my own work that I'd get sold on a new set of tools. For sake of argument let's use the old Infragistics web controls. They do everything! Amazing control and look-and-feel!

I'd drop them on a web page wanting to create a smart grid. But the grid didn't do X, and in my mind, X was what needed to happen. So I'd poke around at the help file. I'd go online. In some cases I'd tear apart the javascript and start fixing it myself. Hey, it's only web programming. I can do this.

But holy shit that took a lot of time. On my next project when I needed a grid? I dropped a HTML table in. Just added whatever functionality I needed directly from JS. Not only did it take less time, but the resulting codebase was easier to read.

Then I started watching the teams I coached. They very rarely talked about actually solving problems, or language/foundational issues. Instead they talked about tools and frameworks. This tool or framework would do this cool thing if you tweaked it like this. Joe spent 2 days trying to get Y to work.

 _For many, many teams, buying into the framework means buying into a complexity and cognitive overhead that 's siomply not relevant to the actual problem they're trying to solve._ I don't know. Maybe it makes them feel cool or something. One of the smart kids. But speaking as both a participant and an observer, it's whack.

tl;dr So sure, let a thousand flowers bloom. But your job isn't arranging flower baskets, it's helping somebody who's down feel better. You might not even need flowers at all. Stop focusing on the tools and start focusing on the solution. Then the tools will work themselves out.

<comment><USER35> Interesting, but you're pretty spot on. Personally this has caused me great angst[0] as I tend to write the absolute minimum amount of code necessary to solve the exact problem I'm trying to solve.

I tend to wait until I've solved a problem in similar ways three[1] or so times before I generalize it.

[0] Because other developers want to solve for a more general problem. [1] Three is such a comfortable number, isn't it?

<comment><USER36> I've noticed I tend to work in three passes, although not necessarily three tries.

First is an over-abstracted mess that may or not work before it eventually collapses. Brainstorming.

Second is a rewrite aiming for compactness, that could end up impossible for anyone else to understand.

Third pulls just the right amount of abstraction out of the terseness of the second pass.

I treat it like a feedback driven control-system. Too much abstraction? Dial it down. Not enough abstraction? Dial it up. Repeat until good enough.

If I stop at 1 or 2, the code is poor. If I don't oscillate, it takes more passes.

</comment></comment></comment><comment><USER37> As an aside, the author of the article is one of the authors of Tachyons—the library I consider the tool that makes me not want to die when designing web pages:

[http://tachyons.io/](http://tachyons.io/)

<comment><USER38> Tachyons is amazing, so I ported it for react-native: [https://github.com/tachyons-css/react-native-style- tachyons](https://github.com/tachyons-css/react-native-style-tachyons)

       <View cls="ba jcfs pa2">
          <Text cls="white tc">
              Something
          </Text>
       </View>

</comment></comment><comment><USER26> This is simply the Pareto principle (80/20) rule, and it's true of most things.

This is also true of Startups -- most of them die, but that doesn't mean they didn't add value in validated learning (positively or negatively).

Elon Musk has often stated that he thought Space X had very little odds of success, but he continued because he believed he could create value that someone else could build on.

</comment><comment><USER39> I disagree. When more developers build the same framework, quality will always be better, because it will be better tested, more reviewed, has more knowledge, has more integrations with tools, packages, other frameworks. I really hate when effort on the same area is distributed. When you have multiple tools instead of one, it's hard to find the best one.

</comment><comment><USER40> This is all fine and good - but it would be nice to know which one's work well, which are robust, and which one's are 'pro level' \- without have to experiment with each one.

It's really hard to tell these days.

After some experience with node.js - I'm weary to pluck anything that's not in the 'top 10' most established frameworks.

</comment><comment><USER41> Wake me up when the good ones are created then

</comment><comment><USER42> It's a feedback problem. People seek to solve problems and by doing so create new ones. Which also need solutions. That create more problems. Packaging, transpiling etc are already second order problems and there are third and fourth ones as well. This won't stop until js becomes completely unusable.

</comment><comment><USER43> (DEVELOPARALYSIS) [[https://techcrunch.com/2014/10/18/you-too-may-be-a-victim- of...](https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of- developaralysis/)]

</comment><comment><USER44> I confess to being one of the people who moans a lot, but this post might be right. I will try to moan less because the JS community has made a lot of progress. I guess the secret is not getting caught up in hype, and focusing on the real value.

</comment><comment><USER45> Java had the same issue in the beginning. Then time and money made many disappear. Now it is Spring and JSF. The hundreds of other frameworks have largely disappeared .

You need organisation. Which is again time/money/resources.

</comment><comment><USER45> Java had the same issue in the beginning. Then time and money made many disappear. Now it is Spring and JSF. The hundreds of other frameworks have largely disappeared .

</comment><comment><USER46> I'm building a better JS framework [https://github.com/crocodilejs/crocodile- node-mvc-framework](https://github.com/crocodilejs/crocodile-node-mvc- framework) \- release v1.0.0 comes out soon, join in Slack at [http://slack.crocodilejs.com/](http://slack.crocodilejs.com/)

<comment><USER47> > CrocodileJS is a Node MVC framework that lets you chew apart JavaScript

Four words in and CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks (Node is an immediate non-starter in the same vein as MongoDB). Just to give you some perspective and perhaps help you see the irony.

<comment><USER48> Node is an application runtime environment, not a framework. There are frameworks written on top of Node, such as ExpressJS.

[http://www.javaworld.com/article/2079190/scripting-jvm- langu...](http://www.javaworld.com/article/2079190/scripting-jvm- languages/6-things-you-should-know-about-node-js.html)

<comment><USER47> I know that. I wouldn't touch node with a 10 foot pole (after past experiences) and since the parent comment's framework is integrated with Node it's a non-starter.

</comment></comment></comment></comment><comment><USER49> The solution - don't use them.

</comment><comment><USER50> >.io domain

why am i not surprised

</comment><comment><USER7> Light bulbs have not improved, they have become worse, and are designed to fail.

<comment><USER51> The parent is right after all. Just do a search for "the 100 yr light bulb".

<comment><USER52> "planned obsolescence" for lightbulbs is not a recent thing though; [https://en.wikipedia.org/wiki/Phoebus_cartel](https://en.wikipedia.org/wiki/Phoebus_cartel)</comment></comment></comment>


Yes, Google "Stole" From Apple, And That's A Good Thing - <AUTHOR> http://www.forbes.com/sites/timothylee/2011/10/25/yes-google-stole-from-apple-and-thats-a-good-thing/

<comment><USER2> If you sit experts in separate rooms and give them the same problems, often they will converge to the same solution. Whether that is due to physical limitations, mathematical or statistical considerations, the current state of the market, what have you.

There are a lot of narrow physical constraints operating in this market: the size of the human hand, the size of a fingertip, the range of human vision, the distance from the eye to the screen in terms of arm's length. There are other technology givens like the resolution of a screen that fits in the hand and the precision of touch technology. There are cultural givens to pull something apart to stretch it or push it together to make it smaller, or to advance a view by turning a page.

The more you think about these problems, the more you realize how narrow the space for innovation was in them, and in fact how many of Apple's innovations were anticipated by the market. Apple got there first with the whole package and reaped the benefits in mindshare. But they shouldn't be able to seek rent on a solution that experts would create in a vacuum.

<comment><USER3> > _If you sit experts in separate rooms and give them the same problems, often > they will converge to the same solution._

As a universal truth, I don't buy this. This is partially based on my own engineering experience, but in terms of the smartphone market I see WP7 (and to a lesser extent Palm) and see touch phone experiences that are significantly different than what Apple developed/evolved with iOS (although it is true that some of the implementation details like pinch-to-zoom are present there as well, but other details are different).

There is no universal axiom that says that a smartphone experience has to look like an iPhone. I think everyone would be better off if Google took more of an independent route rather than just building an experience using bits and pieces of iOS and WP7.

<comment><USER2> I'm an engineer as well. I would say that in interfaces especially, we converge toward best practices globally. Your customer is not happy to have to learn a hundred interfaces or switch interfaces when they get a new device or program. For instance, the VCR. Or Windows version bumps. Or the Ribbon. They prefer one interface to rule them all, like Logitech Harmony remotes, the browser, the command line, Emacs.

The current market provides some evidence.

[http://searchengineland.com/comscore-android-nears-50-us- sma...](http://searchengineland.com/comscore-android-nears-50-us-smartphone- market-share-95768)

70% of the smartphone market is in iOS and Android, two very similar smartphone experiences. RIM's distinctive experience is at 20% and falling fast (it was at 27% in March). WP7 is an also ran at 5%. Symbian is at 2%. Palm is not in the chart.

If you believe those numbers, the contest is all but over. Every non-iOS non- Android experience is failing in the market. It may not be just because of their designs, but I think you have to believe on other grounds that UX/design is the major selling point for all smartphones. The second contender might be applications, and iOS and Android are the leaders there too, by a wide margin over the field.

I think Google decided to beat Apple at its own game. Whatever you believe about how they used Apple's patented material (or not) or how valid the patents are (or not), clearly at some point a decision was made to compete with Apple not just on features, but also in UI polish and look and feel.

And somebody probably looked at Apple and said, how can we top that? When they couldn't, they kept it as similar as possible for a variety of reasons: the patents were too broad to be enforceable, they could justify deriving the same concepts in a vacuum because they come from well known UX principles that predate the patents, the design elements were universals that all phones should have, they should lower switching costs from iOS to Android.

I agree with you that Google could have gone its own way when designing a phone experience. But I don't know that that would have been a path to success. You would only have to believe the preceding paragraph to imagine that a think-different UX could have been worse for consumers.

</comment></comment></comment><comment><USER4> Deja vu - Apple has pretensions that everyone (and especially its biggest rivals) are stealing from them, while simultaneously copying successful features from countless other products.

The non-recognition of this fact of course is the biggest threat for Apple and non-recognition of pretensions of owning 'innovation' a threat. Because selling pretentiousness is the business model.

<comment><USER5> This was different. Look at the original Android Prototype: [http://techcrunch.com/2007/12/17/android-prototype-lets- hope...](http://techcrunch.com/2007/12/17/android-prototype-lets-hope-looks- can-be-deceiving/)

Google scrapped that and then turned around and copied the iPhone. And they copied everything about the iPhone. The resolution was the same. There were the same number of icons per row. Applications placed icons in the same place. You pinched to zoom on both devices. You switched between screens by swiping on both systems. Both systems had an app store (a previously unheard of way to deliver applications).

This isn't Mac vs. Windows or Xerox vs. Mac. This was way above that in the theft department.

<comment><USER6> I cannot tell if you're being facetious or not. App stores were not unheard of in the slightest.

<comment><USER5> Can you name an Apple like app store before the iPhone? The closest you can come is Nokia and Symbian and that was a download an executable type thing.

An app store as we understand it today where you click a buy button and the app installs on your computer was an Apple innovation

<comment><USER7> Linspire's click 'n run from 2002: <http://en.wikipedia.org/wiki/CNR_(software)>

edit: which of course, is just apt-get/synaptic + the ability to pay money. All of the real innovation came from Debian.

</comment></comment></comment></comment></comment><comment><USER8> I haven't read the Steve bio yet, however my guess is that his issue lies with the fact that Schmidt was a board member and how that relationship panned out, rather than the specific technology that showed up in Android. If technology of mine showed up in one of my board member's companies, I'd be pretty upset about it as well - but primarily on the basis that the board member "stole" from me instead of upholding his fiduciary obligation to my organization. Its a tricky one, but I think that Steve might have been right in this case.

<comment><USER9> Schmidt is on record (<http://www.charlierose.com/view/interview/11934>) that he would step out of board meetings when there were conflicts of interest.

<comment><USER10> If rumors are true then Eric Schmidt had an iPhone prototype in 2007.

[http://gizmodo.com/5479684/google-ceos-mistress-tell+all- blo...](http://gizmodo.com/5479684/google-ceos-mistress-tell+all-blog- prototype-iphones-and-steve-stoned-jesuit-jobs)

I don't think that Schmidt stepped out of board meetings until early demos of the G1 were shown off bearing a resemblance to the iPhone.

</comment></comment></comment><comment><USER11> I respect what Apple's done with the iPhone a lot more than I respect Google's contributions, but I don't see what Apple gains (beyond a little bit of marginal profit from slowing down Android adoption with lawsuits) from this holy war. In my mind, they've profited in exact proportion to how much they innovated in the phone market - Android just means that they'll have to keep innovating if they want to keep profiting.

Ultimately, I think Job's emotional reaction is one common to forward thinking people. Andrew Masson has been similarly disgusted with Groupon clones. PG hasn't exactly been sanguine about the YCominator knockoffs. The copycat competitors contribute in many ways, but I think that great minds can only respect people who bring truly new ideas to the table, not those that find a niche or an edge in the marketplace after riding in their wake.

<comment><USER12> Part of having a differentiated product is avoiding market confusion. While there is certainly some back-and-forth between Google and Apple, are there those here that don't think Samsung may have gone too far in mimicking so much about the iPhone/iPad experience? (From using Apple's icons in their sales displays to photoshopping iPhone screenshots for their phone, along with similar packaging and unboxing, ... the list goes on.)

Yes, some sharing is good for consumers, but at some point the knockoffs need to be called on it. The whole discussion boils down to where that line is.

<comment><USER13> There was an article recently about how, in a courtroom, a judge held up an iPad and a Samsung tablet and asked the Samsung lawyers to identify which was their tablet, and they couldn't. I think that's a clear indication that Samsung hurtled over the line.

(I'd provide a link but I'm on a flaky connection right now. It was on reddit, and probably on HN as well).

</comment></comment></comment><comment><USER14> Again, not to belabor a point but in a previous HN post, I noted that Microsoft Surface was likely an earlier prototype with multi-touch, as well as demos of a working "Pinch-to-zoom" back in 2006. I have no clue if and when iPhone already had this feature in a prototype, but Microsoft was definitely demoing this pre-iPhone.

[http://channel9.msdn.com/blogs/laurafoy/a-peek-inside- micros...](http://channel9.msdn.com/blogs/laurafoy/a-peek-inside-microsoft- research-reveals-tom-cruises-technology-today)

So the funny thing about the article is that it states as fact that Google copied Apple's pinch-to-zoom (but that it was a good thing), when in fact the case could be made that Apple copied Microsoft's pinch-to-zoom (I'm not sure if they did or not).

<comment> alok-g See also: <http://en.wikipedia.org/wiki/Multi-touch>

Excerpts:

A breakthrough occurred in 1991, when Pierre Wellner published a paper on his multi-touch "Digital Desk", which supported multi-finger and pinching motions.

... however both the function and the term predate the announcement or patent requests, except for such area of application as capacitive mobile screens, which did not exist before Fingerworks/Apple's technology

<comment><USER15> It's even worse, the pinch gesture goes back to 1983. [1]

[1] <http://www.billbuxton.com/multitouchOverview.html>

</comment></comment></comment><comment><USER16> I really wished Google or (more appropriately) Blackberry would have gone the opposite direction from Apple. Good keyboard support something more in the Raskin's Cat vein. It's nice to see Microsoft go with their Metro interface or the card metaphor of WebOS. Heck, just starting with a browser ala Chrome would have been better. The talk shouldn't be about patent violations, it should be about lack of vision.

I too believe much of this has to do with Schmidt on the board and the radical change of Android from pre to post iPhone. It just seems we really lost something when they made their switch.

<comment><USER17> > It just seems we really lost something when they made their switch.

I don't know about that. If they changed their "vision" from "replicate blackberry" to "replicate iPhone", we (where "we" = "society"/"everybody") didn't stand to gain anything in the first place, apart from cheaper phones maybe (and even that...)

<comment><USER16> I was hoping more for a more refined follow on to the Danger, not a Blackberry clone. Guess you're right though, any replicant would have not expanded anything.

There was really a shot at trying a lot of new ways to interact with mobile devices and very little made it to market in the quest to follow the other guy.

<comment><USER17> > There was really a shot at trying a lot of new ways to interact with mobile > devices and very little made it to market in the quest to follow the other > guy.

I'm glad Microsoft at least is going that way. Palm tried it as well (and as far as I'm concerned WebOS still has the nicest notification system) although they failed for other reasons.

</comment></comment></comment></comment><comment><USER18> The whole "imitate me and I'll sue" mentality is eventually going to stop innovation when we get to a point that you can't even use the same features regardless if they are accomplished in opposite ways.

This reminds me of Ford's stance when Robert Kearns took them to court for his design of the intermittant windshield wiper (the story was made into a movie a while back).

</comment><comment><USER19> It's a sad fact that Google became more of a follower than innovator recently. I can't remember of a successful innovative product by Google in the past few years, but we all know Google deals after Groupon, Google plus after Facebook and Android after IOS.

<comment><USER20> >It's a sad fact that Google became more of a follower than innovator recently.

Haven't they always been a do _x_ good company? Web search and email were around for years before google showed up.

<comment><USER13> Google disrupted the search market. Sure, the basic idea of searching the web wasn't new, but Google did it so much better than anyone else. Since then, they haven't done anything at all disruptive. They've just been copying other people's products and hoping their huge size will let them win.

<comment><USER21> Gmail was pretty disruptive, not to mention Chrome which reignited the browser wars in a way that Firefox never really did...

</comment></comment></comment></comment><comment><USER5> I think there's an easy answer to this problem but it gets obscured by an "either/or" mentality. Either you support patents or you think it's ok for Google to outright steal the iPhone interface.

Allow companies to patent innovations but legally force them to license it to others for a "fair price". That way companies can still build on top of each other's innovations but inventors still get financial compensation for their invention.

I recognize there would be a problem in pricing the license but since these cases end up in court anyway (where a judge or jury determines the fair value) I don't see how allowing companies to resolve what "fair price" means would be any different than what we have now. Except it would take out the ambiguity for the consumer(since a company like Google would never have to pull the product from the market).

<comment><USER22> _Either you support patents or you think it's ok for Google to outright steal the iPhone interface._

What if you think they copied the Palm Pilot GUI?

Music publishing has compulsory licensing, so there's some precedent about how it might work, but music copyrights are nearly as fucked as software patents. In neither case is the root problem addressed.

We need more pirate, less navy.

<comment><USER23> _> What if you think they copied the Palm Pilot GUI?_

Apple _did_ copy it from the Treo-era PalmOS. A grid of fingertip-sized tappable app icons.

And I'm OK with that, because it fosters progress, competition, and iterative improvements of existing technologies. I don't see the big issue with copying user interfaces. You'll either take the idea and improve on it, or make a mockery of it and your product will fail.

</comment></comment></comment><comment><USER24> Alternate Title: The reason why 17 USC 102(b) exists.

<http://www.law.cornell.edu/uscode/17/102.html></comment>


Google plans social games debut - <AUTHOR> http://www.sentinelsource.com/features/technology/google-plans-social-games-debut/article_6f9b7643-5963-5f17-b120-b549aac7678a.html

<comment><USER2> I'm worried that this decision is coming too soon. Of the people I know, it has been the ones who strongly dislike aspects of facebook like these money hungry games that have switched to G+ so far. The other users might follow them but it is a delicate transition and probably has more to do with community than features. Introducing games now might turn off a lot of the early adopters at a time when their continued presence is crucial.

</comment><comment><USER3> Do not want.

Plus is growing on me. It does what it's supposed to do and stops there. I don't want a bunch of smurfberry crap added to it.

</comment><comment><USER4> Does anyone have an idea what kind of platform they're going to require for developers to use? Will it be flash (hopefully not), Javascript?

<comment><USER5> my guess is it will be open to both Adobe Flash and "Google" HTML5.</comment></comment>


How to think about competitors in an immature market - <AUTHOR> http://blog.inklingmarkets.com/2010/03/thinking-about-competitors.html

<comment><USER2> If your business continues to grow I would say the article applies but if I hit a bump I would certainly look carefully at the competition to make sure nothing over there has changed the rules.</comment>


The Stages of IT Monitoring Maturity: A Framework for Enterprise IT Stakeholders - <AUTHOR> http://joshrichards.org/the-6-5-stages-of-automated-monitoring-in-it/

<comment><AUTHOR> Author here.

I've put together a write-up of the various stages of IT monitoring maturity most organizations go through. Feedback is always welcome.

WHAT: It includes the various types of monitoring, main coverage points, and typical implementation approaches and protocols involved. I also mention a few of the most commonly overlooked items in each stage.

WHY: I find it useful to understand the various key stages so that I can recognize where an organization is in its level of maturity, as well to introduce some tangible milestones around where the stakeholders want to go.

Perhaps a few of you will find it useful.

Feel free to share/re-post/distribute within your organization. Feel free to comment here, on the post, or drop me a note privately if that's more your thing.</comment>


HBO Star Zosia Mamet Makes Grant for Women in Entrepreneurship - <AUTHOR> http://live.huffingtonpost.com/r/segment/zosia-mamet-girls/53f50dfe02a760c59d0003e7 <comment><USER2> Ooshma, founder of Gobble who has a quick cameo in this video, is a total boss. The quality of women founders in YC is phenomenal, I'm proud to be associated. Though this is an extremely random TV spot, and I think it would be more interesting if Zosia Marmet asked Ooshma this question instead of the other way around.</comment>


JavaScript fetch API - <AUTHOR> https://davidwalsh.name/fetch <comment><USER2> Why would you want to "cancel" a request, instead of just ignore the response from the server? I feel like I'm missing a use-case here.

<comment><AUTHOR> You might want to stop the processing of an expensive task on the server

<comment><USER2> But if HTTP is stateless, can you actually cancel an operation?</comment></comment></comment>


The software fixed the hardware - <AUTHOR> http://www.jwz.org/gruntle/roomba.html

<comment><USER2> This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards.

It was simple enough to do, but it always feels a bit wrong.

Other types of software workarounds are possible though too. I once modified the acceleration curve of the robot (clamped down the jerk) so that there would be reduced stress on the poorly made drive train and under many failure modes this changed the robot from essentially dead in the water to workable.

It seems surprising how many issues you can solve with code if you aren't used to it. But these hacks are actually everywhere in a lot of embedded systems and allow teams to continue to quick, cheap and dirty work when needed that can get patched up later.

<comment><USER3> _it always feels a bit wrong_

It helps to think of it as "don't care" code rather than "error compensation" code. Which way should the engine be wired? It's cool; the software doesn't care. Just wire it up however. What order should I start these services? It's cool; they don't care. Just start them up however. As soon as your users stop caring about the stuff you can take care of, they'll have time to care about something else that's more important.

<comment><USER2> Well, the values actually sent out to the PWM were backwards. Thankfully I could just invert it at the last step in the code where it got sent and so while writing the actual code I could pretend everything was correct. It's hard to think of -127 going forward and 127 going backwards as anything but a dirty hack.

While the underlying electronics thankfully didn't care, the digitized values set up certain expectations.

<comment><USER4> Typically I get around this by having each motor's direction defined separately. Since you very often need to define the logic of a sensor ('1' can mean either ON or OFF depending on the sensor type) on a sensor-by-sensor basis, it makes sense to do this for motors as well.

</comment></comment></comment></comment><comment><USER4> Meh! If I had a dime for every time that I was told to fix a hardware problem in software, or provide a "limp home" mode if software detected a hardware fault, well... I'd have a lot of dimes. It's pretty standard behavior for electromechanical embedded systems.

The really important take home here is that the manufacturer sent out a software fix _to a consumer product that is not online!_ That's a huge leap forward and is something the industry has been pondering for a long time.

</comment><comment><USER5> I had a similar problem with my Roomba. Recently it began to bump into phantom walls where there were none, to the point where it would get stuck in the middle of the floor, turning around and around, stuck in a jail of invisible walls.

The Roomba detects this problem and emits a failure code of 9 beeps. I contacted iRobot about the problem, and their response was to ship me a fresh Roomba (without the battery + charging station) right away. Here are some pictures of the battery transplant:

<http://dl.dropbox.com/u/1149620/roombasurgery/index.html>

From the troubleshooting instructions that iRobot gives you upon encountering the 9-beep code, I suspect that there's probably just a faulty or possibly dirty (likely very inexpensive) sensor on the front bumper of the robot. I wonder if there's a similar fix to jwz's Roomba where I could patch for the bad sensor somehow (the roomba appears to have more than one way to detect it's stopped moving), and perhaps accept a slightly "dumber" but otherwise working Roomba.

<comment><USER6> My roomba has this problem from time to time. It's because the front wheel accumulates goo and stops rotating. The sensor that detects the wheel rotation then thinks the wheel is not rotating, and the robot moves erratically to free itself from the wall that it thinks is in its way.

Clean out the goo, and the robot is fine again.

</comment></comment><comment><USER7> This is nothing new. Read about Voyager 2. Specifically its platform problems between Saturn and Uranus in 1981, about 3 decades ago.

</comment><comment><USER8> Can they send one to Mars to fix the rover?

<comment><USER9> They can and have! I always thought this was very cool. However, the current Mars rover problem is not a hardware problem, per se, it's a stuck-in-the-mud problem.

<comment><USER10> An elderly robot that walks with a limp that's stuck in the mud problem.;-)

</comment></comment></comment><comment><USER11> Also it should be noted that devices like FPGAs allow for directly altering certain hardware structures via software.

In these cases it can actually be possible to fix a hardware bug (or add a hardware feature) via software, where the hardware itself actually gets fixed (ie its not just firmware working around an ongoing hardware constraint).

</comment><comment><USER12> So, does it actually "fix" the hardware by say, oscillating the wheel in such a way as to clean or jiggle the sensor, or does it update the firmware to compensate for the wheel sensor's spotty readings?

<comment><USER2> The entry itself speculates that the new firmware simply compensates for the spotty sensor(s).

</comment></comment><comment><USER13> Another example occurs on this thread: <http://news.ycombinator.com/item?id=1032063>

Here's the link: <http://news.ycombinator.com/item?id=1032152>

</comment><comment><USER14> When I saw it was jwz being linked to, I was worried I would have to suffer through a green on black web page. Oh, the relief.

</comment><comment><USER15> Why can't this be done with a download and USB?

<comment><USER16> Does the Roomba have a USB port? jwz mentioned a 'serial' port...

<comment><USER17> It does not have a USB port.

The serial port is also a non-standard (for serial ports) connector (it is a standard DIN connector). My guess is that the average Roomba owner doesn't have a PC with a serial port, and probably wouldn't want to acquire an uncommon connector and wire up a serial converter cable, and then run some program on their PC to dump the firmware image in to the Roomba. The osmo dongle makes the process near foolproof for soccer moms and grandmothers and so on.

<comment><USER18> Incidentally, there is evidence that the OSMO dongle collects data, also ..

</comment></comment></comment></comment><comment><USER18> I work in embedded. Primarily, my work involves fixing hardware bugs in software. This is not surprising to anyone who works in embedded, but for those of my programmer friends who just see the hardware and have no clue just how much software is under the hood, it always seems to be a big shock to them that I have had to spend a few weeks fixing a hardware design that had one pin wired around the wrong way, instead of just getting the hardware fixed.

That said, one of the things I really like to see these days is new generations of extremely competent hardware designers who have absolutely no problems with the expenses of hardware iterations .. even though it means less work for me in the end, its good to see. I have lost count of the times I've had to write some god-awful driver code that just makes me want to puke my lungs out, just because the hardware guys were too lazy to breadboard something ..

</comment><comment><USER19> Roombas are no match for Golden Retrievers.

<comment><USER20> As pets maybe... but I've _never_ seen a Golden Retriever clean a floor.

<comment><USER21> Wrong breed. I've got a food-motivated wiener dog that'll destroy any roomba in a floor cleaning contest.</comment></comment></comment>


Information – Consciousness – Reality (open access book) - <AUTHOR> https://www.springer.com/gp/book/9783030036317 <comment><AUTHOR> Editor description :

> This open access book chronicles the rise of a new scientific paradigm > offering novel insights into the age-old enigmas of existence. Over 300 > years ago, the human mind discovered the machine code of reality: > mathematics. By utilizing abstract thought systems, humans began to decode > the workings of the cosmos. From this understanding, the current scientific > paradigm emerged, ultimately discovering the gift of technology. Today, > however, our island of knowledge is surrounded by ever longer shores of > ignorance. Science appears to have hit a dead end when confronted with the > nature of reality and consciousness. In this fascinating and accessible > volume, James Glattfelder explores a radical paradigm shift uncovering the > ontology of reality. It is found to be information-theoretic and > participatory, yielding a computational and programmable universe.

The hardcover is around 50$, the ebook is free

<comment><USER2> Thanks for the opportunity to read. Appreciated.</comment></comment>


Why I still read technical books - <AUTHOR> http://timstall.dotnetdevelopersjournal.com/why_i_still_read_technical_books.htm <comment><USER2> In my experience, books provide higher-quality tutorials to subjects than anything online. Not only that, but all of the information is in one place, saving you the time of searching through the masses of poorly-written and incomplete online tutorials.

However, online is better than reference books. It also has more information on the latest trends and practices. But, you must be a very active reader to even know where to look for the latest information. And, you need to be very knowledgeable in the field to filter good posts from bad.</comment>


Why Hurricane Maria left Puerto Rico completely without power - <AUTHOR> https://www.theverge.com/2017/9/25/16362410/hurricane-maria-puerto-rico-power-outages-electrical-grid-destroyed <comment><USER2> TLDR: The hurricane destroyed 80% of the transmission lines and 90% of the distribution lines.</comment>


ELF: Better Symbol Lookup via Dt_gnu_hash (2017) - <AUTHOR> https://flapenguin.me/elf-dt-gnu-hash <comment><USER2> This might be a stupid question, but why don't they construct a perfect hash (like gperf, etc) at build time?

<comment><USER3> Wouldn't that mean having distinct hashes for every library? If so, that means you would have to, somehow, serialize the hash function inside each library and provide an efficient way to compute hashes.

It also would mean having to hash each function name multiple times during linking (once for each library searched until you got a hit)

Also, I think you would have to change the hash function (almost) every time a symbol is added to a library, but that isn't a show stopper. In the end, the linker will compare strings, anyways.

<comment><USER2> Thanks for you response. It would mean that, but if I understand the code at [https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl- look...](https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl- lookup.c;h=3d2369dbf2b7ca219eaf80a820e2a8e1329fbf50;hb=HEAD#l364) correctly, linear search through all mapped libraries happens already.

</comment></comment></comment><comment><USER4> (2017) (And the format dates to much, much earlier — but still interesting material if you like this kind of thing.)

> The problem with it is that DT_GNU_HASH is not documented anywhere other > than in GNU binutils and glibc source code.

Not really documentation either, but it is of course also implemented in LLVM and e.g., FreeBSD rtld.

</comment><comment><USER5> If this is so great, why isn't it the default?</comment>


Ask HN: What are your favorite algorithms? - <AUTHOR> Post any algorithms you think are cool, inventive, or useful. PDF links or blog posts are appreciated.<p>My current favorite is SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf <comment><USER2> The Fastest and Shortest Algorithm for All Well-Defined Problems: [https://arxiv.org/abs/cs/0206022](https://arxiv.org/abs/cs/0206022)

Abstract: An algorithm M is described that solves any well-defined problem p as quickly as the fastest algorithm computing a solution to p, save for a factor of 5 and low-order additive terms. M optimally distributes resources between the execution of provably correct p-solving programs and an enumeration of all proofs, including relevant proofs of program correctness and of time bounds on program runtimes. M avoids Blum's speed-up theorem by ignoring programs without correctness proof. M has broader applicability and can be faster than Levin's universal search, the fastest method for inverting functions save for a large multiplicative constant. An extension of Kolmogorov complexity and two novel natural measures of function complexity are used to show that the most efficient program computing some function f is also among the shortest programs provably computing f.

The catch is that the constants in the big-O are enormous.

<comment><USER3> I vote twice for this one!

<comment><USER4> Any laymen explanation ? Not able to grasp the concept.

<comment><USER2> It does two things concurrently: (1) search for an algorithm along with proofs for its correctness and time upper bound (2) run the fastest algorithm found so far, possibly aborting an slower algorithm when a faster one is found.

Everything is scheduled so it's asymptotically optimal. However, there's an added cost to search for algorithms. This cost is exponential in the proof length, but constant for each problem since it is independent from the inputs. Of course, this constant is ridiculously huge.

<comment><USER5> Funny thing is, you can offload most of this to compile time, which is what Isabelle is doing, but then you miss out on guaranteed optimal runtime. Also the proof database may not be complete anyway.

</comment></comment></comment></comment></comment><comment><USER6> Given the head of a linked list, how do you determine if it loops? eg, an l-shaped list is easy to determine - you simply process each element in the list until you find one without a subsequent element. But what if it's a 9-shaped linked list? You'll never run out of elements, so the best you could seem to do would be to store a reference to each element and check against all references to see if you've found a duplicate.

There's a way to do it in O(1) space, though.

If you start off two runners in the list, and each "step" move one twice and the other only once, if there's a loop they will eventually run into each other and be processing the same element. Simple, elegant, and nothing I'd have ever thought of. :)

<comment><USER7> I like my solution better:

The list node contains a pointer and some data, most likely another pointer, or a primitive type, or a struct of primitive types. Which means, that on all modern systems, a list node is aligned to at least 16 bits, much more likely 32 bits. That means that the pointer to the node always has the last bit set to zero. So:

        bool containsCycle(node_t *root)
        {
            node_t *p = root;
            bool ret = false;
            if (!root) return false; // Empty list

            while (p->next && !ret)
            {
                if ((uintptr_t)p->next & 1)
                {
                    ret = true;
                    break;
                }
                node_t *q = p->next;
                p->next = (uintptr_t)p->next | 1;
                p = q;
            }

            // Reset all pointers
            p = root;
            while (p->next && ((uintptr_t)p->next & 1))
            {
                p->next = (uintptr_t)p->next & ~1;
                p = p->next;
            }
            return ret;
        }

:)

<comment><USER8> Hacky, trashes CPU cache, the code itself is on a sloppy side and, most importantly, it lacks the elegance of the original solution.

So I beg to differ, it's not really "better" by any metric.

<comment><USER7> It was tongue-in-cheek (see the smiley face), your critiques are all spot on, but there is one thing where it is objectively better:

Tortoise and hare can only detect that a cycle exists. This hack will tell you exactly which node the cycle starts on. That means that if you want to e.g. repair a list, you can just cut that last link and set it to either null or root. Granted, this wasn't the original problem.

<comment><USER9> Tortoise and hare can actually tell you which node the cycle starts on.

      1 -> 2 -> 3 -> 4 -> 5 -> 6
                ^              |
                |______________|

      Step:       0 1 2 3 4
      Tortoise:   1 2 3 4 5
      Hare:       1 3 5 3 5 <- pointers reference same node, cycle exists

Then create another tortoise pointer at the head, iterate until both tortoises point to the same node.

      Step:       0 1 2
      Tortoise:   5 6 3
      Tortoise2:  1 2 3 <-cycle starts at 3

</comment></comment></comment></comment></comment><comment><USER10> 1\. Lempel-Ziv compression algorithms (both LZ77 and LZ78). They are practical, even if one code their basic versions will get good compression ratio. Moreover, they opened the whole big chapter of data compression (LZW, LZSS and more). 2\. The algorithm behind rsync. Nice one. 3\. Jarvis algorithm for finding convex hull. 4\. Speaking of data structures I like xor-linked list, it's neat.

[1] [https://en.wikipedia.org/wiki/LZ77_and_LZ78](https://en.wikipedia.org/wiki/LZ77_and_LZ78) [2] [https://en.wikipedia.org/wiki/Rsync#Algorithm](https://en.wikipedia.org/wiki/Rsync#Algorithm) [3] [https://en.wikipedia.org/wiki/Gift_wrapping_algorithm](https://en.wikipedia.org/wiki/Gift_wrapping_algorithm) [4] [https://en.wikipedia.org/wiki/XOR_linked_list](https://en.wikipedia.org/wiki/XOR_linked_list)

<comment><USER11> > 2\. The algorithm behind rsync.

Do you mean the rolling checksum part?

<comment><USER10> All parts, I like how the simple parts were composed to built pretty complicated algorithm.

<comment><USER12> Yeah, I assume majewsky is wondering if you mean just the rolling checksum part because that's the most complex part. Rsync, as a whole, is certainly one of my favorites and the algorithm(s) it uses are some of the ones I most often call explicitly.

</comment></comment></comment></comment><comment><USER13> I feel I have to mention the algorithm for matching with mismatches which I published in my thesis ([http://www.daemonology.net/papers/thesis.pdf](http://www.daemonology.net/papers/thesis.pdf)), simply because it gave me a legitimate opportunity to use the phrase "Fourier Transform of the FreeBSD kernel".

</comment><comment><USER14> As basic as it is, and completely uninventive, I've always loved Dijkstra's algorithm.

It was probably the algorithm that cemented my love of computer science, it's such an elegant solution to a problem and so simple once you understand it.

<comment><USER15> Why "uninventive?"

<comment><USER16> I believe GP meant that picking Dijkstra's is an uninventive answer to the question of a favorite algorithm, since it's very well-known.

<comment><USER15> Ah that makes sense.

</comment></comment></comment></comment><comment><USER17> The burrows-wheeler transform is pretty interesting [https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transf...](https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transform). It's behind the bzip compression format.

<comment> psi-squared This is related to my current favourite algorithm: Because the BWT is closely related to the suffix tree of the original string, there's an algorithm to search for a substring of length 'm' in a BWT-ed string of length 'n' in O(m log n) time!

The one downside is that you have to pre-process the string, which takes O(n) time and between 5n and 9n space depending on exactly how you do it. But after that, you can do as many searches as you want practically "for free".

There's a paper outlining the various algorithms available here: (PDF) [http://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2...](http://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2002/hons_0205.pdf)

</comment></comment><comment><USER18> I have never seen anything more elegant than Disjoint Set Datastructure [https://en.wikipedia.org/wiki/Disjoint- set_data_structure](https://en.wikipedia.org/wiki/Disjoint-set_data_structure)

<comment><USER19> +1. I was in love with union data structure as well when I get to know about them. And always used to feel good when I used to solve any algo problem with it.

</comment></comment><comment><USER20> Bloom filters: [https://en.wikipedia.org/wiki/Bloom_filter](https://en.wikipedia.org/wiki/Bloom_filter)

<comment><USER21> Agreed. Bloom filters are amazingly useful for checking membership in a set while taking much less space than a database or hash table. They achieve this by being crazily "probabilistic", sacrificing a small amount of accuracy for speed and compactness. Still, this sort of broken, degenerate hash table has found a ton of uses in everything from spell checkers to distributed content networks.

</comment></comment><comment><USER22> Metropolis-Hastings:

[https://en.wikipedia.org/wiki/Metropolis%E2%80%93Hastings_al...](https://en.wikipedia.org/wiki/Metropolis%E2%80%93Hastings_algorithm)

[http://michaeljflynn.net/2015/06/01/my-favorite-algorithm- me...](http://michaeljflynn.net/2015/06/01/my-favorite-algorithm-metropolis- hastings/)

<comment><USER23> This is possibly my favorite as well. MCMC in general is pretty magical.

</comment></comment><comment><USER24> ROAM: Real-time Optimally Adapting Meshes [https://graphics.llnl.gov/ROAM/roam.pdf](https://graphics.llnl.gov/ROAM/roam.pdf)

Whitted's recursive ray tracing algorithm [https://en.wikipedia.org/wiki/Ray_tracing_(graphics)#Recursi...](https://en.wikipedia.org/wiki/Ray_tracing_\(graphics\)#Recursive_ray_tracing_algorithm)

PageRank

</comment><comment><USER25> Here's a rather surprising one. There's an algorithm to generate a uniform random integer in the range 1..n with a KNOWN factorization. That means the algorithm is like a regular random number generator except it will also tell you how to factor it! Magic? yes! This always surprises people and i love results like this.

Search for the paper by Adam Kalai on how to generate random factorized integers easily. It uses log^2 n primality tests an average. The result is originally by Eric Bach who managed it using only log n primality tests but using a more complex algorithm.

</comment><comment><USER26> Diffie-Hellman

One of those algorithms where you go "Shit so obvious and also so completely genius that I could never have thought of it"

Also, the internet as we know it would not work without it

</comment><comment><USER27> Ukkonen's algorithm for linear time suffix tree construction. Knuth called it 'the algorithm of 1973'.

</comment><comment><USER28> Token Bucket. Very lightweight way to implement rate limiting.

PHP implementation: [https://github.com/bandwidth-throttle/token- bucket](https://github.com/bandwidth-throttle/token-bucket)

<comment><USER29> Didn't knew it by that name:

[http://nginx.org/en/docs/http/ngx_http_limit_req_module.html](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html)

</comment></comment><comment><USER3> Linear Hybrid Cellular Automata: [https://pdfs.semanticscholar.org/7835/161f253ab117a3666fa8e7...](https://pdfs.semanticscholar.org/7835/161f253ab117a3666fa8e74e008782a789cd.pdf)

Parallelizable and efficient method for producing high quality pseudo random bits.

Designed to achieve maximal period (with 500 bit state the period of repetition is one less than 2^500).

Can be run backwards or forwards. Running it backwards undoes running it forwards and reproduces the pseudo random bits in reverse order.

</comment><comment><USER30> Tomasulo's algorithm: [https://en.wikipedia.org/wiki/Tomasulo_algorithm](https://en.wikipedia.org/wiki/Tomasulo_algorithm)

A modified version of it is used in most CPU register out-of-order execution

</comment><comment><USER31> Great question. Without a doubt, my favourite is the Burrows-Wheeler transform (as used by bzip2)

[https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transf...](https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transform)

[https://www.youtube.com/watch?v=4n7NPk5lwbI](https://www.youtube.com/watch?v=4n7NPk5lwbI)

</comment><comment><USER32> When I first read of HashLife I had the most extraordinarily vivid dreams of breaking all complexity barriers just by finding the right memoization scheme: [http://www.drdobbs.com/jvm/an-algorithm-for-compressing- spac...](http://www.drdobbs.com/jvm/an-algorithm-for-compressing-space- and-t/184406478)

</comment><comment><USER33> R* tree for indexing spatial data [1]. Also, if you enjoy spatial data structures, you can't go wrong with Samet's[2] _ The Design and Analysis of Spatial Data Structures_ and Applications of Spatial Data Structures_.

1: [https://en.wikipedia.org/wiki/R*_tree](https://en.wikipedia.org/wiki/R*_tree)

2: [https://www.cs.umd.edu/~hjs/design.html](https://www.cs.umd.edu/~hjs/design.html)

</comment><comment><USER34> Randomized algorithms, specifically Monte Carlo (probably because it was the first I explored), have fascinated me since I met them. The idea of having a very simple/efficient method to look for a solution, instead of a very complicated one, and still be able to have a near optimal solution is amazing.

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

</comment><comment><USER35> I really like Fleury's algorithm[0] - I used it to generate more efficient paths to draw on a canvas, for the purpose of displaying simple wireframe models. It may not be the most efficient, but I really like the simplicity.

[0] [http://www.geeksforgeeks.org/fleurys-algorithm-for- printing-...](http://www.geeksforgeeks.org/fleurys-algorithm-for-printing- eulerian-path/)

</comment><comment><USER25> There are a lot of great answers here. Let me add another one I really love: the Knuth Morris Pratt algorithm for string matching. There are many features about it I especially love. First of all it takes a simple idea (when a mismatch occurs it's often possible to shift the pattern a lot more than just by one position) and takes it to it's logical conclusion (that of defining and computing the so called border lengths of prefixes). Second, the analysis of the precomputation step (the border lengths) is tricky, and amortised, but plainly obvious once you see it.

It shows the importance of making a good definition and thinking differently (for the run time analysis I thought for a while and failed to come up with an argument why it runs in linear time, but once you see it differently it's obvious :))

I only recently had the chance to understand this algorithm. Here's a little (annotated) gist I made after understanding it: [https://gist.github.com/quantumelixir/3c410dd4a0afe0f2514e0f...](https://gist.github.com/quantumelixir/3c410dd4a0afe0f2514e0f554cddab05)

</comment><comment><USER36> Number Theoretic Transform aka Discrete Fourier Transform.

The algorithms for computing it are beautiful and have enabled much of the technology we see around us today.

<comment><USER37> This. FFT is crazy awesome.

</comment></comment><comment><USER38> I really like majority voting algorithm to get majority number in array which appears more then half of the elements, Its the most simplest and elegant algorithm i have studied

[http://www.geeksforgeeks.org/majority- element/](http://www.geeksforgeeks.org/majority-element/)

<comment><USER39> I'm surprised how the solution doesn't have the hashmap implementation of it, which gives out o(n) and is much more simple. But the algorithm is interesting though!

<comment><USER38> @sameera_sy thats the point hash map solution will take O(n) space complexity as well consider a situation where you need memory efficient solution

</comment></comment></comment><comment><USER40> Ford-Fulkerson algorithm for finding the maximum flow across a graph: [https://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorit...](https://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm)

The algorithm itself is interesting enough, but when applied to bipartite graphs, you can solve some tough problems very efficiently. For instance, one of my favorites is how Santa could possibly match a million kids with a million different gifts in order to maximize happiness. It turns out you structure the problem as a bipartite graph with nodes on one side for gifts and children on the other, and Ford-Fulkerson can guarantee the best matching in polynomial time (no small feat, given how many possible combinations there are!)

</comment><comment><USER41> I've been diving into a bunch of the newer (computational) optimization algorithms but the old school ones that they teach in school is still extremely interesting and relevant to me. I've always been a huge fan of "Combinatorial optimization" [1]. I saw someone else mention this but the simplex algorithm is awesome as well! [2]

[1] [https://en.wikipedia.org/wiki/Combinatorial_optimization](https://en.wikipedia.org/wiki/Combinatorial_optimization) [2] [http://gizmodo.com/5934150/the-algorithm-that-controls- your-...](http://gizmodo.com/5934150/the-algorithm-that-controls-your-life)

</comment><comment><USER42> Also, fft gets an obligatory mention

<comment><USER22> Cooley-Tukey algorithm.

<comment><USER42> Split-Radix

</comment></comment></comment><comment><USER21> Cuckoo Hashing: [http://www.lkozma.net/cuckoo_hashing_visualization/](http://www.lkozma.net/cuckoo_hashing_visualization/)

"An elegant method for resolving collisions in hash tables... It has the rare distinction of being easy to implement and efficient both in theory and practice."

It does an amazing job of packing values into N hash tables so there's very little dead space but lookups are very fast.

</comment><comment><USER43> [https://en.wikipedia.org/wiki/Extendible_hashing](https://en.wikipedia.org/wiki/Extendible_hashing).

</comment><comment><USER44> 1\. Karatsuba algorithm for fast multiplication. 2\. Heap's algorithm for generating permutations.

mostly because they clearly demo the power of human brain.

<comment><USER25> I recently made the observation that Karatsuba found his multiplication algorithm roughly ten years ahead of Strassen's matrix multiplication alg. And given that the crucial idea (using identities to save one multiplication) is already beautifully captured in Karatsuba's it takes away a little from the latter :)

</comment></comment><comment><USER45> My favorite is the Hindley-Milner type system algorithm: [https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system#Towards_an_algorithm)

It is what is used in ML based languages to infer type and apparently Haskell uses it a bit too

</comment><comment><USER15> Knuth's DLX algorithm. Uses what he calls dancing links to perform backtracking in basically constant space with a clever trick on doubly linked lists.

He recently updated his implementation. Is very fun to read his notes on his implementation. In particular, he discusses things he had wrong.

If you like poor JavaScript implementations, I can post mine again.

</comment><comment><USER46> Simplex. If you can transform your NP hard optimization problem into an LP, simplex can often work like magic.

<comment><USER47> If you can transform your NP hard optimization problem into an LP, you have proven P = NP because LPs can be solved in polynomial time.

That said, many combinatorial optimization problems that look quite similar to NP hard problems have very nice and efficient LP formulations, and for many NP hard problems, _integer_ programming-based methods (which in the end mostly solve LP relaxations) are among the best algorithms. For example, planar TSP can be solved for tens or even hundreds of thousands of nodes using the LP relaxation, branch, and cut tool set.

Modern LP solvers don't just use the Simplex method though. I'm very partial to the Simplex method myself, but in practice, Interior Point Methods are often used.

<comment><USER25> Adding to what you say, OP might have meant the use of LP solvers in branch and bound type algorithms to solve hard problems after recasting them as integer programs.

</comment></comment></comment><comment><USER48> Kalman filter!

</comment><comment><USER49> It looks like SWIM scales better than Raft. Are there well-known production systems that use it?

<comment><USER50> SWIM is in no way an alternative to Raft, and vice-versa. SWIM is a membership algorithm, Raft is a consensus algorithm. They are often used together. (a SWIM alternative is plain Gossip and a Raft alternative is Paxos)

</comment></comment><comment><USER51> Cheney's two finger garbage collector with forwarding pointers. Still beating every other GC out there by factor of 10, if you can afford 2x memory

</comment><comment><USER23> Contrastive divergence for RBMs. Incredibly simple, but absolutely beautiful how it modifies the energy surface. Also, just in general a cool use of Gibbs sampling.

</comment><comment><USER52> Convolutional neural nets and backprop. That stuff is magical.

I also was fascinated as shit when I learnt about minimax and alpha beta search.

Game theory and neural nets have always fascinated me.

</comment><comment><USER53> HyperLogLog

<comment><USER25> I also like the moral predecessor of this algorithm (Morris counting algo I think it's called) which solves the simpler problem of estimating the number of elements in a stream with loglog space. Curiously it appears as an exercise in CLRS.

</comment></comment><comment><USER54> I find the DC3/skew algorithm for linear-time suffix array construction mindblowingly clever!

</comment><comment><USER55> AIXI

<comment><USER5> Nonexistent.

</comment></comment><comment><USER56> I generally appreciate divide and conquer algorithms of any type

</comment><comment><USER57> Lamport's bakery algorithm is pretty neat.

</comment><comment><USER58> Someone already mentioned Tomosulo.

RSA.

</comment><comment><USER42> Backpropagation

</comment><comment> chaotic-good Sequitur</comment>


Ask HN: Common or Preferred Stock (joining a startup for 25% equity)? - <AUTHOR>

If I was going to join a company for 25% equity, what would be the benefits of going with preferred stock over common stock, or vice versa? Are there legal advantages or disadvantages to either, tax advantages, ability to be screwed over in the future, etc.? <comment> o0-0o 1\. You want shares that don't dilute. 2\. You want to make sure you are a partner on the C-Corp/S-Corp. 3\. You don't want to setup an LLC. 4\. You want to make sure you are getting a K1 each year. 5\. You want this all in writing before accepting your offer for salary, etc. 6\. Your title should be Founder / <whatever you do>

<comment><AUTHOR> Thanks so much. Would you mind expand on #2 A bit more, why an LLC is not preferable? The company in question is an S Corp, but IIRC it is also an LLC if that's possible.

Pertaining #1, how can I ensure my shares are non-dilutable?

</comment></comment><comment><USER2> From that equity share, I'm guessing you are a founder. You won't be offered preferred stock, that will likely be reserved for future investors.

</comment><comment><USER3> Founders and employees get common stock. Investors will get preferred stock. This is not something you'd get to choose for joining</comment>


Show HN: TensorFlow for AWS on a Real GPU - <AUTHOR> https://github.com/pavlovml/tensorflow/blob/master/README.md <comment><USER2> Honestly, there are enough issues with TensorFlow right now due to CUDA 3.0 that using it with AWS is highly problematic. I appreciate the author's attempt, but there's no way the five lines of code he changed to allow CUDA 3.0 has fixed any of the issues found in [1], such as NaNs during training, equally slow training on a g2.2xlarge as a g2.8xlarge, etc ...

If you're just interested in playing around, then your laptop will do fine - TensorFlow is happy with just about any hardware you throw at it. Hell, your modern Android phone will run it =]

If you're interested in a more involved experiment, develop and debug your task locally on your laptop. By the time you're ready for large scale training, there might be a stable and battle tested AMI such that people are no longer reporting issues in [1] about it.

Again, if you're interested, follow the CUDA 3.0 issue on GitHub[1] - this is nowhere near a solved problem and will only cause headaches if you're using it for education.

[1]: [https://github.com/tensorflow/tensorflow/issues/25](https://github.com/tensorflow/tensorflow/issues/25)

<comment><AUTHOR> Thanks for the feedback! I've added a note to the README that support is still experimental. I'll be tracking the issue and updating the repo + AMI as it develops. Will be compiling with the latest commit (72a5a60) for configurable CUDA Compute support soon.

<comment><USER3> Thanks, would be good to have multiple sources of verification that HEAD now supports this natively without issues like unexpected NaNs.

[https://github.com/tensorflow/tensorflow/issues/25#issuecomm...](https://github.com/tensorflow/tensorflow/issues/25#issuecomment-156256071) is one verification :)

<comment><AUTHOR> Updated to the latest commit, works for me! :)

</comment></comment></comment></comment><comment><USER4> Top link points to a non-existent AMI so this "recipe" \-- like almost every "here's how to ..." recipe on GitHub that gets posted on HN -- doesn't work. I swear, it's like 100% fail on these types of posts.

Also this "real GPU" is explicitly called out in the Google docs as unsupported.

<comment><USER5> I tried with the Oregon region and it failed. I changed to the N. California region and it worked. (No comment about the GPU though.)

<comment><USER4> Github recipes are the "works on my machine!" of the new millennium. Just like pecking in programs from computer magazines in the 1980s, only better!

I like the ones that are hardcoded to a specific name in a home directory best. Especially when it doesn't match the github name of the "creator."</comment></comment></comment>


Ask HN: Making a static site generator. How to handle GitHub-style links? - <AUTHOR> Am writing Yet Another Static Site Generator. In Github Pages, internal links must go to .md files, not .html. So for example page1.md links to page2.md like this: [Visit page 2](page2.md).
This seems a little odd to me, so mine expects the actual HMTL link [Visit page 2](page2.html). However, that breaks compatibility with GitHub pages and will probably annoy people. I'm thinking the better behavior would be to for [Visit page 2](page2.md) to look for the .md file at site generation time and if it doesn't exist, generate a link to an .HTML file instead.
Mind is a little fuzzy lately so I'd like feedback on this idea. <comment><USER2> i like the sound of how its done on GitHub alright... if you ever change your URL structure, you dont have to rewrite all your pages to point at the new location, plus if you did, you could write redirects in there too... it would also allow for checking of links; if you link to newpgae.md, not newpage.md, it should throw a "compile" error... what language are you writing this in?

<comment><AUTHOR> Thanks for the feedback. Don't understand what file extension has with URL structure? It's relative no matter what, or am I missing something?

Writing it in Go.

<comment><USER2> not necessarily the extension that would link to the url, but the file might be, in my case with Hugo, in posts/2020-01-01-title.md. but when that gets built, it will be in posts/2020/01/01/title.html... you could, in theory, not have the date in the file name, and just use the date from the md file, which then will still generate that way...

<comment><AUTHOR> I think that's due to the way Hugo converts the date portion of the source file, which has a whole bunch of rules about weighting and things, but I'm not smart enough to understand how they work.</comment></comment></comment></comment>


Tankster: HTML5 Multiplayer Game - <AUTHOR> http://www.tankster.net/

<comment><USER2> mostly slow and locking up. The fact that I'm disappointed means it's off to a great start!</comment>


Ask HN: Recommend a code host? - <AUTHOR>

I'm looking for a place to upload my Free Software projects. I'm nearly up against Google Code's project limit and I'm not a fan of GitHub. Hosts outside US reach strongly preferred but not essential. Hosts that support git strongly preferred but not essential. <comment><USER2> [http://gitorious.org/](http://gitorious.org/)

I don't know where they are located (I'm assuming U.S. or U.S. servers) and I don't know what their limits are, but there are a lot of open source projects using them for hosting.

</comment><comment><USER3> I use [https://www.assembla.com/home](https://www.assembla.com/home) for open source projects</comment>