Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

Post reply on HN
Print view View original

81–90 of 172 posts

Re: The Danger of “Simplicity”

#81

Post by karmakaze »

cytzol wrote: post #56
codingdave wrote: post #12

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,…

> "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, bu…

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.

Re: The Danger of “Simplicity”

#82

Post by mbrock »

frou_dh wrote: post #11
mbrock wrote: post #6

Earlier quoted context omitted.

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.

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

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).

Re: The Danger of “Simplicity”

#83

Post by empthought »

ken wrote: post #52
panpanna wrote: post #30

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...

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…

You can also use structs and preprocessor macros. Have a look at the PostgreSQL source sometime.

Re: The Danger of “Simplicity”

#84

Post by hashmal »

brlewis wrote: post #38

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.

Yes, I worked in teams where "YAGNI" would come up all the time, preventing any kind of actual code design/architecture.

Every time YAGNI is mentioned, it should be put against code quality (maintainability, readability, testability, etc) because they are often opposite/fighting concepts: code quality, in the end, is all about making (not yet known) changes easily, which means you have to anticipate different possible futures.

The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start.

Re: The Danger of “Simplicity”

#85

Post by hyperpallium »

ajdegol wrote: post #14
blondin wrote: post #8

Earlier quoted context omitted.

wouldn't say simple is the opposite of complex though? especially when talking about software systems or other systems in general. what i am thinking is that some complex systems can be made of very simple components. the best example is our complex brain being made of simpler components working together. maybe the opposite of complex is chaotic? i don't know...

Simple systems can indeed be made of complex components; however it is a measure of interconnectedness. The key concept is that we can only hold a finite amount of complexity in our heads at any one time, and so if we can minimise that we can be more efficient and effective. The analogy is a lego castle vs a wool castle. A lego brick is very simple and contained, and from this you can build wonderful structures; in a…

"Interconnectedness" is also a measure of resistence to hierarchical decomposition (or factoring ax+bx -> (a+b)x); irreducable complexity.

One technique is redefining the problem, to smaller or bigger:

Work on only part of a problem, a subset, leaving something out. e.g. git's data model does not represent renames as first class constucts, enabling it to be disproportionately simpler.

Expand the problem, a superset, to integrate lower or higher level or associated parts that aren't usually included. Previously scattered commonalities may then appear, enabling decomposition.

Re: The Danger of “Simplicity”

#86

Post by chasd00 »

theaeolist wrote: post #53

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.

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.

Re: The Danger of “Simplicity”

#87

Post by paggle »

mumblemumble wrote: post #76
leggomylibro wrote: post #18

Earlier quoted context omitted.

I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" She really wanted to drill the idea into our heads that just because you know exactly how to do something, doesn't mean that it will be quick or easy to accomplish. Like, for a schoolchild, long division. The rules are simple, but given big enough numbers you'll probably mess up at least once. And th…

> I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" I can imagine no more poetic description of the experience of reading Wolfram's A New Kind of Science .

Can you elaborate?

Re: The Danger of “Simplicity”

#88

Post by breck »

> 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/...

Re: The Danger of “Simplicity”

#89

Post by brlewis »

ninkendo wrote: post #65
brlewis wrote: post #38

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.

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 wi…

https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

Re: The Danger of “Simplicity”

#90

Post by haolez »

cytzol wrote: post #48
haolez wrote: post #17

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.

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 si…

That’s true, but there are a lot of beautiful and featureful programming languages out there, and possibly only Go in the “simplicity above features” camp. I disagree with the move towards Go 2 by introducing genetics and whatnot. If I really want those features, I know where to get them.
Post reply on HN