The Danger of "Simplicity" - <AUTHOR> https://asthasr.github.io/posts/danger-of-simplicity <comment><USER2> "Simple is often erroneously mistaken for easy. 'Easy' means 'to be at hand', 'to be approachable'. 'Simple' is the opposite of 'complex' which means 'being intertwined', 'being tied together'" \- [https://www.infoq.com/presentations/Simple-Made- Easy/](https://www.infoq.com/presentations/Simple-Made-Easy/)

<comment><USER3> I am yet to appreciate Rich Hickey's now famous "Simple Made Easy". While I agree with his points, I don't understand the significance of it. Simpler is easier than complex, right? Even the title said "simple-made-easy". What is the fuss about emphasizing "Simple is erroneously mistaken for easy"? They are not the same, but they are intimately related. Or is this an emphasis on relative vs absolute -- that relative simple can still be relatively not easy?

I don't think I misunderstood Rich Hickey, and I don't think I disagree. But I don't understand why people quote the opening sentence and feel so significant for them? To me, that is just a click-bate.

<comment><USER4> My takeaway was that if we conflate the two, we tend to use familiar (easy) tools to solve our problems, but that learning a new tool (hard) could result in a simpler solution.

E.G, passing something to a legacy program in a language I'm unfamiliar with from a program I wrote in a familiar language is easier than implementing my solution in the legacy language, but it's not simpler.

The 'relative vs absolute' seems like a heuristic to distinguish the two. Writing a solution in a different language is easier _to me_ , but I can tell on an absolute level that there are more failure points to that approach.

<comment><USER5> Nice explanation. Python is a great example of this IHMO. It is a real struggle to get the Python programmers on my team to use any other language than Python.

Why? Because it's easy for them. But the solutions they create with it are highly suboptimal. They could be far more robust and expressed much more concisely and directly in other languages with more powerful type systems and better support for eg: functional concepts.

But they actually really think that because Python is easy for them, that it's "simple". It's not: it's incredibly complex.

<comment><USER4> Haha, I was thinking of that as I wrote it. My first language was C++ back in the day, then I dabbled in various languages for a while, and finally really dove into Python because there was a project I couldn't figure out how to write any other way. If I had to work with one of the languages I learned earlier, my first instinct would now be to write the solution in Python and pass it to the legacy program. Perfect example of what the speaker is warning of.

</comment></comment></comment></comment></comment><comment><USER6> The quote of "If I had more time, I would have written a shorter letter" has been quoted so often that it is arguable who said it first, but it is definitely at least a 300+ year old concept.

Simplicity takes effort. It takes time. And you often cannot write simple software in the first version because you are designing it as you go. Simplicity comes from maturity both in the product design and the development staff, and is a long term goal.

It is not something that you achieve by critiquing individual PRs, but by insightful long-term thought into how to solve your problem with your code, and many refactors over time.

It is wise strive for simplicity in all code you write, but wiser to have the patience to let it develop over the lifecycle of your product.

<comment><USER7> > "If I had more time, I would have written a shorter letter"

I don't like seeing this quote in the context of programming.

Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has _two_ goals: not only for the intent of the code to be understood by future programmers, but also to make the code _easy to change_ in response to unknown requirements without causing any regressions.

The article is a bit all-over-the-place, but I do agree with it in general, because I've seen far more bugs in production caused by _changing_ code than by _adding_ it. Therefore, I would rather use a language with advanced features I can use to make my code harder to change in the wrong way. I think that if you phrase it like that, it makes it more acceptable to "avoid simplicity".

<comment><USER8> I get what you mean but tend to think of them to be so.ilar with in a different respect--that the concepts being expressed are clear. If the reason why code is organized by n a certain way is clear along with its effect then there would not be the motivation to stray from it. The problem is that often the organization is the result of achieving multiple effects rather than behaviorial factoring.

</comment></comment></comment><comment><USER9> > For example, dynamically typed languages like Python (or Ruby, Lisp, etc.) > are easy and pleasant to write. They avoid the difficulty of convincing a > compiler that you've written your code correctly, but they're harder for a > new team member to comprehend: you're trading fluent writing for more > laborious reading.

I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read _and_ write. For one thing, there's simply a lot less of it.

Lisp isn't more productive just because it's easier to "convince a compiler that you've written your code correctly". After all, if you haven't written it correctly, the _user_ will notice right away, too!

> Short functions, methods, and classes are quick to read, but must either be > built of many lower-level functions or themselves comprise parts of larger > compositions in order to accomplish anything. You're trading away locality > in favor of concision.

That's how languages work. You used the word "concision" rather than spelling out what it means in tiny words, and count on us readers to know it, or look it up. That's usually a win, especially if we have a standard set of words.

Again, this is where higher-level languages win big. You can encode higher- level concepts. I can write MAP or FILTER and people know what they mean. Or if my language doesn't have those, I can write them.

Just because you can explain something with lots of tiny words does not necessarily make it easy for anyone to understand: [https://www.muppetlabs.com/~breadbox/txt/al.html](https://www.muppetlabs.com/~breadbox/txt/al.html)

<comment><USER10> > _I feel like this misses the point of high-level languages. In my > experience, higher-level code is easier to read and write. For one thing, > there 's simply a lot less of it._

High level code shifts the burned of understanding the type system from the author and the compiler to the reader.

Yes, there is more text to read in a strongly, strictly typed language, but that extra syntax conveys a _lot_ of important information quickly and cheaply, and this is information that the reader _will_ need to know.

The difference between:

        cat( first, second ){ ... }

And

        cat( first: LogEntry, second: LogEntry): void { ... }

Is immense. In the later case, I know exactly what this function wants me to provide, what contracts the arguments must honor, and I know something about what the function intends to do with those arguments; it's void, so there are probably side-effects.

In the first case, I have to figure that out by reading the body of the method. The signature _could_ tell me all of this, but it doesn't.

> _After all, if you haven 't written it correctly, the user will notice right > away, too!_

My users are not paid well enough to debug my code for me.

<comment><USER11> What's wrong with:

        (cat-logs [& entries] ...)

If we care about human understanding of the contract, types are no better than names.

        reverse :: [a] -> [a]

        (reverse [xs] ...)

<comment><USER12> Names can and do lie, types are checked by the compiler. Also in you example, is an entry a string? a dict? its own class? who knows.

</comment></comment></comment></comment><comment><USER13> There was a wise thing along the lines of "to build a simpler system, start with more powerful (and complex, by necessity) building blocks"... I think it was Alan Kay who said this or something very similar.

Worst thing is that "simple" languages like Go force you to mix up "business logic" with "plumbing/infra logic" with "error handling logic" if you try to be idiomatic... I know that for security crucial code you might want to see all error paths next to a piece of code, for for the _other majority of the code_ I want error handling tucked away in different system, and also the business logic factored out in some other very generic one that doesn't care about actual implementation of infrastructure.

Sure, if _infrastructure IS your very product_ like Go's use case probably is, then it probably makes sense to not have features for such separation.

<comment><USER14> I experienced a good example of this recently when trying to decide between Bitwig and an upgrade of Ableton Live Lite to Suite.

Suite comes with a full-featured audio programming environment called Max for Live. It has some high level devices for common functions, but you can go very low level and make just about anything. The building blocks are all very simple and basic: oscillators, math functions, routing, etc.

Bitwig's Grid takes a different approach with a small number of powerful building blocks. The range of possibilities is smaller, but you can be more productive if the thing you want to make is composable from the available devices.

</comment></comment><comment><USER15> I once worked on a system where the senior engineer on the project had a dogmatic definition of simple.

It was an MVC web application. He insisted that having any form of flow control or logic in views was too complex - it was simpler to regard all logic as application logic and put it in the controller. This meant that instead of one controller being able to drive multiple views, something as straightforward as rendering a table a row at a time required a dedicated controller action.

That engineer's definition of simplicity produced an explosion of complexity in the codebase. That was when I came to understand that hand drills may be simple, but power drills are _very_ useful.

<comment><USER16> Yip, I've also encountered "architects" who obsess on certain things, and make a mess in the process, at least something that is a "mess" to the majority of coders.

One is left with a dilemma of complain harder or leave. Unfortunately, leaving is probably the only way out. Often such people have "connections" and are thus not correctable. They have outlier minds and want a system that models their outlier brain even if multiple developers complain. Bail out.

</comment></comment><comment><USER17> The article refers to "the much-abused YAGNI" and links to another blog post that goes into detail. Apparently some people take YAGNI to mean never anticipate anything. Is that your experience? I've always taken it as a tie- breaker when you're unsure whether to anticipate or not, and I've had the impression that others take it the same way.

Overall I like this article and the YAGNI one it links to.

<comment><USER18> I take YAGNI to mean not developing abstractions until you have enough use cases to back them up.

If you don't have a reason _now_ to make an abstraction, don't do it yet. Wait until you have at least 3 use cases where you're repeating yourself before you come up with an abstraction that collapses them. You'll know better what the right abstraction will be once you have those use cases... any abstraction you come up with now is much more likely to be wrong. And a wrong abstraction is much worse than repeating yourself.

Of course, if this is the umpteenth time you've done the same CRUD app that wraps a relational database, go ahead and use the abstractions you know worked before, because in that case, you've already seen the use cases before and you have a better idea of what abstractions will work.

<comment><USER17> [https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

</comment></comment></comment><comment><USER19> I think the confusion around simplicity is in what terms a thing is simple.

For example, 2 pieces of text can be simple in 2 different ways:

First text is long but uses fewer words in vocabulary. So it is "simple" in a sense you need to learn only few words to read it.

Second text is short but uses richer vocabulary to describe things with fewer words (syntactic sugar). It is "simple" in a sense you only need few words to describe stuff, but more "complicated" because you need to learn more words.

"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement.

<comment><USER20> >"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement.

I was thinking something similar recently.

Good code should take the next developer less time / effort to understand it than it took the original developer to write it (assuming similar levels of ability).

<comment><USER21> > the next developer

And that's often you, just in a few months' time.

<comment><USER20> True.

And as I mentioned in another comment, I learned the most by building a system from scratch and maintaining git for 4 and a half years. If I couldn't understand a bit of code that had written more or less straight away, then it was usually time to refactor it.

</comment></comment></comment></comment><comment><USER22> Go's parsimony is about cognitive load. I've programmed for 30 years and am an expert in complex languages like C++. I find that when I write Go my mind spends far more time thinking about the problem than the language, which I like.

The language is modern and powerful enough to spare the programmer from some of the worst drudgery (unlike C) and is much more inherently safe, but it's not a jungle gym of complicated constructs and difficult quasi-mathematical concepts that (while interesting) detract from the task at hand.

</comment><comment><USER23> If Buttercup and Westley from _The Princess Bride_ were working on software, the conversation might have gone something like this:

Buttercup: I balk at your complexity! Westley: Software is complexity! Anyone who says otherwise is selling SaaS.

</comment><comment><USER24> > The complexity of software is an essential property, not an accidental one. > Hence, descriptions of a software entity that abstract away its complexity > often abstracts away its essence.

\- Fred Brooks, _No Silver Bullet_ , 1986

> Complexity _is_ the business we are in, and complexity is what limits us.

\- Fred Brooks, _No Silver Bullet Refired_ , 1995

</comment><comment><USER25> > The problem with these approaches is that "simplicity" never gets a rigorous > definition

Last I counted there were 48 proposed methods of defining simplicity. I created one as well and am biased and think it is the best way to rigorously define simplicity/complexity: [https://github.com/treenotation/research/blob/master/papers/...](https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.pdf)

</comment><comment><USER26> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

By simplicity, we mean frugality.

If you can implement something without adding a ton of dependencies, abstraction layers, and design patterns, it will be easier to understand and debug.

YAGNI is everything but abused.

</comment><comment><USER27> One analogy I like for software problems is knotted string. You approach the problem, loosen some things up, try some approaches, and sometimes you get lucky and shake things loose.

Other times, you have to cut the string and you lose fidelity in your solution.

Other times, you can only move the problem around so it looks simple to the user; there's still a knot there, but it may be hidden in the back end.

This isn't the only analogy, and it's incomplete, but I still like it.

</comment><comment><USER28> I classify easy/hard as

1) Concise vs. Verbose 2) Straightforward vs. Confusing 3) Flexible vs. Inflexible 4) Efficient vs. Inefficient

The important thing about these 4 is _they get along horribly_. The most concise solution is often confusing, inflexible, and/or inefficient in many respects. I should also note that straightforward-confusing is the hardest one to measure objectively.

</comment><comment><USER29> The two perspectives that I often find at opposite poles when proposing simplicity is that of the developer vs. that of the user. Generally what's simple for the user drives less simple solutions for the developer and vice versa. It's not always possible, but when it is, I strive to find the solution that ends up being dead simple for both.

<comment><USER30> I really noticed this when I caught business folks conflating the two.

Often the more easily you can describe the situation, the more code it takes to make it Just Work.

Simple for the user is harder for me.

<comment><USER29> Exactly

</comment></comment></comment><comment><USER31> I'm starting to think that I'm in the minority that agrees with most (if not all) Go's design decision and appreciate Rob Pike's stewardship so far.

<comment><USER7> I'm in the opposite camp from you — I like generics, lack of null, and syntax highlighting — but that's fine! I don't think this is something we have to 'agree' or 'disagree' with. It simply means that you're within Go's target market. If you want to use a simple language, and the software you're writing works just fine without these features in your code, then of course it's OK to jettison them and stick with the simple language. I need those features because of the software I write, so I need to stick with a more feature-ful language.

Acting like there needs to be some 'one true way' when we're writing completely different pieces of software is how pointless internet arguments get started.

<comment><USER32> The problem is not all of us get to choose the language we work in and sometimes someone picks a language for all the wrong reasons and then you're stuck with it because a rewrite is costly and usually not an option.

So these debates do have some merit.

<comment><USER7> You're right, and that is unfortunate. But "people sometimes make the wrong decisions" is a much tougher nut to crack!

I agree that we should have these debates — but on a "is this language acceptable for my use case" level, not a "is this language acceptable for _any_ use cases" level.

</comment></comment></comment></comment><comment><USER33> Let me answer this once and for all:

> What are we optimizing for?

You mean who are we optimizing for. For the guy who has to understand and maintain this code 2 years from now. (This guy could in fact be you yourself).

Thats why I like Go. And C, now that I think about it...

<comment><USER9> I agree with the first part -- which is why I _don 't_ like low-level languages like C.

I can't count the number of times I've encountered old C code that uses pointers and bytes and arrays, and I discover a bug, and on further inspection I can't even figure out what they were trying to do. It's all just pointers and bytes and arrays. The language is too low-level to encode _intent_ , except at the lowest level, so you're putting all your trust in comments.

<comment><USER34> Functions are the basic abstraction in C. They are good for describing intent. Likewise, structs are good for giving pointers and bytes meaning.

Pointers and bytes and arrays are the least of all my problems in dealing with old C code.

</comment></comment></comment><comment><USER35> I agree with the author that the simplicity of learning the language is not the only type of simplicity. There are other types of simplicity like the simplicity of how consistent the language is. For instance, I've felt for some time that Python has become too complex. I started out quite simple, and there are now like 3-4 different ways to write a method signature.

</comment><comment><USER36> Steve Jobs created many things and also destroyed a many. One of them is the openness of platforms and another is what I'd call _delightful complexity_. Simplicity is not always a joy and lot of overjealous wanna-be-Jobs seem to forget about that. I do want all those buttons and choices in my music app that let's me be expressive and opiniated about my taste. And I definitely want generics!

A bigger issue is that a many times simplicity for you is not simplicity for others. This often comes back to haunt you in software design. You might think that complex design is not good for you and you may strive to simplify internals even though it might make life awkward for users of your creation. I feel a lot of such decisions have been made in designing Go. Overjealous pursuit of simplicity has led its designer to keep compiler less complex, internally beutiful and work of art but at the expense of external usability for its users. This article captures the sentiment pretty well.

</comment><comment><USER37> I don't think it's a good idea to introduce complexity to the definition of simplicity and I think this is what the author is trying to do.

It's completely backwards. The whole point of calling for simplicity is to make you think about whether there is a simpler way to express yourself that still solves the problem at hand. This might be a hard task, but it's not a complex one.

</comment><comment><USER38> I think this piece risks being interpreted as saying that simplicity is not important.

The fact that simplicity is hard to achieve will be obvious to anyone who has ever truly tried to achieve it.

Personally I would worry far more about people thinking simplicity is a fools errand and so not trying hard enough to achieve it, rather than people thinking it might be easier than it is.

</comment><comment><USER39> TFA seems to build upon confusion of how "simplicity" is defined.

It's easier to compare it against "complexity" which is the sum of parts; e.g. a complex machine, so "simplicity" must be attributed to an atomic design of "the smallest part which cannot be broken any further"; i.e. think of a simple machine like a lever.

<comment><USER40> I think Ousterhout's pragmatic definition of complexity is the best one when discussing actual code bases: complexity is anything that makes the system hard to change, taking into account how often the relevant part needs to change.

<comment><USER41> Hard to change is subjective. Maybe something you found hard to change, your colleague would have no trouble with. And vice versa.

<comment><USER40> Yeah, with this definition, complexity is something you notice as a working team, not something you can directly measure with syntactic criteria (of course syntactic criteria may correlate with the complexity).

</comment></comment></comment></comment><comment><USER42> I'm usually in favor of the good old KISS principle, but I've experienced few situations where "simple" ready made solutions were chosen on the basis of few demos showing "how simple it is to use this or that feature" over writing in- house scripts in general purpose language like python. In all of those unrelated situations there was trouble later when it transpired that indeed it is simple to use feature A, B and C that works exactly as original author's wanted, but the moment you want to tweak something manipulating the whole thing is terribly inefficient, and/or complex. In the end tweaking those simple ready made solutions required more work than re implementing the whole thing from scratch would take in the first place...

</comment><comment><USER43> I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives"

I would hope that people with the same objectives would agree on simplicity for that domain.

Examples:

Need a lot of machine control, direct memory control (page alignment, cache alignment, shared memory, numa, etc) interact with system calls directly, interact with hardware, and security is not important in the domain (e.g. private hpc cluster behind a firewall)

C is probably the simplest

Need to quickly prototype something medium sized that involves non-trivial data structures or needs to interact with an http server. And you don't care about performance.

Something like Python is probably simplest

Etc etc etc

By contrast.. try doing the former with Python, Java, etc and see how much additional cognitive load you have to add.. ever try the later with C.. no fun.

<comment><USER5> > I would define simplicity as "the approach that minimizes cognitive load > while meeting all other objectives"

That's one dimension of simplicity, but it doesn't take into account some of the other benefits of simplicity, such as, eg: robustness. Another definition would be "the approach that minimizes the total number of possible interactions" (akin to "moving parts" in a physical machine). In that sense, the fewer total possible interactions, the fewer places something can break. There might be MORE cognitive load to a human in direct sense, but the system is far more constrained to only do the "right thing".

I sometimes think of the generalization of it being "the approach that minimises the total state space of the system, including the brain of the human trying to understand it".

</comment></comment><comment><USER44> I like to take an information theoretic, model-problem fit stance on simplicity. It's useful to reason about it in terms of overfitting vs underfitting, over-abstraction vs under-abstraction, high resolution fit vs low resoltion fit, and in terms of cross entropy between the knowledge embedded into a software system and the information relevant to solve the corner cases of the problems ([https://email@example.com/product-market- crossfit-c09b...](https://email@example.com/product-market- crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667)). Well tuned knowledge is not an easy thing.

</comment><comment><USER45> My take on simplicity is how strong the abstraction layers are. Using a web framework to show "hello world" versus making a video card driver and make it show "hello world" on the screen.

A world class athlete makes something hard look easy. So just because the code looks simple, doesn't mean it is easy.

Remember when you first learned how to code, or learned some new concept, and now you can't remember what was so difficult about it?

Just one line of code might touch several computers, hardware components, with several software layers. Everything has to go right, all the way down to atomic level. Nothing is simple. It just appears to be simple through strong abstraction layers.

</comment><comment><USER46> Recognizing simplicity requires familiarity with complexity.

\- - - -

FWIW, Category Theory provides a mathematical formalism for determining when your system is "as simple as possible, but no simpler".

\- - - -

> "average programmers" have difficulty understanding complex languages

That's not pejorative IMO, that's practically tautological: If "average programmers" have difficulty understanding a language, isn't that an indicator that it might be too complex? Anyhow, trawling though e.g. Stackexchange provides adequate evidence, IMO. Or a thread about Haskell with all the people complaining about how hard it is to understand FP, etc.

</comment><comment><USER16> There are several key "rules of thumb" to keep in mind, and they are often contradictory. Knowing how to weigh them well against each other takes experience in both the domain and IT in general.

Another rule of thumb to add is "don't obsess on a _single_ rule of thumb; they are all important."

In my experience "keep it approachable" often overrides "less code" and DRY. Maintenance staff changes and you probably cannot control the quality of the next maintainer such that if your code requires an abstraction guru to figure out, you may put your org in a difficult spot.

<comment><USER47> _> There are several key "rules of thumb" to keep in mind, and they are often contradictory._

Rules of thumb in software engineering is bullshit masquerading as wisdom. Don't keep them in mind. They will hog your cognitive bandwidth which you could use to actually reason about problems.

Real engineering involves balancing tradeoffs. To balance them, you need to understand what they are. Sloganistic "rules of thumb" do not help with that at all.

For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info _or_ it could be used to advocate for ignoring a critical design flaw that's guaranteed to bite you in the ass later on.

Good engineers don't spew out slogans. They explain their reasoning.

<comment><USER16> Re: "For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info..."

Another rule of thumb is "know your domain".

Re: "Good engineers don't spew out slogans. They explain their reasoning."

That is true, but it's also good to have summary reminders. People won't remember most 2 hour lectures unless refreshed over time, and rules of thumb are one way to do this without re-attending the same 2 hour lecture over and over. In the ideal world they'd re-attend the full lectures (or close to) to get a refresh, but that's not the way most humans do things.

</comment></comment></comment><comment><USER48> "There are two ways to design a system: make it simple enough to be obviously right, or make it complex enough not to be obviously wrong" \-- Charles Hoare

</comment><comment><USER49> Simplicity cannot be a goal in itself. Is the dashboard of a F35 worse than the dashboard of a car -- because it's less simple? It's the same thing with programs and programming languages. Computers are universal devices, they can be F35s or just basic cars. The important thing is 'fit for purpose', which is more elusive and not so amenable to simplistic ideological statements.

<comment><USER50> i can't remember the author but there was a disucssion on usenet about comm. protocols years ago and someone said "it's not finished when there's nothing left to add, it's finished when there's nothing left to take away". To me, that's what simple means and i think it also equally applies to "fit for purpose". A perfect fit for purpose is an implementation with nothing left to take away. I feel like when you someone sees a perfect fit for purpose they would also think "this is really simple" whether it be an F-35 dashboard, nuclear reactor control room, or the controls on a lawn mower.

edit: after thinking about this for a few min. there's larger than normal holes in my point heh. However, i really like OPs point.

</comment></comment><comment><USER51> Here's a few more if anyone is compiling a list:

Dieter Rams -- [https://www.vitsoe.com/gb/about/good- design](https://www.vitsoe.com/gb/about/good-design) John Maeda -- [http://lawsofsimplicity.com/](http://lawsofsimplicity.com/)

</comment><comment><USER51> Here's a few more if anyone is compiling a list: [https://www.vitsoe.com/gb/about/good- design](https://www.vitsoe.com/gb/about/good-design) [http://lawsofsimplicity.com/](http://lawsofsimplicity.com/)

</comment><comment><USER52> What's the point being argued here? Seems to go all over the place.

Seems like it's a rant mainly about semantics.

<comment><USER17> I took the point to be that there isn't always a clear "simpler" way to implement something, and that when someone is hesitant to accept what to you is the obvious simple solution, listen to their concerns.

Mainly this comes from the 2nd paragraph.

</comment></comment><comment><USER53> Heh

"I apologize for such a long letter - I didn't have time to write a short one."

― Mark Twain

</comment><comment><USER54> Simplicity is objectively measurable. Here is a practical suggestion, though directly applied to mechanical engineering is readily adaptable to application design.

[https://www.sciencedirect.com/science/article/pii/S235197891...](https://www.sciencedirect.com/science/article/pii/S2351978918302361)

One way to think about simplicity is to accomplish the greatest number of business objectives with the fewest number of abstractions. As others have said, that isn't easy. It takes increased effort to achieve simple.

<comment><USER55> The metric chosen here is still arbitrary, why would the number of interfaces be more important than the number of the amount of interconnected interfaces? It is still subjective and hence simplicity is still subjective too

<comment><USER54> When a metric is quantifiable with numbers it is objective. It may not be the best tool for the job or even valid at all, but it is still objective.

Subjectivity, on the other hand, means to prioritize a content or bias above its measures.

<comment><USER55> The problem is that no matter which metric you choose, I can pick another one leading me to have opposite outcomes in a manner that you cannot argue with. The importance of your objective metric will still be subjective based on how important I think each metric system is. Making the entire thing subjective.

<comment><USER54> You are confusing cause and effect. The measure itself is the objective part. What you do or what you believe from that number is the subjective part.

If objectivity were important to you then you would use _many_ measures.

</comment></comment></comment></comment></comment><comment><USER56> There is a lot of noise in the article (like mentioning Rob Pike's take on syntax highlighting), but mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles. Could've been a single tweet.

Attempt to explain the dangers of simplicity is lost in vague sentences like "Rust has different concept of simplicity -> Rust authors wanted to protect from memory errors" or TBU (True But Useless) phrases like "every choice has a cost"/"everything is a tradeoff".

<comment><USER57> > mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of > articles

The mentions of Rust, Haskell, and Go are limited to a single section of the article, so I'm not sure what you're talking about. Most of the article seems to stay abstract with concrete cases brought as examples.

<comment><USER56> I might be biased, as I had to read every Go rant back then when writing a "How to complain about Go" article, and this is clearly the same narrative.

Author did a good job to hide it, but if you look closer you'll see indirect Go mentioning throughout the whole article:

\- ""What do you mean, you think Go's error handling is bad? It's simple!""

\- How can we articulate a position more powerful than "syntax highlighting is juvenile?" <\- refers to the Rob Pike's opinion about syntax highlight

\- "Go's error handling has become a meme,"

\- "The creators of Go have said, sometimes in pejorative terms,1 that "average programmers" have difficulty understanding complex languages,"

\- "It's inflammatory, but the article "Why Go's design is a disservice to intelligent programmers" is worth reading just for the quotes from Rob Pike."

</comment></comment></comment><comment><USER58> quote of the month: "Code, in itself, is not an asset. A solved problem is an asset."

</comment><comment><USER59> The link about Go with quotes by Rob Pike lets me think that maybe Abc.xyz made Go like they did because they wanted to be able to have some sort of AI generate code eventually.

</comment><comment><USER60> Thought this was gonna be a cybertruck jab.</comment>


Google Wants to Sell You Auto Insurance - <AUTHOR> http://blogs.wsj.com/digits/2015/01/08/google-wants-to-sell-you-auto-insurance/ <comment><USER2> "We determined your sleeping schedule based on your computer and mobile usage. Since you are below the recommended hours suggested and may be tired behind the wheel, we are raising your rate 40% effective immediately."

<comment><USER3> Or, our self driving car can cut your premiums in half!

</comment></comment><comment><USER4> People seem to be speculating well beyond what's in this article. It looks much more like they're just going to have a site for selling insurance, not becoming an insurance company.

It looks like just more of their credit card comparison thing: [https://www.google.com/compare/creditcard](https://www.google.com/compare/creditcard)

<comment><USER5> Wow, thanks for the link to that credit card comparison! I've never seen it before, but that's really cool. Why do they provide this as a service/how does it help them?

<comment><USER6> Money is a driver. Google can either take 1 USD _) per click or 5 dollar from the credit card companies. They 're cutting out the middle man, other comparison websites. I wouldn't think they do it for the benefit of users or because users asked for the service.

_) I don't know that the current adsense price for query term on credit cards is

<comment><USER7> more like $60 - $180 per credit card signup + $$ for just getting people to apply. Given the high volume of traffic Google can drive, I'm sure they'll get the best commissions from banks.

It looks like the commission is all they're after too, since it's not possible to sort by things like 'Sign Up Bonus', which would be useful to consumers.

</comment></comment></comment></comment><comment><USER8> This could be a touchy subject for Google. Larry Page always joked that they could start a successful hedge fund with the knowledge people hand them every day.

If Google starts aggregating their data to sell insurance I can see people moving away from some of their services.

Imagine if your health insurance provider had access to your emails, search history and web queries before deciding if they wanted to provide you with insurance or not......

If they just aggregate quotes from brokers to show to people then I can't see a problem with it. The people who loose out on the adwords revenue, however, might disagree:)

<comment><USER9> > Imagine if your health insurance provider had access to your emails, search > history and web queries before deciding if they wanted to provide you with > insurance or not......

I'm fine with this. With the Affordable Care Act, insurers aren't able to decline you due to preexisting conditions. And previously, they would be able to cancel your policy for medical issues you hid from them. Its already illegal for insurers to discriminate against you based on your genetic profile.

What's the concern?

<comment><USER10> Google (probably) knows my sexual orientation, number and frequency of partners, if I'm trying to get pregnant, if I'm self-treating anything, if I'm hiding anything, if I drive recklessly, if I've settled car accidents under the table, etc. Some of these are not protected even under the ACA or other regulations, which may not survive in their current form for very long.

There's a lot more to discriminate against when you have total information awareness of a person. Most of it surprisingly legal. As a google search engine user, chrome user, android user, and web dev - I imagine google's picture of me is and highly invasive and creepily accurate. This is bothersome privacy violation and a major competitive advantage against other potential insurers.

<comment><USER11> Keep in mind the whole point of insurance is shared, proportional risk.

Is it both simultaneously the Wrong Thing for an insurance company to use all available information to make an informed decision, and the Right Thing for a person to put on airs to appear less statistically risky than they actually are?

Bluntly, this quacks like an argument for deception for personal gain (via lower premiums).

Granted we can talk about insurance companies being shady, but even a completely honest one would, say, rightly raise your rates after an accident.

<comment><USER12> > Keep in mind the whole point of insurance is shared, proportional risk.

The fundamental problem is that the more information is brought to bear on the idea of "risk", the less shared it is. This is especially stark in health insurance: do you have family history of serious diseases? Do you carry a particular gene? Do you engage in risky behavior like smoking, adventure sports, promiscuous sex? It can price some people out of the insurance market altogether, and make it less of a "shared" pool. This is precisely the problem the ACA is trying (with debatable success) to tackle.

Auto insurance is arguably more directly tied to statistically risky behavior rather than factors beyond your control (like genetics), but the potential is still there. We as a society are not ready for total information awareness on the part of our insurer. If Google offered insurance directly, could they deny a claim based on an email you sent before or after an accident? Raise your rates if you search for fast cars online? What's the difference between actually risky behaviors, and behaviors that are merely correlated with higher risk? The insurance markets are opaque enough without adding black box algorithms working on nearly limitless data inputs.

<comment><USER11> The opaqueness is a feature, not a bug. With full transparent knowledge of what goes into the risk calculation, people _will absolutely_ game the system and ruin it for everyone else.

</comment></comment></comment></comment></comment></comment><comment><USER13> As it happened with plane tickets ([http://en.wikipedia.org/wiki/ITA_Software](http://en.wikipedia.org/wiki/ITA_Software)), it is happening with car insurance. Insurance is the most expensive vertical in terms of CPC ([http://www.wordstream.com/articles/most-expensive- keywords](http://www.wordstream.com/articles/most-expensive-keywords)) simply because it's a very high-margin business and the market for car insurance leads is _very_ hot.

The most successful participants in the car insurance leads marketplace (and any leads marketplace TBH) do things that are inherently consumer-unfriendly to achieve as high margins as they do. Will Google do those things? No.

So will Google see as much to gain from cutting out these players as they would from allowing these players to pay for AdWords? Eh, we'll see.

Self-driving cars are far, far off, leaving billions of retail dollars on the table between now and then.

<comment><USER9> > Self-driving cars are far, far off, leaving billions of retail dollars on > the table between now and then.

5-7 years is far, far off?

<comment><USER13> Yes, yes it is--but your off-hand estimate does not do the situation any justice.

<comment><USER9> My "off-hand estimate" is from multiple sources:

[http://www.wired.com/2015/01/rode-500-miles-self-driving- car...](http://www.wired.com/2015/01/rode-500-miles-self-driving-car-saw- future-boring/)

[http://www.businessinsider.com/elon-musk-on-the-future-of- dr...](http://www.businessinsider.com/elon-musk-on-the-future-of- driving-2014-10)

[http://www.theverge.com/2014/9/22/6828161/california- permits...](http://www.theverge.com/2014/9/22/6828161/california-permits-self- driving-cars-google-audi-mercedes-benz)

The idea of you driving your car is essentially dead. Vehicle miles driven per year is already stagnent due to boomers retiring and millennials not having the same inclination for cars as generations past have.

Passenger cars sit idle 95% of the time. Its not going to take many autonomous vehicles to replace the current fleet with existing utilization so low.

<comment><USER14> I would expect it to go like electric cars. Maybe in 5-10 years you will be able to buy a high-end one, but the time to a majority having one will be double that, at least.

<comment><USER9> If I can get a self-driving Model S on Uber whenever I want, why would I buy a car?

<comment><USER14> Yeah, when that day comes, it will be nice. We just disagree on how soon it will be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> As Google continues to develop _vertical search engines_ they are naturally flirting with anti-trust issues. We already saw a pre-cursor to this with Google Flights, even though the Justice Department cleared Google's acquisition there were significant conditions Google had to concede [1].

Here Google's insurance product will go far beyond Google Flights in terms of anti-trust issues. Moreover, it would be like Google Flights if Google: 1.) directly sold airline tickets on behalf of airlines (instead of linking you to where you can buy tickets); and 2.) if Google owned its own airline.

The other issue, which many have touched on, down the road is the potential conflict of interest, if simultaneously a driver owns a Google self-driving car and Google is the insurer. That said health insurance companies are acquiring hospitals and physician owned practices in record numbers, and while I see an inherit conflict of interest there is apparently no regulations in place prohibiting this practice. Do consumers really want the manufacturer of a self-driving car to be the same company who might be determining liability on an insurance claim?

[1][http://www.wired.com/2011/04/google- ita/](http://www.wired.com/2011/04/google-ita/)

</comment><comment><USER16> I found my car insurance using Google's comparison tool. It was much slicker and easier to use than the other comparison sites.

</comment><comment><USER17> Google UK has been providing comparison services [1] for car insurance, travel insurance, credit cards, mortgages and bank accounts, for years now.

Comparison sites are pretty big in the UK [2,3,4], more so than I have noticed since I've been here in the US. They are generally give the same sort of price; and all take the same sort of inputs. But I personally always found Google's lack of clutter, in-your-face branding and simplicity to make it my favorite.

Though it's not really advertised, and almost everybody I have mentioned it to has never heard of it.

[1] [http://google.co.uk/compare](http://google.co.uk/compare)

[2] [http://comparethemarket.com](http://comparethemarket.com)

[3] [http://confused.com](http://confused.com)

[4] [http://moneysupermarket.com](http://moneysupermarket.com)

</comment><comment><USER18> This seems like a no-brainer for Google.

In fact, I would expect them to offer own insurance directly in the near future, for several reasons. First, insurance is one of the big practical hurdles facing their self-driving cars – in an accident, who is at fault? By offering their own product they can potentially circumvent this hurdle. Second, if they begin to offer homeowners insurance, they can tie their rates directly to Nest data, which should allow them to offer more competitive rates and more accurate pricing, similar to what Progressive has done with Snapshot [0]. And lastly, this obviously gives Google access to more, and potentially better, personal data.

[0] [http://www.progressive.com/auto/snapshot/](http://www.progressive.com/auto/snapshot/)

</comment><comment><USER19> "Carney says Google may also face resistance from insurance companies that are reluctant to share information that could help Google compete with them someday."

Dear insurance companies. Don't flatter yourselves. Google is already light years ahead of you.

<comment><USER20> Ahead of them in what regard, exactly? Daily active users to the site?

<comment><USER19> The context of the quote from the article has to do with speculation that Google will one day want to start their own insurance company to become a direct competitor in the insurance business.

</comment></comment></comment><comment><USER21> \- Adwords for insurance are among the most expensive. Makes total sense for them to take a cut of that market.

\- There's a huge difference between quote aggregation / marketing / sales, and the actual underwriting / pricing. The prior is far less regulated than the latter.

\- This has nothing to do with self-driving cars.

</comment><comment><USER22> There will probably be a lot of resistance towards self-driving cars from insurance companies as the issue of responsibility becomes much more complicated, so It's probably a good idea for Google to get some influence in this business.

</comment><comment><USER23> I'm amazed at the attitude towards insurance companies in this thread... that they shouldn't be able to charge you based on what they consider risk... People act as if insurance companies exist to just give you free money.

</comment><comment><USER24> Insurance could be a killer feature of self-driving cars. Imagine a self- driving car that came with a $0 5-year collision insurance policy.

</comment><comment><USER25> Really interesting to consider how self-driving cars will enable lower insurance rates.</comment>


Use Virtualenvs the Easy Way - twebz-gh https://github.com/twebz-gh/venv-path-shim <comment> twebz-gh I've been using versions of this tool (VPS) with workmates and associates for awhile. It has proven handy for our workflow, so I wanted to share it.

VPS might be useful to you if you handle multiple projects written in different versions of Python, and/or with different dependencies.

</comment><comment><AUTHOR> VPS might not be the best acronym here, as many will confuse it with Virtual Private Servers.</comment>


Show HN: Hacker Lab – an easy way for netsec students to practice hacking - <AUTHOR> http://thehackerlab.co <comment><AUTHOR> Hi I'm pretty new to netsec, I haven't even started on OSCP, just working through some of the common prerequisites I've seen recommended.

Anyway, I'm a frontend webdev by profession, wanted to see if anyone was interested in a little side project I've been working on as I've been learning: thehackerlab.co

I'ts similar to vulnhub or hackthebox. Just sets up vulnerable boxes like webgoat, dvwa, metasploitable or whatever, but there's no download or setup. The site just self-hosts it. let me know if you'd like to try it out, or feel free to leave any kind of feedback as well. Even if it's just something like "you're crazy for hosting vulnerable boxes on the internet!" Also any questions that pop into your head are super helpful too, I'm trying to build up an faq with the common ones.

Thank you for the help!</comment>


Calling All Hackers - <AUTHOR>

Calling All Hackers
If you know anything about coding and are angry with Congress over its handling of the debt crisis, unemployment, financial reform, health care, gun control, gay rights, or anything at all, we need your help.
Think Computer Foundation is putting together a project that is designed to make a substantial impact right now. We need your help to do it.
If you can make it tomorrow, August 8th at 6:00 P.M., come to the offices of the Foundation's for-profit sister company (Think Computer Corporation) at 3260 Hillview Avenue, Palo Alto, CA, 94304. We'll be handing out tasks to get things rolling.
E-mail info at thinkcomputer.org with any questions. <comment><USER2> What about those that want to help but are unable, geographically, to attend?

<comment><AUTHOR> Send an e-mail to info at thinkcomputer.org.</comment></comment>


It got eaten - <AUTHOR> http://www.lrb.co.uk/v32/n13/peter-godfrey-smith/it-got-eaten

<comment><USER2> The title of this submission is a bit misleading. The linked article is a review of a new book by Jerry Fodor (and others) attacking Darwinism in biology. The Chomsky review (which devastated Skinner's behaviorism) is mentioned in the first few paragraphs, but it's not the focus of _this_ piece.

That said, Fodor makes some very interesting reading when he attacks evolutionary psychology. See this article, for example: [http://www.lrb.co.uk/v20/n02/jerry-fodor/the-trouble-with- ps...](http://www.lrb.co.uk/v20/n02/jerry-fodor/the-trouble-with- psychological-darwinism)

<comment><USER3> The Chomsky review (which apparently devastated Skinner's behaviourism) is mentioned in the first few paragraphs because the author of the review, Peter Godfrey-Smith, claims that similarities between behaviouralism and Darwinism have been pointed out. In the second last paragraph of this long review he says:

"The similarities between behaviourist learning theory and Darwinian evolutionary theory are not as close as Skinner or, now, Fodor and Piattelli- Palmarini claim, even if the theories have structural resemblances. Behaviourist learning theory, as applied to humans, has been largely abandoned, but that doesn't mean that Darwinism's theory asks to be abandoned along with it. Still, if one view is right and the other wrong, we might try to say something about why a certain pattern of explanation works in one place and not in the other."

Chomsky's review is not the focus of the piece but it is bound up in the back and forth of ideas under the microscope here. You are correct though, the title of the submission is misleading.

I found the arguments very hard to follow even though I am pretty well read up on the mechanics of the theory of evolution and even though I have some philosophical training. This is one of those instances where I'd need to read the book I guess. I'm not sure if it is Godfrey-Smith's fault for not explaining Fodor's and Piattelli-Palmarini's position well or whether their position is unsellable. Seemed very hair-splitting to me.

<comment><USER2> Fair enough, but my point was just that the title here might mislead people if (like me) they were already familiar with the legend of "Chomsky's review of _Verbal Behavior_." I went to the article expecting it to be a cultural history of that review. (You know the sort of thing I mean: one of these now popular histories that starts from something very specific - a product, or an event or what-have-you - and then spins a larger historical/cultural investigation from that starting point. Someone should write that book actually: a semi-popular history of the shift away from behaviorism.) Not a huge deal, but I was confused.

<comment><USER3> I never heard of this legend but maybe if you're coming from sociology or psychology rather than philosophy like I am then this is famous-ish. I'd read a book like the one describe for sure, I love Chomsky and never had much love for behaviourism and am delighted to find that I'm in such hallowed company. By the way I was completely agreeing with you earlier but just expanding on what you had said and I shall do so in kind again sir: very misleading title.

</comment></comment></comment></comment><comment><USER4> For anyone who never read Chomsky's review of _Verbal Behaior_ , the text is at Chomsky's website, here: <http://www.chomsky.info/articles/1967----.htm>

His review of Skinner's _Beyond Freedom and Dignity_ , several years later, was also pretty devastating: <http://www.chomsky.info/articles/19711230.htm>

</comment><comment><USER5> This post title is trolling. The article is actually about a book that tries to criticize evolution in the way social "sciences" are made: a thick haze of theory and very scarce empirical data.

Might be interesting for those that think that social sciences are worth respect, in spite of their flaby methodologies.</comment>


Tim Cook: You Deserve Privacy Online. Here's How You Could Get It - <AUTHOR> http://time.com/collection-post/5502591/tim-cook-data-privacy/ <comment><USER2> I ve said this before but I ll say it again, between GOOG/FB/MSFT Apple seems to be doing more to privacy and it's mainly in part due to their business model where most of their revenue comes just from selling products and not ads. (May be MSFT is more diversified than the other two). It will be interesting to see how this plays out in their favor.

<comment><USER3> Key words being "seem to," which is due solely to a marketing construction. They make devices that you can't (realistically) develop for without giving your credit card or bank information. When the iPhone was released, you couldn't even use the device at all without an iTunes account with payment information.

<comment><USER4> These sort of replies always show up in these threads. They're also absolutely, 100% wrong. About as clueless as the classic "less space than a Nomad" line.

Apple isn't buying your credit and loyalty card transaction history.

Apple isn't storing plaintext transcripts of your chats, and using access to them as a tool for backroom political deals.

Apple's former HQ wasn't turned into Palantir's HQ.

People need to stop making these sort of comparisons. It doesn't make you look smart. It makes you seem either insanely pedantic or completely uninformed about what the other companies ARE doing. You can criticize Apple for their pricing model, the uselessness of iTunes, whatever ... Privacy is not one of those options. The closer you are to this actual issue (and I'm pretty damn close to it), the more you know that this is the truth.

<comment><USER3> As much as you try to deflect, my statement is factually correct about what Apple IS and WAS doing and just one of many reasons why Apple is worse than alternatives for privacy.

> Apple's former HQ wasn't turned into Palantir's HQ.

What's that got to do with the price of tea in China?

</comment></comment></comment></comment><comment><USER5> I think apple is still not there

* You have to identify yourself and log in to use an apple product.

* Apple products contact apple continuously, along with akamai and others (cdns are the cookies you cannot disable)

* You cannot firewall apps, they can always access the network.

* Apps can run in various ways without you realizing it, during installation, notifications, deep links, etc...

* Apple piggybacks services you do not want on the back of legitimate services:

\- turning on bluetooth will also enable ibeacon tracking services, and your device can become a beacon.

\- turning on wifi will also collect data for crowdsourced location information

\- your device will auto-connect to various wifi services out of the box.

\- pasting a web link in mail, imessage, etc will look it up, and following it is shared with apps using deep linking.

I do think Tim Cook is right about something, only legislation can slow things down (it will never stop things, because the bills will be compromised on before they become law).

I also think Apple could still change their behavior. Let people turn things off. Even the "anonymous" data/analytics apple collects. Even the network.

I think many legitimate companies over-collect data out of fear of not having enough information. It's the mindset - if I allow people to opt-out, we will get no information to understand things or make decisions with or provice services. Beginner leader mistake - you don't need perfect information.

I think with trust comes unfettered commerce.</comment>


Google updates its Privacy Policies - <AUTHOR> http://www.google.com/intl/en/privacy_faq_2010.html

<comment><USER2> This is saying why they are changing the Privacy Policies (they are deleting product-specific Privacy Policies and using the Main Privacy Policy), the actual policy is here:

<http://www.google.com/intl/en/privacypolicy_2010.html></comment>


Apple Explains Mysterious iPhone 11 Location Requests - <AUTHOR> https://krebsonsecurity.com/2019/12/apple-explains-mysterious-iphone-11-location-requests/ <comment><USER2> The surprisingly positive aspect of this is that a piece of system software which is checking for location, which there is no toggle for in System Services, which nobody even new existed at all...

...still makes the the Location Services icon flash! The Location Services icon _really does_ flash when _anything_ uses Location Services, apparently.

This is no trivial thing to be thankful for, and hardly something I'm confident will be universally true forever.

<comment><USER3> Yeah, there's been cases where "This light means the webcam is active" and "This hardware switch toggles the WiFi on and off" were overridable.

Well, then again, I don't want an Alexa or Google Home, but I don't mind having an always-on Android phone with a microphone and 2 cameras...

<comment><USER4> > I don't mind having an always-on Android phone with a microphone and 2 > cameras...

I'm not happy that I don't have the option of a hardware switch to disable the cameras and mics on a phone, but I can do everything a smart speaker does without bugging my home in the process.

If a company like samsung, LG, or Motorola offered a phone that really took user privacy seriously I think they'd find a lot of people would be interested, but until then I just have to assume my phone is spying on me at all times and I limit how I use it and what data I enter into it as a result.

<comment><USER5> > I'm not happy that I don't have the option of a hardware switch to disable > the cameras and mics on a phone

Librem 5 is the phone you're looking for. Or a Pine Phone.

<comment><USER4> I've looked into Librem phones from time to time over the years and every time I check the phones are unavailable, usually back-ordered. I'm sure they've managed to ship something at some point but I haven't seen anyone IRL who has one. Pine seems to be about the same (maybe available next year although even then you'll likely be using an OS that's in beta). Not encouraging.

As much as I'd love to support these kinds of products they just don't seem ready.

<comment><USER6> If you prefer a bit of OS polish while Librem improves, why not using AOSP on a Pixel or Xperia device?

<comment><USER4> It'll be some time before I replace my current device, but once I do I'll be looking for something that supports LineageOS or Replicant although that'd still leave the hardware suspect.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This brings up an issue I wish iOS and Android would solve. Location data is always very specific, as accurate as GPS or Cellular triangulation can offer (down to the centimeter in some cases). However the vast majority of use-cases don't need this level of precision. Maybe Maps for accurate directions require this, but rarely anything else. In this case the OS simply needs to know what country you are in, not what street corner you are on.

Why can't apps request less precise location data, and maybe let the user choose this? Another common example is Twitter, Facebook, Instagram, and even dating apps, don't need to know your location with precision, they usually just want the city or zip code with relative accuracy. My Weather app doesn't need to know what rock I'm standing next to for accurate forecasting.

<comment><USER8> iOS apps definitely do have this granular option. It's been around since iOS 2 SDK.

[https://developer.apple.com/documentation/corelocation/clloc...](https://developer.apple.com/documentation/corelocation/cllocationmanager/1423836-desiredaccuracy)

<comment><USER9> Very interesting. But when an app requests location permissions, it's still the same message right?

There's no way of knowing whether the app will be using your exact location, or just the city you're in?

<comment><USER10> Correct. Room for improvement would be giving users the option to see this and select/approve it.

<comment><USER11> I'd also want the option to choose any location as the location my phone sends to that app. I'd give each app a different city near me (when precision isn't that important) just to add more noise to my precise location.

<comment><USER12> As someone who jealously guards their personal data, I agree with you.

As a product manager/designer, I think that would end in disaster for any consumer-facing company that implemented it. The number of people who would enter random places, forget they did so, and then complain that their phone is broken or the app doesn't work would be _staggering._

<comment><USER13> Android has supported this for ages, just not customized per app. they put it under dev options, i guesd to mitigate the demented user problem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> ...y'know what I find particularly nuts about this whole thing? That we only know about it because of that location icon in the status bar. Apple could have chosen to hide that icon for certain types of requests, and this story wouldn't exist.

I really hope that after this update is released, someone with checkm8 goes and checks what has _actually_ changed. Not because I distrust Apple per se, but because we shouldn't be making discoveries based on a cosmetic icon.

Also, thank god for checkm8.

Edit: donkeyd, below, reminded me that this behavior is only on the iPhone 11, which isn't vulnerable to checkm8. Sigh...

<comment><USER15> > ...y'know what I find particularly nuts about this whole thing? That we only > know about it because of that location icon in the status bar

It seems to me like discovering this from that status bar icon is a _good_ thing. It gives me more faith that the system isn't hiding particular types of calls from the user; that it's tying the system call to the icon being present.

<comment><USER16> Yes and no. One of the results of iPhone 4's "antennagate" is that Apple changed the way the phone signal is displayed. They changed the algorithm, and made the signal bars more prominent in low signal situations [1]

I'm not suggesting they will change its behavior, but it wouldn't be unprecedented if they did.

EDIT: Changed the video start time to specific reference.

[1] [https://youtu.be/b9eXYOA8TCk?t=672](https://youtu.be/b9eXYOA8TCk?t=672)

<comment><USER17> That was the first time I actually watched that conference.

Steve Jobs presents a convincing case. It's now clear to me that the media hyped up a non-issue, or at least one that was ubiquitous across the state of the art at the time. And Apple's response is perfectly reasonable.

What exactly is your problem with his explanation of the changes?

<comment><USER16> I have no problem or strong opinion regarding iPhone 4's antenna debacle, I'm only referencing what has happened in the past about issues hyped by the media, and how Apple has handled them.

iPhone 4/4s remain my favorite iPhone generations to date.

</comment></comment></comment></comment></comment><comment><USER18> As I mentioned on the previous story about this, my phone checking where it is doesn't bother me. My phone sharing my location without me knowing does bother me.

I'm far more bothered by the fact that my Roomba requests location data than I am this. Seriously Roomba, WTF.

<comment><USER19> Sometimes checking is sharing.

I think there are ways to design APIs to be more private, but noone seems to do it.

For instance, one way to figure out your time zone is to send your location to a server, which will return the time zone.

Another more private way might be to load a list of location vs timezones for a region of the US, then calculate your timezone locally.

<comment><USER20> I implemented something like this a couple years ago and the geometry files used for timezone lookup were surprisingly large (~200 MB at decent precision)! I ended up simplifying the geometries drastically to minimize data requirements and compute burden of the lookups, but if you need higher precision, server reverse geocoding may be your only option in constrained environments.

<comment><USER19> On the other hand, with my example the timezone data can be stored and used locally until you leave the region.

</comment></comment></comment></comment><comment><USER21> This is because Apple is silently building a survailance network for lost devices, the UWB chip in the iPhone 11 is also in the Airpods Pro and will be on all future Apple things. Say I leave my Airpods pro in the conference room of an office I was at earlier for a job interview... with Apple's UWB magic, any iPhone 11 can be used to find my airpods, not just mine... This is for locational discovery of all future apple devices, this mesh network allows someone to use your device as the exit to apples location servers.

<comment><USER22> How do we not know that they would only allow discovery of devices linked to your Apple account?

<comment><USER23> If you read the white paper it makes it clear that location information isn't limited by policy (permissions, etc), but rather by actual cryptographic techniques that need your devices to access. It is designed so that you can always have find my X working without simultaneously requiring your (unencrypted) location being sent to apple.

<comment><USER24> The only way we will know that those claims are remotely true is if they release spice code. Until then, how can we know?

<comment><USER23> I mean if you're unwilling to accept a published document from them, then you can't accept any claims by any company. Including Google + Android.

At least, unlike android, iOS indicated that the location system was being used.

<comment><USER25> Android shows this. Not sure why Android is relevant in this thread, seems like a pivot

</comment></comment></comment></comment></comment></comment><comment><USER26> I never get why cell phones don't have the indicator light that tells you the camera is on. Ideally this light would be physically linked to the power going to the camera and the light would be impossible to disable without physically altering the device. I'd like the same for the microphone. I think location based stuff is a little more instantaneous in turn harder to accomplish but generally speaking more indicators that cannot be disabled with software tightly coupled with sensors potentially violating our privacy.

<comment><USER27> > I never get why cell phones don't have the indicator light that tells you > the camera is on.

Reduces BOM, manufacturing cost, board space needed, and battery drain to exclude it.

LEDs on phones were all the rage (at least one Blackberry model had an LED accessible by apps IIRC) until Apple took the market by storm and then everyone started copying their aesthetic.

> Ideally this light would be physically linked to the power going to the > camera and the light would be impossible to disable without physically > altering the device.

There's no way for you to verify unless you built the camera yourself or can remove the camera.

<comment><USER28> Many phones have LEDs but do not have software support for it. Sometimes it goes a long time before someone recognizes that a LED hides in the speaker grill and then boom, someone writes an app to enable it. The manufacturer was contempt with adding a LED to a device and not caring if it ever was used. Cost was not part of it.

Even google, on it's nexus 5, had a LED. A prominent RGB LED that could do everything you ever wanted. Well, unless you relied on google for the software which if possible made it worse than if it hadn't existed.

Then you open up the phone to replace the dying battery. And behold, multiple SMA type connectors for external antennas(?) One wonders if a single person on earth found a use for them. Cost optimization don't seem to be that important.

Now for the camera LED I don't think phone manufacturers want to even admit that it is something anyone should be worried about. So their strategy is likely to pretend that there doesn't even exist any issues to worry about. Probably works out pretty well for them.

</comment></comment></comment><comment><USER29> It is astonishing to me, that one of the best known IT security researchers has to rely on a flashing icon to determine if location services were used or not.

Apple could easily disable said icon in certain cases. This begs the question: Isn't there a more reliable way to determine if an iPhone uses location services and maybe even say for sure for what they are used?

<comment><USER30> Absolutely. You can reverse engineer components of iOS to find this out, and analyze outgoing network traffic as a quick way to see what data is going out to remote servers.

The icon, in this case, was a helpful indicator allowing others to easily reproduce this test in minutes.

</comment></comment><comment><USER31> "The management of Ultrawide Band compliance and its use of location data is done entirely on the device and Apple is not collecting user location data."

Call me paranoid, but this statement is telling us that:

"The management of UWB compliance and the management of its use of location data is done on the device" \-- which okays that the data can be used outside the device, only the management needs to be done on the inside,

"Apple is not collecting user location data." \-- which could mean that some other parties (not Apple) _could_ collect user location data.

</comment><comment><USER32> The thing that I find amusing is that we are talking about an implementation of Google's own White Spaces initiative that is working as intended.

To use the same frequency band allocated to uses like television and radio broadcasting without interference, you need a way to know which frequencies are already in use by the local stations at your location.

>So-called "white space" frequencies have considerable benefits when compared to traditional Wi-Fi signals, and now Google has created an API to make the process of utilizing them easier. Companies using the Spectrum Database API will be able to search for frequencies unoccupied by TV or radio signals in specific areas of the United States, and register equipment that uses those frequencies to broadcast wireless internet.

Google has championed unlicensed TV white space (TVWS) over the last few years. The FCC approved the use of Google's TVWS database in June, after tests began in March.

[https://www.theverge.com/2013/11/15/5106218/google- database-...](https://www.theverge.com/2013/11/15/5106218/google-database-api- brings-white-space-broadband-closer)

Apple appears to be doing nothing more than querying a local copy of the database to look up which frequencies must be avoided at the current location.

All the Android phones that adopt ultra wideband technology will have to do the same thing.

<comment><USER33> UWB is not White Spaces.

White Spaces was a plan to make frequencies once allocated to analog TV broadcasters unlicensed (similar to the existing ISM bands). This would give things like WiFi access points more spectrum to use, without fundamentally changing how the protocols worked. (Same signal, different RF frontend for the new frequencies.)

UWB is a very low-power spread-spectrum technique. It decreases power and increases the bandwidth used to achieve a usable channel capacity. The idea is that the power is so low that it won't interfere with licensed users, even though it's using licensed frequencies. The downside is that it's a lot more complicated and requires new hardware and electronics techniques to implement. (I assume the reason it's disabled in some regions is because they haven't convinced the relevant authorities that it doesn't actually interfere with licensed users while using their spectrum.)

</comment></comment><comment><USER34> The previous related thread: [https://news.ycombinator.com/item?id=21699576](https://news.ycombinator.com/item?id=21699576)

</comment><comment><USER35> This is simply a case of a new system service of which there are many: Location, Photos, Calendar, etc. and now, Ultra Wideband (UWB), being rolled out without being tied into the existing permission model.

[https://developer.apple.com/design/human-interface- guideline...](https://developer.apple.com/design/human-interface- guidelines/ios/app-architecture/requesting-permission/)

</comment><comment><USER36> If Apple introduces tile like competitor, would it lower the threshold for creepy and stalky folks to track others? Would it be as easy and slipping in a Apple Tile and its location be crowdsourced back to Apple and therefore to the stalker?

<comment><USER21> Yep, it's a beta called B389

<comment><USER30> Technically, that is the hardware product codenames (Closely tracking with AirPods it seems, B188 and B288)

</comment></comment></comment><comment><USER37> This is actually awesome. If Apple wanted they could have made the indicator not show up at all when that feature uses location. This means they are staying true to the promise.

</comment><comment><USER38> Location-check icon still appears on iPhone 11 when Airdrop is disabled via Apple Configurator policy and location permission denied for all Apple system services.

Is UWB used for features other than Airdrop? Location reporting of nearby tags/devices?

One avenue of investigation would be to capture all iPhone 11 traffic via VPN (e.g. Charles Proxy) and correlate network traffic with appearance of the location indicator.

<comment><USER30> This test would not yield a useful result in this particular case, as the data is processed locally on-device and is not sent to a remote server.

</comment></comment><comment><USER39> in other words: "yes we can have your location at any time, and we are not collecting the data, I promise!"

<comment><USER40> Turning off Location Services completely still turns this off. There is just no specific switch to turn only this off (so if you turn off all the other specific switches, this stays on).

</comment></comment><comment><USER41> I seem to have missed something:

Apple claims Location Services cannot be disabled because it is needed for Ultrawide Band (UWB) compliance.

And what about UWB? It cannot be disabled either? Do you have a say if someone wants to send you a file 'simply by pointing at your iPhone'?

<comment><USER33> Airdrop is not a new feature. You can whitelist people that can use it on you.

</comment></comment><comment><USER42> It seems that the answer raises even more of an eyebrow than the original question... why is UWB active in devices if no end-user application can yet benefit from it?

<comment><USER43> AirDrop already benefits from it.

<comment><USER44> Does iOS still make location requests when AirDrop is turned off?

<comment><USER38> Yes, [https://news.ycombinator.com/item?id=21719040](https://news.ycombinator.com/item?id=21719040)

</comment></comment></comment></comment><comment><USER45> _"Ultra Wideband technology is an industry standard technology and is subject to international regulatory requirements that require it to be turned off in certain locations," the statement continues. "iOS uses Location Services to help determine if iPhone is in these prohibited locations in order to disable Ultra Wideband and comply with regulations. The management of Ultrawide Band compliance and its use of location data is done entirely on the device and Apple is not collecting user location data."_

Ridiculous. The phone always knows very well what country and what regulatory region it's operating in. Otherwise, how could it know what cellular bands to use?

<comment><USER40> > _Otherwise, how could it know what cellular bands to use?_

By passively listening for what bands are being broadcast on? I mean, dumb phones without any kind of location support whatsoever could do that, without determining what regulatory region they are in.

<comment><USER45> _By passively listening for what bands are being broadcast on?_

Exactly, that's my whole point. Obviously I didn't make it clearly enough.

Are you in the 0.0001% of the planet's populated area where the local cell network doesn't tell you roughly where you are? Fine, _then_ turn on location services. That's almost never going to be the case.

</comment></comment></comment><comment><USER46> The only way to ensure location privacy is to interfere with GPS. When you wish to use the location feature, turn off the GPS interference. As such technique is pretty esoteric, it's unlikely Apple will develop counter techniques until it becomes more popular.

As has been mentioned before, relying on some icon on your screen is rather naive unless Apple has provided some legal assurance that we can.

It would be a good question to pose to Apple - can the icon be overridden to not be shown or shown so quickly that it is effectively invisible?</comment>


Ask HN:  I have a FaceBook Group with 100,000 People In It...now what? - <AUTHOR> http://www.facebook.com/#/group.php?gid=2269355003&ref=ts

<comment><USER2> Make a pamphlet, sell it on <http://www.lulu.com/>

Make an app to gift it, so friends can criticize eachother's shotgun habits with a social gesture

Is the goal monetization? Because if not, you might already be done.

</comment><comment><USER3> Check out this interview on Mixergy: <http://mixergy.com/jeff-widman- brandglue/>

The founder of BrandGlue talks about groups vs fan pages and how to effectively market to your followers on facebook. Some interesting tips about how to get your group mentions into other people's news feeds.

</comment><comment><USER4> Maybe you could let people create their own customized "House Rules" reference card for their car, maybe as a sticker they could attach to their passenger window or something.

        $12 * 100,000 * 0.05 = $60k

<comment><USER5> Randomly multiplying a sample by an arbitrary "small" percentage is a terrible way of demonstrating profit potential.

Unless you can demonstrate otherwise, the correct calculation is: $12 * 100,000 * percentage of people that are your mum = $0-$24

<comment><USER6> Exactly. People only have to convince 0.0000000001% of a 6B person market to marry them, but it's still a hard thing to do.

<comment><USER7> Actually, I bet I could convince at least 1/100 of that group to marry me. It's the mutual compatibility that's the problem.

</comment></comment></comment></comment><comment><USER8> Perhaps fix the link at <http://www.shotgun.com>

<comment><USER9> I was going to say, nice domain! ;)

</comment></comment><comment><USER10> Write the book and sell it to them...

[http://www.fourhourworkweek.com/blog/2009/12/08/no-more- excu...](http://www.fourhourworkweek.com/blog/2009/12/08/no-more-excuses-how- to-make-an-extra-100000-in-the-next-6-months/)

</comment><comment><USER11> The domain (Shotgun.com) would be more valuable then the group, wouldn't it?

In any case, throw up an online shop on it, posters, pamphlets, coffee table book, bumper stickers. See if any of it sells.

<comment><USER12> He's linking to that domain, doesn't mean that he owns it.

<comment><USER11> OK. Why linking to that domain?

</comment></comment></comment><comment><USER13> Christmas/Holiday gifts seem like the obvious choice. I would definitely buy a poster for my brother with the rules of shotgun on it (if it was funny). Not sure if you can put it together in time.

</comment><comment><USER11> Found this site: shotgunrules.com

It uses the same text & sells a pocketbook.

</comment><comment><USER14> Write an ebook on how to create a facebook group and get it up to 100,000 people.

<comment><USER2> no, do not become a social media consultant.

that path to hell is paved with the carcasses of trampled douchebags.

</comment></comment><comment><USER15> Get suggestions from them then make an book that can be sold at urban outfitters

</comment><comment><USER16> I suppose there's already a shotgun iPhone app. Or twenty.

</comment><comment><AUTHOR> Anyone have any ideas? I was thinking maybe taking the content from the group and making a 'Rules for Calling Shotgun" Pocket book (that people could keep in their cars). Everyday I get a facebook message from 1 or 2 people who want me to put their information on the 'group details' page... but anyone know of anyone or have any other ideas?

Thanks.

<comment><USER17> The path of least resistance: buy a new domain, create a Shotgun Rules wiki on it, enable Adsense, and link to it from your page.</comment></comment>