PRISM kills the cloud - <AUTHOR> http://blogs.computerworld.com/cloud-storage/22305/why-prism-kills-cloud

<comment><USER2> " _In order for these services to become the main foundation of the Post-PC future, users are utterly justified in demanding binding commitments to security from service providers._ "

Which, due to the total secrecy of the government's process (e.g. National Security Letters), they cannot provide.

We could, of course, watch ever word we put on the cloud, including the supposed private stuff, but I'd rather not do that for a large class of things (submissions to forums like this are an obvious exception, I am after all submitting it for the whole world to see as it wishes).

The cloud can still be useful for encrypted backup, that's what I do with rsync.net to avoid loss by disaster, and it saved e.g. my email when the Joplin, Mo tornado hit 2 years ago. But put my spreadsheets on the cloud? The one tracking the blood test results of a relative's anemia (fortunately, it looks like it was a "hit and run" virus). No, I think not.

<comment><USER3> Just out of curiosity, what is it about your relative's blood test that you don't want the NSA to know about? Especially since the results are already on a network at the hospital (or testing lab), and the NSA can get it directly from there anyway via an NSL.

I've often wondered about why medical records are such a sensitive topic to most people. The only things I can think of is either the insurance company will find out and raise your rates (they find out anyway, as they pay your bills), or the condition one suffers is due to something they did that was embarrassing (or similar).

<comment><USER4> > Just out of curiosity, what is it about your relative's blood test that you > don't want the NSA to know about?

This is the wrong question. The _right_ question is, "what is it about your relative's blood test that you don't want the NSA, or anybody else in the government, or any contractor or lobbyist the government is persuaded to share this data with, now or at any point in the future, essentially in perpetuity, to know about?"

And the answer is, of course, "I don't know".

I don't know if Obamacare will die an ugly death and insurance companies will successfully lobby for absolutely anything establishing genetic prior conditions.

I don't know if, in 50 years, the government will decide to, say, demonize Jews and go hunting for Ashkenazi DNA indicators in their databases and go after the families they can find with them.

I don't know if a genetic predisposition to homosexuality, haemophaelia, a positive test for AIDs or herpes or ginger hair will one day be used against me or my descendants by some future mob.

And that's why privacy is important.

<comment><USER5> I agree with the point you are making. In the spirit of agreement, I would suggest that the right question is "what is it about your relative's blood test that you specifically want to bring to the attention of the NSA, government, contractors, and lobbyists."

Privacy should be the default state and expectation, and disclosure should be by exception when necessary, for exactly the reasons outlined in your post. The argument that privacy only matters if you have something to hide conceals a number of assumptions, and misses the fact that one doesn't know what one might one day wish one had hidden.

</comment></comment></comment></comment><comment><USER6> It does not kills the cloud. It just makes some of the flaws that were obvious to the tech people since day one known to the wider audience.

<comment><USER7> The wider audience being the people who make the purchasing decisions...

I work in the financial sector in Europe and this HAS pretty much killed the cloud simply due to the uncertainty. People are in meetings _right now_ working out how to move all their stuff off AWS etc rapidly before the people who pay the bills land it on the doorstep.

In fact it's killed datacenters that are US subsidiaries such as Rackspace as well. I had a conversation with a guy at Rackspace this morning and they actually recommended going to a local company over themselves.

The shit has literally hit the fan this time.

<comment><USER8> >People are in meetings right now working out how to move all their stuff

I'm wondering why they didn't consider this scenario in the first place. That lets me question their expertise very much. Aren't they professionally paranoid enough? Then why do they run critical infrastructure?

<comment><USER7> They were informed. After all it's our job to inform them of the facts and let them make a decision, usually based on a tradeoff of risk perception (note not real risk rating) and cost.

Now risk is perceived to be higher, cost is a little more flexible.

Businesses don't necessarily operate in the best interests of their clients. The shareholders come first, then the clients and anything which takes from the bottom line is going to end up a risk tradeoff.

I post anonymously as I'm risk averse and don't necessarily agree with how businesses operate in this respect.

</comment></comment></comment></comment><comment><USER9> Eric Schmidt's quote

"If you have something that you don't want anyone to know maybe you shouldn't be doing it in the first place"

becomes

"If you have something that you don't want anyone to know maybe you shouldn't put in on the cloud in the first place"

<comment><USER10> If you don't want it known, don't use the phone.

<comment><USER9> Any two-bit street hustler knows that, which is why billions of dollars on wholesale phone monitoring is such a waste.

<comment><USER11> You'd be surprised at the level of intimate details discussed by street hustlers on prepaid mobile phones. I'm not sure if prepaid throwaway ipv6 addresses would be viable, but it may not hurt to start thinking in this direction.

<comment><USER9> When I get an bright idea that will make me a lot of money and bring me fame, I'm sure I'll figure out a way to keep it secret when I communicate it to a few trusted advisors.

</comment></comment></comment></comment></comment><comment><USER12> I always figured the better solution would be to have a cloud-in-your-pocket. You can carry your own data with you and sync backups to a site you personally control.

Phones certainly have the capability to do the job of a personal server (of course you may not want it to be an actual phone considering the latest snooping news). A mechanism to use any nearby desktop or laptop as a client would enable most of what you need without any requirement for an untrusted remote storage provider.

<comment><USER13> Another (or complementing) implementation of that idea is the FreedomBox:

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

<comment><USER12> Certainly complimenting. By definition communication requires more than one person accessing information.

I know what I'd like to see in this area, but I don't have a good idea how to implement it. FreedomBox might be heading towards that implementation.

The idea I'm kicking around in my head for comms is something where I'd want a distributed data store (possibly just a file system) with access controls to enable requests such as "UserA acting on behalf of UserB would like to read data at /path/to/data". Where UserA might be twitter and UserB might be StephenFry. UserB can control what UserA can see and manipulate. UserA can do things that UserB cannot (such as acting on behalf of UserC)

</comment></comment></comment><comment><USER14> My (pessimistic) prediction is that _nothing_ will change because of this, at least not in the US.

In the consumer space, there's little that this awareness will do to illustrate the risk to those who didn't see it before. It's only when _abuse_ of a program like PRISM comes to light in a _big_ way will the average consumer demand change or change their habits.

In the corporate space, most already are very wary of putting trade secrets or confidential data into cloud services and those who aren't won't be any more so, I would argue, until they see real impact from improper use/disclosure.

Outside of the US? I would hope there'd be more outrage and want for non-US options, but, in truth, most other governments want to be doing the same thing, I'd bet, so just where is the safe harbor is a question many will be asking, I'd bet.

</comment><comment><USER15> _It is unlikely too many people want their privacy curtailed in exchange for convenience_

You'd be surprised just how many people do exactly that, and I don't mean the average citizen either. I wonder how many of us in HN have turned on Google Now ?

</comment><comment><USER16> This is a convoluted buzzword mess.

He's talking about the consumer buzzword 'cloud', as in iCloud, eCloud, store your pics in the "cloud", not the IT buzzword "cloud computing", with things like virtualization, EC2, AWS, S3. Thanks for that, marketing assholes.

But I want to know. Whats the difference now, in light of all the spying, between storing your stuff encrypted on S3, or using EC2, and colocating hardware somewhere? Are we worried about back doors into the virtual machines and S3 buckets, or are they just going to watch the traffic in and out, just like they can do anyway if you colocated, or even put all the crap in your basement?

<comment><USER17> No, he's not.

I'm in the business / IT end of things, as well as the consumer side.

Businesses. And non-profits (many with services/clients in ... less than democratic regions, not even counting the United States). And governments. All care about integrity, access, and, more than anything else: security.

With colocated hardware, you've got control over the physical devices, there's no intermediating virtualization layer (unless you've installed it yourself), and you can control aspects such as data and disk encryption (though in truth: this is fraught even on hardware you _do_ own, and is also possible in many hosted environments). You also control the physical wiring and cabling within your cabinet, cage, and/or datacenter.

Most importantly: you controls _where_ your data are. When I use a colo, my data live on specific pieces of hardware in specific locations I've specifically designated. And if it's seized, you'll likely know about it (you may not be happy, but you'll know). When you host in the cloud, access becomes ... distributed.

Both have their security issues, but the envelope is _much_ larger in the cloud.

<comment><USER16> Yes he is. He's an apple blogger. He doesn't know virtualization from his own ass.

I once interviewed with a company that was letting users store data 'in the cloud'. They were promoting the the job as something to do with 'cloud computing'. I asked if they used AWS. He replied they had a few colocated servers.

I'm asking, from a spy point of view, if there's a difference between a virtualized server and a physical one, if in fact all they are doing is watching network traffic.

</comment></comment></comment><comment><USER18> On the other hand, external hd business is now booming.

</comment><comment><USER19> We should resurrect this 2009 Stallman prophecy. [https://news.ycombinator.com/item?id=318440](https://news.ycombinator.com/item?id=318440)

</comment><comment><USER20> I often jokingly tell a specific friend that I'll murder him (he says the same to me)... it wouldn't be clear if you read the e-mail correspondences that we're joking. It _would_ be clear if you saw us in real life joking, laughing... but you don't have that context, you don't know the history of my relationship with him, we're both practitioners of an absurdist brand of humour (think adultswim's Tim&Eric humour). Compound all of this with the fact that I'm brown (Asian descendant) and that a running brand of jokes is about terrorism ('yeah so we have AQ training camps in our basement') -- and, I'm sure we're setting off a good amount of triggers.

Here is what is unnerving to me: considering the high-capacity storage capabilities of these three-letter agencies, it's highly likely that a lot of our data has already _been_ copied... it's little use disabling our fb/goog accounts, it's little use deleting everything en masse now.

Anyway, my takeaway from all of this is that 1) I have to stop making these jokes, even in private conversations, and 2) communicate more clearly in my e-mails, so that if it's being read by someone with no context, it does not invoke any suspicions to wrongdoing of any sort. I am extremely annoyed that I have to start doing this, but I will.

<comment><USER21> The first step has been taken: [http://thinkprogress.org/justice/2013/06/07/2120141/why- the-...](http://thinkprogress.org/justice/2013/06/07/2120141/why-the-nsas- secret-online-surveillance-should-scare-you/)

Quote: "A citizenry that's constantly on guard for secret, unaccountable surveillance is one that's constantly being remade along the lines the state would prefer. Foucault illustrated this point by reference to a hypothetical prison called the Panopticon. Designed by utilitarian philosopher Jeremy Bentham, the Panopticon is a prison where all cells can be seen from a central tower shielded such that the guards can see out but the prisoners can't see in. The prisoners in the Panopticon could thus never know whether they were being surveilled, meaning that they have to, if they want to avoid running the risk of severe punishment, assume that they were being watched at all times. Thus, the Panopticon functioned as an effective tool of social control even when it wasn't being staffed by a single guard."

<comment><USER22> >> The prisoners in the Panopticon could thus never know whether they were being surveilled, meaning that they have to, if they want to avoid running the risk of severe punishment, assume that they were being watched at all times.

That's what it feels like to me working in open cube areas.

</comment></comment></comment><comment><USER23> if another hit to the US economy is what it takes to make things change ...

</comment><comment><USER24> I am thinking about closing my Crashplan and several of cloud accounts. Am I overreacting? What about Lastpass? Lastpass now seems too risky.

<comment><USER25> The crypto on your online backup and password syncing services should be both strong and entirely client-side. All they should be able to provide to an attacker is useless cyphertext. If not, you probably shouldn't have been using said services in the first place.

</comment></comment><comment><USER26> This is why you use open source software.

</comment><comment><USER27> US based password/identity management is now dead.

<comment><USER28> Hold on, they never give direct access to the passwords.

<comment><USER27> We would not know, they can not even acknowledge the gag order legally. This is the beginning of the end for US based technology companies.

<comment><USER28> Forgot <sarcasm> tag.

I agree that this double speak from US cloud tech companies and the government is putting US cloud vendors into peril. But seriously, the US cloud might be like the dollar. It's not perfect, but it is a known refuge.

There is at least some amount of oversight, however weak, if you have US customers - I would assume that all foreign rivals are actual targets.

Who said it's better to be an American ashamed of our foreign policy than to be a victim of it?

<comment><USER27> I would be salivating at this if I run China. A chance to replicate the entire knowledge economy, the same way that was done to US manufacturing.

<comment><USER2> Hello? Everything here goes N times over for the PRC.

Anyone here feel their government is more trustworthy than the US's???

<comment><USER29> I can't stop the local government from looking at my data if it wants to. I can stop the US government from looking at it. Wich is more trustworth isn't a relevant question.

<comment><USER30> > I can't stop the local government from looking at my data if it wants to. I > can stop the US government from looking at it.

I doubt that.

US government intelligence gathering _within_ the US is being reported on right now and controversial _because_ their are strong expectations and at least some legal restrictions that suggest that such surveillance is _exceptional_.

But if you think keeping your data overseas means that the _foreign intelligence_ gathering apparatus of the US government _isn 't_ going to get at it, then you may have failed to think things through clearly.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> A classic over reaction by a member of the press. However it may lead to certain SLA revisions. If the NSA comes calling I will notify you before giving them access. Or people choosing to host outside the USA.

<comment><USER32> if you have an sla like that, the service provider has to choose between violating the SLA by not telling the customer, or violating the warrant/court order which compels them to not inform you.</comment></comment>


Show HN: Blink – an iphone app for creating memes out of screenshots - <AUTHOR> http://blink.am <comment><USER2> First I was like, "How does it detech screenshots in other apps?"

Then i was like, ahh, it must look at the images added to the Photoroll :) It should be added somewhere on their website like FAQ.

I need to try it out!

<comment><AUTHOR> For those who are curious, we explain a bit more how it works here: [http://blink.am/help](http://blink.am/help)

<comment><USER2> That gives me a 502 sadly.

<comment><AUTHOR> Try again now, we had a temporary maintenance outage.

</comment></comment></comment></comment><comment><USER3> I don't have a problem with it myself, but I suspect using Location Services to allow for background processing is against Apple's App Store guidelines.

</comment><comment><USER4> How is that different from one shot?

<comment><AUTHOR> Oneshot is great for sharing a snippet of an article via Twitter. Blink is aimed at everything else, providing a way to share content from any app anywhere.

</comment></comment><comment><USER5> So basically Skitch for mobile?

<comment><AUTHOR> Kindoff...except it doesn't have the standard tools (arrows, text color customization) that you'd expect from a tool for PM's like Skitch. What you will find other features that help preserve context (hotlink blink & selective highlight/crop) and make sharing ad-hoc screenshots faster (blink instant) and more fun (scalable emojis).</comment></comment>


Elon Musk Says Google Deepmind's Go Victory Is a 10-Year Jump for A.I - <AUTHOR> https://www.inverse.com/article/12620-elon-musk-says-google-deepmind-s-go-victory-is-a-10-year-jump-for-a-i <comment><USER2> AI is good for rules based systems, but most of the worlds problems that need to be solved don't have rules in the same way a board game does.

Sure it's cool that a computer beat a human at a board game, but thats like celebrating a penguin being better at fishing than a person with bare hands.</comment>


MESH: SSO via SSH public key authentication - <AUTHOR> http://people.nas.nasa.gov/~kolano/papers/sacmat07.pdf

<comment><USER2> Project Page: <http://ti.arc.nasa.gov/opensource/projects/mesh/>

"Mesh is a secure, lightweight grid middleware that is based on the addition of a single sign-on capability to the built-in public key authentication mechanism of SSH using system call interposition."

</comment><comment><USER3> That sound pretty awesome actually. I'm surprised ssh isn't used more often to create things like this. Could be a big help in the virtual organization world of research.</comment>


Bifocals.js - asynchronous, nested view rendering - <AUTHOR> http://bifocalsjs.com/

<comment><USER2> Are there any examples of using this as the renderer for an Express application?

<comment><AUTHOR> Posting for the author of Bifocals:

I'm not very familiar with express, but I just looked at the template system to see what I can do.

I don't think you would get a ton of benefit out of this library with express as is.

An express website would get the most benefit out of this library if they had a system so that the route your http server picked could also manually call routes which would add additional content to the page.

For example, something like the following would allow bifocals to work its magic.

        app.get(/^\/user\/(\d+)$/, function (req, res) {
            res.render('user.html', {user: req.params[0]});
        });

        app.get(/^\/home$/, function(req, res){
            app.perform_request('/user/1234', res.child('content',  'user_widget.html');
            res.render('home.html');
        });

If I accessed /user/1234 in my browser, I would see a user's profile page. If I accessed /home in my browser, I would see the home page and a user widget containing user 1234's data.

Both times you see a user, they have executed the same route function, but you can change the templates and inject them into other templates asynchronously. You can do this unlimited times within one route, and to an unlimited depth (depending on your system resources of course)

Bifocals also offers some of it's own features, multiple rendering systems, http header+status code handling, and more.

</comment></comment><comment><USER3> I don't get it. Is the library for progressively loading html content? So that you can use multiple threads to handle one request and therefore get higher performance? From the examples given, it is hard to see why regular template rendering wouldn't work just as well.

<comment><AUTHOR> Posting for the author of Bifocals:

It's definitely not the easiest library to explain.

This does not explicitly use threads, but it will take advantage of any asynchronous systems you want to use.

<http://bifocalsjs.com/#why-do-i-need-this-library> is a more concrete example that might shed some light on the issue.

This allows you to run two database queries in parallel, and render immediately when the longest of the two queries is complete.

Most standard template systems have one large pool of data they provide to a template. You have to locate this data before you render a template, even if it is used by a partial.

Most partial systems simply combine two templates into a bigger template, that takes this large pool of data.

What bifocals does is give each partial it's own, isolated pool of data and render them separately and asynchronously from each other. This allows you to delay each partials rendering until it is ready, without waiting for the other partials to be ready.

Each function that creates Bifocals objects then can be isolated from the rest, with one sole responsibility. Render this template.

Your object might have parent objects, it might have children. Your function doesn't care, it just pumps data into a Bifocals object and marks it as ready. Bifocals then tracks your whole hierarchy, and sends it to the user when every last section is ready.

</comment></comment><comment><USER4> Seems very interesting, I'll surely give it a try in my next personal project. Small suggestion to the author: Please add syntax highlighting in the example.. it makes a huge difference when reading code online! Thanks

<comment><USER5> I messed with a couple of highlighters and they all had issues highlighting everything correctly.

I might turn them all into gists, but I am going to talk with the rainbow.js author before I do.

Hopefully this will be fixed soon!

<comment><USER6> Since you're using Github pages, just use Markdown fenced code blocks, e.g.

        ```javascript
        function() { .. }
        ```

</comment></comment></comment><comment><USER5> Hey all, I'm having issues replying to comments so I've been emailing jasonmoo to get everything lined up properly.

Hope I can answer any questions you have.

Thanks, Aaron

</comment><comment><USER7> I am new to NodeJS, but this seems like a pretty useful tool - I plan to check it out.

</comment><comment><USER8> Mixing tabs and spaces. :S

(Otherwise pretty cool)

<comment><USER5> Ugh where the hell does that happen?

My linter usually yells at me, I'll dig around and fix those up.</comment></comment>


Complexity Has to Live Somewhere - <AUTHOR> https://ferd.ca/complexity-has-to-live-somewhere.html <comment><USER2> Oh this, I've known for years. I learned it early, as a new OS engineer at Convergent Technologies. There was a nasty part of the kernel, where programmable timers lived, that was a large part of the change history of the OS. Looking at it, I saw folks had been thrashing for some time, to get all the issues resolved. But it was a '10 lbs of feathers in a 5 lb box' kind of thing. One change would cause another issue, or regress a bug.

So I took 2 days, made a chart of every path and pattern of events (restarting a timer _from a timer callback_ ; having another time interval expire _while processing the previous_ ; restarting while processing _and_ another interval expires; restarted timer expires _before completing previous expiration_ and on and on). Then writing exhaustive code to deal with every case. Then running every degenerate case in test code until it survived for hours.

It never had to be addressed again. But it _did have to be addressed_. So many folks are unwilling to face the music with complexity.

<comment><USER3> Regarding being 'unwilling to face the music', is it possible that you were only able to perform this refactor due to all the 'thrashing' that came before you? Is it possible that the majority of commits leading up to your refactor were dealing with unforeseen complexities and addressing real bug fixes that you were able to conveniently take in and synthesize all at once?

Refactoring too soon, before understanding the entire system (and all the possible changes/additions/issues that could arise) is probably worse (time- wise) than thrashing for a bit.

<comment><USER2> As I recall (and it was a long time ago) the history gave some insight into the complexity. But nobody had exhaustively enumerated all the cases. I remember the chart had more conditions that had ever been addressed.

<comment><USER4> You'd be surprised how few people look through commit history while bug fixing.

There's a steady stream of people who don't understand why 'breaking' the commit history is a problem, and assume you have some sort of untreated OCD if you bother to even care.

<comment><USER5> 100%. Apparently relatively few have experienced the power of `git bisect run`. More than once I've had to explain that no, this isn't just some idiosyncratic aesthetic preference, there's a reason your version control tooling is designed the way it is.

<comment><USER6> Higher level tooling doesn't prioritize this. AFAIK neither Gitlab nor Github have an actual option in their CI implementations for "test _every_ commit before allowing merge". And both of those are everywhere.

There's also nothing out there which enforces practice - i.e. new code must be covered by some amount of test case (I'll settle for "it is executed in some way as part of build").

These are all things that _could_ be done, but they're not priorities to the big players evidently, and good luck to me trying to get any organization to commit to putting that tooling in or running something custom that does it.

<comment><USER7> Why do we want to test every commit? Does it matter if you broke something if you end up fixing it later?

<comment><USER6> In the context of git bisect, it's vital. You can't go looking for bugs commit by commit with no requirement that any individual commit is actually buildable or functional.

In my own projects I'm as guilty of this as anyone, because it's nigh impossible to get the tools to actually do this (which has a massive effect on the culture which builds up around them).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Complexity is often frivolously created during specification. If the true consequences of complexity (wherever it may live) were understood, we'd simplify things a lot. But they want that next button, they want ancient emails be searchable instead of having them archived, and they have no idea that their wish leads to new servers installed in a data center, new bugs introduced, and development time lost at for each new release.

There are also ways to design things better (or worse) with regards how they handle complexity. Reuse UI, patterns, workflows and languages. Keep things consistent, make things discoverable.

Point is, the slogan "Complexity has to live somewhere" could also be used as an excuse to do sloppy work. Then again, this keeps us all employed.

<comment><USER9> > Complexity is often frivolously created during specification. If the true > consequences of complexity (wherever it may live) were understood, we'd > simplify things a lot. But they want that next button, they want ancient > emails be searchable instead of having them archived, and they have no idea > that their wish leads to new servers installed in a data center, new bugs > introduced, and development time lost at for each new release.

I think features are definitely worth servers being installed in a data center, and most people coming up with product requirements are fine with the _monetary_ costs.

Features leading to bugs and wasted development time... that's where the point of the article lives. There are ways to build software that can more easily accommodate changes.

However, it's more common that developers try to _hide_ the complexity of features behind abstractions that hinder more than they help. And _that 's_ what results in breakages and lost time.

</comment></comment><comment><USER10> I think the conversation has shifted slightly this decade to avoiding _incidental_ (accidental) complexity (I didn't realize Fred Brooks popularized the term!), which I wish the author would address.

Otherwise this essay is spot on when it comes to essential conplexity.

Incidentally, the question of "where complexity lives" is one of the focal points of "A Philosophy of Software Design," which comes highly recommended if you're trying to come up with your strategy for managing complexity from first principles.

<comment><AUTHOR> I think the most contentious part of the post is that I just simply assert that people are an inherent part of software. You often avoid the incidental complexity in code by indirectly shifting it to the people working the software.

Their mental models and their understanding of everything is not fungible, but is still real and often what lets us shift the complexity outside of the software.

The teachings of disciplines like resilience engineering and models like naturalistic decision making is that this tacit knowledge and expertise can be surfaced, trained, and given the right environment to grow and gain effectiveness. It expresses itself in the active adaptation of organizations.

But as long as you look at the software as a system of its own that is independent from the people who use, write, and maintain it, it looks like the complexity just vanishes if it's not in the code.

<comment><USER11> _> You often avoid the incidental complexity in code by indirectly shifting it to the people working the software._

Yes, this is Larry Wall's waterbed theory: [https://en.wikipedia.org/wiki/Waterbed_theory](https://en.wikipedia.org/wiki/Waterbed_theory)

I do think it's important to distinguish accidental and essential complexity. Some complexity is inherent and if you think you've eliminated it, all you have really done is made it someone else's problem.

But there is also a lot of complexity that is simply unnecessary and can be eliminated entirely with effort. Humans make mistakes and some of those mistakes end up in code. Software that does something that _no one_ ever intended can be simplified by having that behavior removed.

</comment></comment></comment><comment><USER12> Complexity is like energy, it cannot be created or destroyed, it is a fundamental property of any process or thing.

However, complexity can be managed. Humans do this using abstraction as a tool. We divide the complex problem up into a sequence of several simpler states, and we find it easier to understand the simpler problems _along with_ the sequence within which they lie.

Good software uses this same approach to reduce complex issues to a manageable process. A good tool makes the simple things easy and the complex thing possible, the design of the tool reflects the effort and work that the designer out in to u the problem they're trying to solve, and to produce something that helps guide others along that self-same path of understanding, without them having to put in the same level of effort; it establishes the golden path through the marshes and bogs of difficulties that the problem domain throws up.

"Embracing complexity" is a measure of last resort, IMHO. It means the tool developer could not analyze the problem and come up with a good solution; it means "here, you figure it out"; it means giving up on one of the fundamental reasons for the tools existence.

 _Sometimes_ , embracing complexity and the ensuing struggle that this necessitates is simply what you have to do, but not often. Maybe, _maybe_ this is one of those times, but I always start off with a critical eye when someone tells me that a complicated thing is "the only way it can be done". Colour me sceptical.

<comment><USER13> Complexity can easily be manufactured. Comparing it to something as fundamental as energy is pure bollocks.

Heres an amusing and simple example of manufactured complexity: [https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

<comment><USER14> If only there were some scientific discipline that studied complexity and proved that _problems_ possess some essential, minimal, complexity below which no implementation can go...

If anyone proved such a result, I'm sure they would be awarded a prize of some kind.

<comment><USER15> Well, there are many complexities. People here are talking about the Programming Complexity (of which one measure is Cyclomatic Complexity) of a textual program vs. the Time/Space complexity of the same program. There is the weakly-related concept of the Kolmogorov complexity of a string.

It's obvious that the time/space complexity of a program can stay fixed while you arbitrarily raise the programming complexity of a program by arbitrarily raising the number of branches that are rarely taken, an action that won't affect the asymptotic time complexity of a thing.

And sure, you can talk about the Kolmogorov complexity of a string of computer code, but the minimal string representation of that code is unlikely to be one that a programmer would describe as simple. Even minimizing the string that would behave as that of the original program is usually non-desirable.

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

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

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

<comment><USER14> Pick _any_ of those. Given a problem, there is a minimal complexity to the programs that solve it. You can always _raise_ the complexity, but not reduce it.

<comment><USER15> I'm confused by your response to ninjapenguin[0]. Were you agreeing with him or disagreeing or something else? I interpreted your response to be disagreement. I feel that your original style of phrasing "If only x etc. etc." is not easy to understand. I'm having a hard time placing your subsequent comments in context of that original response.

0: [https://news.ycombinator.com/item?id=23042891](https://news.ycombinator.com/item?id=23042891)

<comment><USER14> I was disagreeing with the statement that "Comparing [complexity] to something as fundamental as energy is pure bollocks." There is, in fact, a discipline that studies complexity -- computer science, and, in particular the field of complexity theory. Complexity was, in fact, found to be fundamental and "irreducible". Two people, Hartmanis and Stearns, did, in fact, discover that through a comparison to physics [1] in 1965, and for that discovery -- that led to the creation of complexity theory -- they won the Turing Award in 1993.

[1]: [https://dl.acm.org/doi/10.1145/1283920.1283949](https://dl.acm.org/doi/10.1145/1283920.1283949)

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I wonder if the author has read _Out of the Tar Pit_ [1]¹. See, in particular, section 6.

Essentially, the author is, I think, arguing about what the paper calls "Essential complexity", complexity inherent to the problem one is trying to solve. And with that, I agree.

I think the author should acknowledge accidental complexity (or provide some argument as to why that must live somewhere), and I think a lot of comments here on HN are pointing out the fact that accidental complexity exists, and _doesn 't_ have to live somewhere. But my guess is that that's not what the author is saying, and that the author is only arguing about essential complexity.

[1]: [https://github.com/papers-we-love/papers-we- love/blob/master...](https://github.com/papers-we-love/papers-we- love/blob/master/design/out-of-the-tar-pit.pdf)

¹I personally found this paper somewhat mixed. The definitions of complexity are what make it worth reading. Its conclusion of "functional programming languages will fix all the woes" I think is not practical.

<comment><USER17> Yes, there's definitely a kind of complexity that _doesn't_ stem from the problem domain, and it can often be eliminated.

Stuff like over-abstracting, insane default values, duplicated state that needs to be synchronized (e.g in React components) or just overly-repetitive code, for example.

<comment><USER18> > Yes, there's definitely a kind of complexity that _doesn't_ stem from the > problem domain, and it can often be eliminated.

Yes, it can be eliminated, but only to some extent. Programming languages add a baseline of complexity by themselves that _can't_ be removed: programming languages are not infinitely flexible so there will always be problem characteristics (invariants, data structures, etc) that will not be easily expressible. Those are new sources of complexity.

Think how Java simplifies manual memory management when compared with C or C++. Or how the Rust borrow-checker provably prevents a whole class of bugs. But these are all tradeoffs, both Java and Rust are ill-suited to express other problems.

</comment></comment></comment><comment><USER19> "The trap is insidious in software architecture. When we adopt something like microservices, we try to make it so that each service is individually simple. But unless this simplicity is so constraining that your actual application inherits it and is forced into simplicity, it still has to go somewhere. If it's not in the individual microservices, then where is it?"

The failing of this point is that much of what we call complexity is disorganization. Certainly, there is a fundamental level of logic in any desired system that can not be willed away with cute patterns, but to consider all complexity of an existing system to be necessary is a fallacy. Dividing systems into problem domains does not inherently reduce the total complexity of a system. It probably usually adds to it. But organizing systems this way can drastically reduce the scope of complexity into manageable pieces so that mere mortals can work on it with out having to hold the entire system in their mind at one time.

It's like saying that you can't make a garage full of junk any less complicated, because no matter how you arrange it, it will still contain all the same junk. In fact, organizing all the junk into manageable storage can make it much easier to understand, work with, sort through, clean, and identify items that may be unnecessary.

<comment><USER20> Indeed, but we need to differentiate between the inherent complexity of the problem (which can't be mitigated, but only shifted around as the article points out), and the incidental complexity added when we create the solution.

The inherent complexity can be taken on by the solution (and the inherent complexity may be hidden behind a simple interface, or it may be introduced in the interface, but that's another problem), or it gets removed of the problem domain, and then needs to be dealt with by the user.

There's no correct answer; half the problem is defining the appropriate problem domain, and even then there are only better or worse solutions. The incidental complexity of the system comes purely down to the implementation, which often comes down to how well the problem domain is defined in the first place.

<comment><USER19> Yes. That's exactly what I'm saying. Although, from the way I read the article, it doesn't seem to acknowledge the possibility for significant overhead in a chosen implementation. Sounds like they're saying, no matter what you choose, it's all the same. Don't even try.

</comment></comment></comment><comment><USER21> This is a great essay.

Along the same lines, there's a great quote from many years ago that I unfortunately can't find the exact text of, but it goes like this (paraphrasing):

"Most Microsoft Word users only use 5% of its features."

"So why don't we get rid of the other 95%, since it's so bloated and complex?"

"Because each user uses a different 5%."

<comment><USER22> It was Joel Spolsky - [https://www.joelonsoftware.com/2001/03/23/strategy- letter-iv...](https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv- bloatware-and-the-8020-myth/)

It was 80/20, but the sentiment holds.

</comment></comment><comment><USER23> As every discussion about bullshit jobs or frontend frameworks, or hardware abstraction VMs (recently, WASM) will easily show, we are swimming in accidental complexity. And even when it's not obvious, every general advance on science or technology is fundamentally the removal of some complexity that everybody just adapted to like if it was essential.

So, no, it doesn't have to live somewhere. It can be created and destroyed, this happens every day. Probably some of it can not be destroyed, but nobody knows what part so any article about it will be useless.

</comment><comment><USER24> I don't disagree with the message, but I'm kinda ambivalent about putting the focus on it like that.

> We try to get rid of the complexity, control it, and seek simplicity.

Well, not really enough. Complexity is a beast that takes many years to understand, and that's when you are really trying. Many devs don't. And companies even less. So while it's true some complexity is unavoidable, I think we still have a long way to go in being aware of it first. We write software once, and that's not a proper strategy to manage complexity. Anyone who has looked into computers from top to bottom knows we have tons of problems with complexity that we really haven't solved properly, and that bleed into day to day development in the ugliest ways.

My particular take when I don't have the massive amount of time required to properly deal with complexity is write something like this: "hey, this is very complex. please don't touch it. if you have to, we have this much headroom. if you need to go beyond that, please rewrite this entirely / find a better way. if the code doesn't bite you immediately I will".

</comment><comment><USER25> I completely agree, and even commented the same essential idea a couple years ago here:

[https://news.ycombinator.com/item?id=18774619](https://news.ycombinator.com/item?id=18774619)

One of my highest upvoted comments with 161 upvotes.

But I've come to another idea too. Part of all this complexity is dealing with change. We could simplify things if some aspects of our software hit a final point where only security updates were published after that. Imagine a programming language that was specified and actually _finished_ without the constant roll of changing patterns and practices. Or a web framework. Or a database. Intentionally designed to be robust and secure from the first day then intentionally set to minimal patches for bugs and security fixes.

Part of the issue though is that things keep changing. New characters are added to unicode, new timezones emerge or existing ones change. It's a hard problem to crack.

<comment><USER26> If you designed a mainframe in the 70's, it didn't change. And so we are still running mainframes from the 70's today for critical infrastructure, government, financial, and educational work.

<comment><USER27> I don't know if that's really true. While the software that runs on the mainframe is the same, mainframe hardware has advanced considerably.

</comment></comment></comment><comment><USER28> This is especially evident for those who used golang for non-trivial projects. Because the language has very poor support for abstractions and higher level constructs, you end up with much more verbose, brittle code that's harder to modify and read. IMO, the language designers, by optimizing for a language that's relatively easy to pick up* have pushed the complexity onto the programmer.

* Any language has its paradigms that need to be learned, and golang is no different. Just because you can learn the syntax in a couple of sittings does not mean you know how to use the language in an effective matter. Something I see many people not bring up.

<comment><USER29> That is not my experience from using Go for nearly 10 years at all. Go actually has significantly removed the complexity of writing asynchronous and concurrent programs and has pushed it to its own runtime. At this moment in time, as a language nerd, there are few languages that I know of that compete with Go in the balance it strikes between performance and complexity.

<comment><USER28> "goroutines" is probably the only thing that golang has going for it. But today with async/await in languages like Rust and C#, C++ getting a coroutine implementation, and Java getting fibers, golang is no longer special in anyway in this domain, while it still carries the baggage of a non-expressive verbose language, and performing worse than the aforementioned.

<comment><USER29> Go is special in that it is _significantly_ simpler than all of these languages, while having a large overlapping domain of operation with each. I'm yet to see a single real-life money-making program written in any of the languages you cited that is as easily readable as a Go program.

</comment></comment></comment></comment><comment><USER22> This has been something living in my head for a long time, but the largest problem is that the complexity needs to live in different places for different sizes of problem. For example, for simple systems, the build tool that forces a limit to complexity might be the right one, because the exceptions will be small and well-understood. For a large system, you may have a team that is dedicated to the build tool itself, and as such the compromises are different.

If you are lucky, you have someone who is able to analyze the entire system, can identify all of the stakeholders, and can drive consensus when the change in abstractions is necessary, and has the budget to do it.

The danger is that people pick the solution for a large solution first because "we will need this someday" rather than waiting for the accidental complexity to build, knowing that the rework necessary to move to an intermediate system is less expensive than the cost of delay in getting the simple solution out first.

My dream is that we can build incremental complexity systems that could support simple solutions quickly and highly complex solutions eventually. The problem is that these are hard to build. :)

</comment><comment><USER30> The author seems to be starting with the premise that complexity is _necessary_.

I'm not sure I'd agree. Some complexity exists because the effort to simplify was too great. Either cost or skill prevented the refactor. As the saying goes, "sorry this letter is so long, I didn't have time to make it shorter."

I've repeatedly found that the first iteration of a solution tends to be more complex. One culprit is that sufficient abstractions were either not recognized or not implemented. Put those abstractions in, and you simplify the system.

So that refactoring step after an initial solution is created is crucial and unfortunately often just not done.

<comment><USER31> It depends on the kind of work. Systems integrations are often complex for uncontrollable reasons. That one legacy system only speaks ASN.1, not JSON; the three vendor systems have different semantics for a fundamental concept (vendor, order, shipment); failure modes are under-documented, so defensive programming is needed; etc.

If we accept that the integration itself is necessary, then the complexity necessarily comes along with it. Not to mention all the complexity generated by the client base: I'm paying for this system, it's mine, so make it do X, even if you think X is too complicated/impossible/etc.

</comment></comment><comment><USER32> I know. Lets move it all that annoying complexity to yaml/json/XML config files!

Now look at this app I can write in 30 lines of code with this framework! Oh and 500 lines of yaml across 2 dozen files but look the "code" is so sleek and sexy.

Joking aside I think he could have at least mentioned the difference between required complexity and unneeded complexity. Ironically it seems to spawn from attempts to reduce the first type of required complexity in a lot of cases.

</comment><comment><USER33> The title is catchy and it's not _exactly_ wrong. There's an element of truth to it. And yet, 99% of the times I hear it, it's as an excuse for crap, not some fundamental truth.

Dirt has to live somewhere, too. That's a good motto for a garbage company, but if you hear a chef saying it in the kitchen while preparing your meal, you might be worried.

<comment><USER34> Yep. Most of the "complexity" that is justified by mantras like this is not _necessary_ complexity (like the inherent baseline complexity in solving a certain problem space) but cruft/enterprise/poor coding style that winds up suffocating a project. That kind of complexity should be torn out with disregard for the notion that it's somehow necessary.

<comment><USER35> I would differentiate between intrinsic complexity of a problem and artifical complexity of a solution.

Certain knots can be solved without changing the topology! They would just add artifical complexity.

Also, some truths can have both very simple and very involved proofs. They are a perfect example how just the right approach can reduce much complexity. Just formulating the problem in a different way can already reduce much artifical complexity.

</comment></comment></comment><comment><USER36> It is not about simplicity versus complexity. It is about creating simple abstractions that successfully hide the contained complexity.

When I want to search for a string within some data, I don't want to have to think about the algorithm it uses (naive, Boyer–Moore [1], etc.). I just want to know that somebody cared about it and that it will work great.

Bad abstractions, on the other hand, make you think about the underlying details that you have to be aware of. For one layer that might not be too bad, but the more you build on top of such things, the more fragile the whole construct becomes.

[1] [https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string- sea...](https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string- search_algorithm)

<comment><USER37> This is missing their point. If you use a simple abstraction, you won't be able to address all of the complexity of the underlying task. You'll be sacrificing at some point, either by leaving performance on the table or by ignoring an edge case and having it come back to bite you later. "it will work great" can only go so far without cooperation from the user, and then the complexity starts creeping back in.

<comment><USER36> I just read the text a 2nd time and I disagree with you.

The point of the text is, that you have to define where to put the complexity:

      If you are lucky, it lives in well-defined places.

Otherwise, it will be everywhere (obviously bad):

      With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads.

My point, on the other hand, is that you should focus on good abstractions, which is just one more step into the direction of defining 'where the complexity should live'.

When defining the abstraction you focus on the practical use-cases so that it is as simple as possible but not simpler. The main task here is to find the right focus. In doubt, it might be better to use multiple different abstractions (e.g. if there are two distinct use-cases).

The goal is to find a construct where everything looks simple from the outside because the complexity is hidden by the abstraction.

<comment><USER37> I agree that abstraction is a useful tool in tackling complexity, but in my experience it is often the _only_ tool people reach for, which can lead to a continuous rat chase of refactoring after refactoring, because somehow the ugly can never quite be fully hidden.

This is exactly what the text talks about: shuffling of the complexity around, trying to hide it, and the end result can often be that you just don't know where it ended up. Personally I think a lot of this is due to the way software engineering ideas like "don't repeat yourself" or "design patterns" can attain an almost cult-like following, and people just blindly apply transformations instead of deeply looking at what the actual problem is.

As others mentioned in the rest of this thread, complexity must be addressed, and only from a perspective of understanding what your problem is, where the traps are, what all of its complexities are, can you then come up with abstractions that will be any good.

</comment></comment></comment></comment><comment><USER26> It could be that your complexity is necessary, like a small widget that just has an enormous amount of variety that it has to constantly account for. Or it could be that you designed one giant widget made of 10 widgets, and a re- design could simplify how you think about and build it.

Simplicity is the art of taking complex things and stripping them down to their essential nature. Simple things can be complex, but no more complex than they have to be.

With that said, this piece talks a lot about frameworks and tools and patterns, and I really hope people don't think that's the right way to think about architecture. Abstractions do not make things simpler, they make them abstract.

</comment><comment><USER38> While I agree with the message about essential complexity, I disagree that all complexity is essential. In fact, I think it let's us off the hook far too easily to just claim all complexity is essential. It's _easy_ to invent complexity, in fact it's the default. I'd go as far as to say that about 50% of the complexity in software is non-essential. And in terms of what to address, it's a bit like paying off debt - just like you should always pay your credit card first, always start by eliminating the non-essential complexity.

</comment><comment><USER39> Paraphrasing the "Fundamental theorem of software engineering", _Every problem can be solved with enough levels of indirection._ Every level of indirection adds complexity, so the question should be: is the additional level worth it?

I am fully on board with the overall sentiment of the article that there is some irreducible complexity that one cannot avoid. Often it comes straight from the business domain or entity the code is modelling, and then, sure, you cannot make it any easier, otherwise you are not solving the problem and users will be unhappy.

However, then the author goes too far: > Accidental complexity is just essential complexity that shows its age.

You can absolutely add heaps of unnecessary complexity; in fact, this is almost surely what you will get by attempting to cover every possible future use case and evolution scenario, or to cater to every minor aesthetic concern (e.g., "I need to be able to replace my cloud provider / DB / message queue / user notification medium / etc by changing just one line!").

It takes humility to admit that getting the balance "right" from the start is difficult, and often the only way to improve is to accept some badness now and revisit the decision later with more information.

The quote however seems to be saying that we (as software engineers) always get it right, just later things change and our choice does not appear right anymore. This mindset is counterproductive, as admitting flaws is the first step to improve.

</comment><comment><USER40> Certainly you can make things more complex than they need to be (for your given use case). That is self-evident for most engineers.

Doesn't that hold that the inverse must be true? In some cases, you must be able to remove complexity from the equation, without introducing it somewhere else.

I agree with the spirit of the post, but I think it's eliding some of the complexity involved in identifying essential complexity.

</comment><comment><USER41> I find there are some concepts used to qualify complexity and data-model fit in information theory and machine learning that can also be used to think about product-market fit or software-domain fit.

I tried to describe them here. I'm not sure I did a good job:

[https://email@example.com/product-market- crossfit-c09b...](https://email@example.com/product-market- crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667)

The gist:

Low resolution fit: The product vaguely and simply fits its market or domain.

High resolution fit: The product is complex and is tightly tailored to the market or domain.

Overfit: The product is so tightly tailored to some users that it only fits a small part of the market.

Underfit: The product is so generic that it's missing important features and corner cases.

And then another qualifier 'crossfit' which is a bit harder to grasp, inspired by cross-entropy, that has to do with whether the design language, which can be seen in some ways as 'encoding' the problem, fits the domain or market well.

</comment><comment><USER42> Kolmogorov complexity is uncomputable. What that means in this case is that we may never be 100% sure if we have eliminated all unnecessary complexity in our programs; if we have expressed things in the simplest way. The complexity may have to live somewhere or... or there may be a simple underlying principle we have just not seen yet.

</comment><comment><USER43> There is still a huge difference in the amount of complexity in a solution and the amount of complexity in the computer system implementing that solution. In extremely simple cases, such as implementing a mathematical formula, the solution (in the form of words or an equation) and the implementation (actual code) could be on the same size order - there is virtually no accidental complexity. For business solutions, like a shopping web site, the difference could be a factor of 10,000 or more. But that's almost all accidental complexity, because of how organically the web and most programming languages have grown to handle cultural concepts like language, visual flow, authentication, encryption, cross-platform compatibility and so on.

</comment><comment><USER44> I think that things only become less complex when it becomes old and reliable. Even if the internals of the thing are a fucking mess. For example, Linux, in its entirety is a complex fucking beast for its maintainers.

Yet for other people it's a simple as fuck thing that accomplishes things for them and lets them move forward with getting shit done.

So really, it's how you look at it.

The human body is so freaking complex, it is entirely possible we'll never even understand how half of it works. Yet from another point of view we easily hire a bunch of humans to do tasks (programming, making food, yard work, etc..). And even though we don't know how the body works, we have a simple understanding of how that body can accomplish those tasks, which is enough to move forward.

</comment><comment><USER45> I think "complexity has to live somewhere" is just the definition of essential complexity. "Accidental complexity is just essential complexity showing its age" makes no sense to me: accidental complexity is often the result of ignoring essential complexity (or using inadequate tools). One often finds that edge cases can be naturally handled by principled approaches that capture the essential complexity of a system (see: Paxos). The alternative is a naive, simplistic approach that ignores essential complexity and quickly accumulates accidental complexity in the form of workarounds for newly-discovered edge cases. In other words, most software systems.

</comment><comment><USER46> I think I understand the point the author is trying to make, but I think they end up accidentally making too strong of a claim.

 _Sometimes_ there is /essential complexity/, but it is far from always. I think the line of thinking espoused by the author leads to less simplification and encourages a "well, the complexity has to live somewhere, so why bother?" type of approach. However, reducing complexity is often possible, and it usually comes before the implementation stage. Reducing complexity sometimes means solving a different problem.

</comment><comment><USER47> Of course it does. It lives in your frameworks and libraries. It lives in your container classes and threading routines. It lives in that bit of code at the core of your business rules that people are scared of.

If you write anything, even "hello, world", complexity lives somewhere! Just the complexity of the print function path all the way to the hardware would baffle some.

</comment><comment><USER48> Very interesting. I'm happy I read it. I think that seeking simplicity in code for me is often trying to find the most simple and straightforward way to write the code so that I can understand it. This usually boils down to good naming, and good encapsulation of tackling specific problems into specific (ideally well named) places.

</comment><comment><USER49> It is nice that we recognize that there is certain amount of necessary complexity and the skill involved is complexity management. But it is a pity that we don't recognize that 1. we can create extra complexity that often wraps around necessary complexity; 2. There is such thing that is called scope.

</comment><comment><USER50> If we think of model, view, controller, much of the complexity seems to be when these dimensions leak into each other.

Keeping them orthogonal seems the first step in the process of trading the problem for a smaller problem.

As TFA notes, there is a lower limit to how much complexity can be squeezed out of a system.

</comment><comment><USER51> The strategy recommended at the end with the "embrace it, give it the place it deserves" feels like the "eating your shadow" of design. It's also what I've been trying to approximate most of the time, and I appreciate the representation of it here.

</comment><comment><USER52> This is one of the best titles I've seen this year. Reminds me of G.G.Márquez, who told how much he sweated over the first sentence. I haven't read the post yet, but I feel the discussion has already started.

</comment><comment><USER53> C++ : Make the language complex, not the code.

Go : Make the language simple, make achieving a simple thing complex.

C : The machine is complex, be careful what you do if you overflow into the inner workings.

</comment><comment><USER54> Some complexity cannot be avoided, but that doesn't mean that complexity is a constant and removing it in one place necessarily means that it has to go somewhere else.

</comment><comment><USER55> The good thing is you can manage inevitable complexity with the proper balance of abstraction, tooling, and documentation.

</comment><comment><USER56> I agree. Often good architecture amounts to finding the prettiest place to put the ugly.

</comment><comment><USER57> The fact that complexity has to exist is obvious.

The real question of design, especially the design and organization of computer programs, is _where_ that complexity lives, and how do you organize that complexity so that it doesn't introduce _extra_ complexity.

Usually the way we handle this is through layers, with the initial layers being simple, the middle layers being complex and the top layers being simple again. There's no theory about why this is better, it is just usually how it's done and it seems to work when we can pull it off.

The bottom layers are your primitives and axioms. Simple building blocks. This is where designers want to create a most minimal and simple set of tools that can help facilitate unlimited complexity at the upper layers (Think a minimal set of language primitives that allow for Turing completeness)

The middle layers are your theorems. Different permutations and compositions of your axioms to implement things like business logic or whatever logic you want. This is where good designers should try to stuff as much complexity into as possible.

The Top and final layer is the interface. Something that is built to directly access the middle layer while providing an interface that is simple and more understandable from the perspective of a user. This is probably the least theoretical aspect of the stack as you have to factor in things like art and human psychology into how you build an interface.

A good example of this will be your phone. The primitives are assembly language instructions, RISC. The middle layer is all the code that facilitates programming and applications and the interface layer is the touch screen.

Note that you don't have to look at it from a birds eye view from CPU instructions all the way to touch screen. You can zoom in and look at just a web stack: Java on the backend all the way up to react on the front end.

By zooming in you will see systems that violate the design principle I describe. Java as a primitive has become incredibly bloated and so has React and the javascript tool chain. There are several reasons for why this happens: Lack of planning, optimization requirements inevitably violate design principles, lack of knowledge, lack of central direction and more.

Either way, always remember that the ideal design that most people should strive for is complexity sandwiched by simplicity at the primitive layer and the interface layer. This goes for most things within computer programming and outside of it, like your car.

<comment><USER21> > _The fact that complexity has to exist is obvious._

I can't tell you how many engineers and designers I've worked with for whom it is _not_ obvious.

Unfortunately, the lesson that complexity has to exist seemingly needs to be re-taught constantly.

A lot of people really truly believe that a beautiful, minimalist, elegant product is always the best solution -- and that the users needing it to do other/extra things are the ones who are wrong.

<comment><USER57> I'm not really talking about that. I'm saying that it's obvious in the sense that this English sentence has a certain level of complexity... In fact for anything to exist it must have some level of complexity... that much is obvious.

The real question is what to do with complexity. Like you said some people think that complexity should be pushed onto users other people like you and I disagree.

<comment><USER27> If you're building real systems, it is not the case that complexity of the problem is obvious. I've just spent several years in an organization where inherent complexity was discounted by important technical decision makers in the organization.

The result is a mess since the system was not designed to cope with the operational complexity involved.

</comment></comment></comment></comment><comment><USER58> One of the reasons to study category theory is that it holds out promise of a way, mathematically rigorous, to discover and describe the _essential_ complexity of a task or problem.</comment>


Show HN: Quickly navigate to any URL in Chrome with one word - <AUTHOR> https://chrome.google.com/webstore/detail/redirect/ndmlefihodnjkipamdighnjjmiddafai <comment><USER2> This is an interesting idea. Where can I see the source code?

</comment><comment><USER3> This is an interesting idea. Is it open source?

</comment><comment><USER4> This looks pretty cool!</comment>


HP On Palm Acquisition: "Our Intent Is To Double Down On WebOS" - <AUTHOR> http://techcrunch.com/2010/04/28/hp-palm-deal-webos/ <comment><USER2> WebOS is actually pretty nice to develop for, it just needs faster hardware with better battery life. Oh, and a way for developers to make money. It's a little rough that anyone can just shell into their phone and view all of your source code.

<comment><USER3> Is Palm's hardware roughly comparable with average Android and Apple phones? (thus making it the software that's slow and power-hungry, not the hardware?) I've just heard so many people complain that the "everything is web" aspect of it makes it slow, but I don't know whether that's just a scapegoat or if it's really true.

<comment><USER4> The Pre isn't as fast as the top of the line Android phones, but it's no slouch either. It holds its own in most side by side comparisons.

<http://www.youtube.com/watch?v=S7FJj5-7vQI>

</comment></comment></comment><comment><USER5> Maybe we'll finally see a legitimate competitor for the iPad now. All of a sudden, the market just got a little interesting.

</comment><comment><USER6> Good for them! WebOS, as I understand it, is the nicest OS of the bunch from an elegance and openness perspective, so it's good to see it getting a fair shot at market dominance.

Exciting stuff -- let's just hope the additional fragmentation is worth it.

<comment><USER7> The fragmentation is good. The phone market is much healthier than the PC market. A handful of profitable platforms means heavy competition and innovation: a big win for consumers (and developers). I hope HP does well in the phone market, as I wish the peddlers of Android phones and Apple success as well. Plenty of money to spread around in that market.

<comment><USER8> Too much fragmentation sucks. It means none of them will gain critical mass and at least half of them will spend several painful years slowly failing. I don't see how any of these guys (Symbian, WebOS, etc.) hope to overcome Android & WinPhone, at least in the smart phone market. All they can do is harm them by distracting and confusing the market for a few years, equating to consolidation for Apple. I know I am certainly not going to write apps for 5 platforms. I will pick 2 and go with that.

<comment><USER9> The majority of them are Linux-based, and all of them make heavy use of the same web technologies for the primary part of the user experience. The exception is WinMo, but I can't believe that they're going to last long at all with IE7 as their browser of choice. They're going to need to either light a fire under the IE9 team and somehow get feature parity with mobile Webkit, or just throw in the towel and allow one of the other browsers on WinMo.

And as for the suggestion that Apple is going to take over... RIM still has the largest market share in the US. Apple is a niche player, and they always will be because of the premium they charge on their hardware (now further compounded by the restrictions imposed on their hardware.)

<comment><USER10> I've never had a phone with Windows Mobile, but I use to have a PDA woth that OS and I could run both Minimo (Gecko based) and Opera on it.

<comment><USER9> With WinMo 7 all apps must be coded in Silverlight, and there is no native development. This might be okay if they weren't using IE7 as the basis for the WinMo 7 browser.

</comment></comment></comment></comment></comment></comment><comment><USER11> I love my Pre. Great new innovative ui, and excellent browsing experience.

</comment><comment><USER12> The first thing came to my mind reading the headline was:

"What does KFC have anything to do with HP or Palm?"

</comment><comment><USER13> Is using a gambling term to describe a business acquisition supposed to calm shareholder fears/concerns of risk?

Clearly that one didn't go through the normal PR approval process.

<comment><USER14> maybe they think embracing the obvious is the way to go

<comment><USER13> You double down when you expect the odds favour a dealer bust.

I'm not sure how anyone suggesting that Apple, Google and RIM busting shouldn't be feared, if that's what they actually mean.</comment></comment></comment>


Growing up in a city weakens the brain's navigational skills - <AUTHOR> https://www.economist.com/science-and-technology/2020/02/06/growing-up-in-a-city-weakens-the-brains-navigational-skills <comment><USER2> So because I grew up with a Grid pattern in my community I am now less adapt at memorizing non-grid like streets in a video game? "The detrimental effect of city living on navigation.."

Why Detrimental? Why is it bad that I skill I have never needed to use is not developed? I don't juggle well either- have never needed that skill.

I am not sure that the published work provides anything of value other than teaching us that people who use GPS or even live in cities are not used to navigation without a grid of some sort. Which does not honestly seem like much of a surprise.

Also thank you lovely Jeffersonian mapping [http://www.usgennet.org/usa/ok/county/muskogee/cemeteries/ma...](http://www.usgennet.org/usa/ok/county/muskogee/cemeteries/maps/trro.html)</comment>


David's calculating sticks: collection of slide rules - <AUTHOR> http://www.sliderules.nl/

<comment><USER2> I've mailed him about the E-6B flight computer missing in his database and collection. The E-6B is still in production and widely used, not only for pilot training. I'm using it for sailing, and have not yet found any other intuitive modern calculator for drift/vector calculations(1). Smartphones have big problems with sunlight, and with wet fingers. Not to talk about the problem that most smartphones dislike water.

(1) Lets say your boat runs 7 knots, you have a current of 2 knots from 123⁰. What course do you talk to reach a target 321⁰. Those type of calculations are trivial on the backside of an E-6B. And the frontside contains all those practical conversations between imperial, nautical and metric systems, e.g. whats the weight of 10 gallons of fuel in metric tons would be a question that is trivial to answer on the frontside.

</comment><comment><USER3> I didn't see any Keuffel and Esser slide rules listed. They were one of the leading brands back in the day. Here's a link for those who are interested in exploring more slide rules:

[http://www.sphere.bc.ca/test/ke- sliderule.html](http://www.sphere.bc.ca/test/ke-sliderule.html)

</comment><comment><USER4> About a month ago I got an old slide rule from my Grandfather that he'd used in engineering school. It's a little thing, but it's amazing to hold something that was some decades ago the standard tool for certain types of computation. It really puts into perspective just how far we've all come in such a short time.

</comment><comment><USER5> I still have the one I got for high school chemistry.

A bit of trivia: slide rules survived into the 1980s and maybe beyond as "proportion wheels" used by graphic artists to calculate the reductions needed on images. I'm sure that most of these folks had no idea that these were essentially circular slide rules.</comment>


Google Chrome: The Fast Browser With Slow Adoption - <AUTHOR> http://www.pcworld.com/article/181118/google_chrome_the_fast_browser_with_slow_adoption.html

<comment><USER2> I don't think Google's primary goal here is to have the largest market share in the browser market but to be able to drive innovation in the other leading browsers through competition.

Google Chrome drove Firefox (and others) to improve the speed of their javascript engines/interpreters which is hugely beneficial for Google meaning their web apps now run faster across the board.

In my opinion, Google Chrome exists to help Google push other browsers to introduce new features that make their web applications more accessible to everyone else.

<comment><USER3> That's why they have television commercials for chrome?

If they wanted to make the web better, why didn't they just contribute to the Firefox project itself rather than inventing their own browser?

Releasing, yet another browser only complicates things for existing web developers.

<comment><USER4> To be fair to Google, they tried to contribute to Firefox back in the Firefox 1.x timeframe, but they realized that Mozilla is rather dysfunctional open source project. It is incredibly hard to get feature work into Mozilla as an outsider, so they decided to go their own way. In a way they got what they wanted in the end, now with Mozilla copying stuff from Chrome wholesale now that someone else has made them look bad.

The main things holding Chrome back adoption-wise is a stable Mac version, and extension hooks to support popular functionality like AdBlock and Noscript. With those you'll start seeing geeks and tech influencers switch, which will probably start eating at Firefox's market share. It's a testament to the power of Google's brand that it's got as much market share right now as it does, which is mainly at the expense of IE.

<comment><USER5> I am a mac user (primarily) and I find this funny. How is Mac version holding back Chrome in terms of adoption when mac represents roughly 9-10% OS market?

Chrome already supports extensions, Adsweep works on Chrome as an alternative of ABplus. Noscript is used by a very small niche users, I seriously doubt noscript users are holding Chrome back on mass adoption.

I think switching browser is always a difficult choice for non tech savvy users. Personally it was a hard choice for me 4-5 years ago to leave IE for FF, but it was easier for me to make the switch to Chrome after I used it and liked it. I think my view towards a browser changed over the last 4-5 years and I see a "browser" as a tool as opposed to a gateway to the internet. I think most of the early adopters of Chrome are fairly tech savvy users and for chrome to be really mainstream they need to push chrome bundled with new computers (I think they already do that).

Chrome is awesome and it can only get better. I hope Google Chrome OS will be just as good.

<comment><USER4> > How is Mac version holding back Chrome in terms of adoption when mac > represents roughly 9-10% OS market?

Because Mac usage among early adopters and other tech influencers is a much higher percentage, and they're the ones who recommend software to use to the less savvy. That's how Firefox's marketshare got its initial big boost.

> Noscript is used by a very small niche users

Again, Noscript usage incidence is higher among that same market.

> I think most of the early adopters of Chrome are fairly tech savvy users

Most alpha geeks I know (including myself) use Firefox as their primary browser rather than Chrome, mainly because it's not quite there on Mac/Linux, and/or favorite extensions don't exist. Nearly all Chrome users I know are Windows users, and don't care about extensions, and like the perceived speed compared to other browsers. Nearly all alpha geeks I know use Chrome on Windows, when they have to use Windows, which isn't very often.

Get more of those alpha geeks using Chrome as their primary, more recommendations trickle down to their less geeky friends. That's what happened with Firefox, and that's what will happen with Chrome once a stable Mac port and support for the popular extensions show up.

</comment></comment></comment></comment></comment><comment><USER6> 4% market share in a year seems pretty impressive to me. The last major browser to launch, Safari, had about 2% market share two years after its release. Three years after that it was at 6% (depending on where you look). In another year, Chrome will probably have a significant lead on Safari, which will be 7 years old. Never mind Opera.

</comment><comment><USER7> _"To date, Chrome really hasn't had the success that I suspect Google had anticipated for it," said Sheri McLeish, a Forrester analyst._

What sort of comment is that? One could create a quote like that about virtually anything in the world.

The article as a whole seems pretty bad. Looks like the author was looking for a reality to support his thesis...

</comment><comment><USER8> Is the reason people get away with saying "There's no chrome for mac or linux" that chrome doesn't exist on those platforms but chromium does? I've been using chrome (or chromium, whatever) on linux for about 2.5 months and it's great. I use it on my macbook too and it's also really good. So what gives?

<comment><USER9> There's no non-developer release yet, and the browser isn't feature-complete on non-Windows platforms. For example, on Ubuntu I can't open links from other programs with Chrome, and asking it to restore tabs when opening the browser doesn't work.

I'm sure once they make official versions the situation will change, I've been happy having it as my secondary browser on all three platforms despite the hiccups.

<comment><USER10> I'm posting this from Chrome on the Mac. It works well enough to use for daily use. There're still some glitches, but in general I've found it better than Safari or Firefox (both of which I also have installed...web developers need everything).

<comment><USER11> I've found Chrome for Mac pretty stable so far, too - but this is my showstopper.

Any time Calibri is requested in text, it displays like this: <http://u.phoreo.com/jy.png>

The font works fine everywhere else, so I'm not sure what's up. Do you have this problem?

<comment><USER10> The site in your screenshot works fine for me. I can't tell whether that's because it's working or because Calibri's not installed. I'm using Chrome 22.214.171.124 (wtf is up with those version numbers) on a recent (~3 month old) stock Macbook Pro.

</comment></comment></comment></comment></comment><comment><USER12> It's like Silverlight. Initially people were like "oh flash is already on 99% of computers" but failed to realize the fact that 99% (not really, but close enough) of computers come with Windows, and Microsoft controls Windows. Microsoft, when ready, can easily get people to use it.

And with Google, all it has to do is slap that browser on its front page if it _really_ wanted the average user to switch.

Obviously Google chrome still has some kinks, so they won't want the average user to switch just yet (assuming that's even their goal).

</comment><comment><USER13> I am waiting/hoping for NoScript-like functionality...

<comment><USER14> I want AdBlock and Greasemonkey. Once those things work properly on Chrome, I'll switch happily.

(If they already work, and I just missed the news, please tell me.)

<comment><USER11> Ask and ye shall receive -

Here's AdBlock (Adsweep): <http://adsweep.org/>

Here's Greasemonkey (Greasemetal): [http://www.mychromeaddons.com/chrome- addon-greasemetal-greas...](http://www.mychromeaddons.com/chrome-addon- greasemetal-greasemonkey-for-chrome/)

<comment><USER14> The Greasemonkey clone has a lot of people warning of crashes when they installed it, so I think I'll hold off for another month or so. Still, I'm impressed that Chrome is this close. Thanks for the links!

</comment></comment></comment></comment><comment><USER15> I had this wierd thing where I'd flip to Chrome, and it'd draw its screen line by line, like a broken Amiga. I switched to Firefox after that. [I was using Chrome because of wanting to use Google Wave).

</comment><comment><USER16> I don't use Google Chrome because they haven't made an official version for Mac OS X. The current developer version for Mac OS X is very buggy and unreliable.

<comment><USER6> I have to disagree. I've been using it full time for a week and it hasn't crashed yet. It's faster than Safari, and it's open source. It has some UI quirks still, but on the whole it's a great browser.

</comment></comment><comment><USER17> relax. browser market share is about branding and building those takes time.</comment>


For Apple, Pressure Builds Over App Store Fraud - <AUTHOR> http://www.nytimes.com/2012/03/16/technology/pressure-on-apple-builds-over-app-store-fraud.html

<comment><USER2> The thing that gets me is that these fraudulent apps are showing up on the App Store's highest grossing apps list. What's the point of all these App Store rules and the 30% cut if they aren't even going after highly visible offenders?

</comment><comment><USER3> For me, the money quote in the article was "It's a change for Apple, which was once criticized for its micromanaging of the App Store. Now the problem is not too much control, but too little."

</comment><comment><USER4> These problems aren't going to just go away on their own. Apple needs to step up to the plate.

</comment><comment><USER5> Security breaches are no joke.</comment>


Facebook documents seized by MPs investigating privacy breach - <AUTHOR> https://www.bbc.com/news/business-46334810 <comment><USER2> Discussion from yesterday: [https://news.ycombinator.com/item?id=18524434](https://news.ycombinator.com/item?id=18524434)

</comment><comment><USER3> Dupe: [https://www.theguardian.com/technology/2018/nov/24/mps- seize...](https://www.theguardian.com/technology/2018/nov/24/mps-seize-cache- facebook-internal-papers)</comment>


Android 1.6 SDK is here - <AUTHOR> http://android-developers.blogspot.com/2009/09/android-16-sdk-is-here.html <comment><USER2> When are they going to put bluetooth stack in the sdk? That would be finally something really better then the iphone.

<comment><USER3> I agree. I want to play Wii games using my android.

</comment></comment><comment><USER4> Does anyone know what languages are supported by the text-to-speech engine? I found a list of locales in the release notes. Would that be them?

</comment><comment><USER5> The new skins look interesting:

[http://developer.android.com/guide/developing/tools/emulator...](http://developer.android.com/guide/developing/tools/emulator.html)

<http://imgur.com/etdDr.png>

I wonder why they changed.

<comment><USER6> The first emulator only had a dpad and a couple of buttons. With more devices coming out, it looks like they added more key support for various things.

The old emu also only supported QVGA and HVGA, the new one appears to let you pick a custom size and DPI for your build.

</comment></comment><comment><USER7> Question: are Android apps resolution independent? Because if they aren't, I'm going to be _really_ angry. 50% of the J2ME apps[1] out there refuse to work correctly on my phone because they were designed for a different screen resolution/size.

[1] Yes, I still use an old J2ME phone.

<comment><USER6> Could you try to watch the first 15 seconds of the video on that link?

</comment></comment><comment><USER8> A good text-to-speech engine on a mobile device opens a lot of possibilities. I've always wanted to have my incoming SMS/e-mail read to me while I'm driving. Even better with voice recognition for basic interaction.

<comment><USER9> Have you seen the accessibility features for the iPhone? <http://www.apple.com/iphone/iphone-3gs/accessibility.html> \-- be sure to watch the video.

</comment></comment><comment><USER10> I'm glad I didn't download the previous version it yesterday!</comment>


U.S. May Outlaw Messaging Encryption Used by WhatsApp, iMessage and Others - <AUTHOR> https://www.forbes.com/sites/zakdoffman/2019/06/29/u-s-may-outlaw-uncrackable-end-to-end-encrypted-messaging-report-claims/ <comment><USER2> [https://news.ycombinator.com/item?id=20305176](https://news.ycombinator.com/item?id=20305176)

</comment><comment><USER3> The fantasy of an encryption backdoor that only the good guys can use is just as realistic as the prospect of manufacturing firearms that only the good guys can use. Equally impossible. Not to mention, the definition of "good guys" is a political whimsy.

Don't give an inch in the war on math.

</comment><comment><USER4> The title of this article is phenomenally bad. Yes outlawing encryption certainly is an outcome, but just like the article says even the executive branch is split on this issue. Much better title would have been "US Govt Renews End to End Encryption Debate"

</comment><comment><USER5> If the trump administration decides to do this, there will be backlash. There will also be immediately ways of getting around whatever rules the put in place.

Part of me almost a wants the US government to try just to see what people come up with.

<comment><USER6> "Those who cannot remember the past are condemned to repeat it."

[https://en.wikipedia.org/wiki/Clipper_chip](https://en.wikipedia.org/wiki/Clipper_chip) 'Clipper 1993-1996 - R.I.P.'

[https://www.zdnet.com/article/the-laws-of-australia-will- tru...](https://www.zdnet.com/article/the-laws-of-australia-will-trump-the- laws-of-mathematics-turnbull/) 'The laws of Australia will trump the laws of mathematics: Turnbull'</comment></comment>