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

The Design of Software is a Thing Apart

pathsensitive.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: The Design of Software is a Thing Apart

#31

Post by fallous »

mpweiher wrote: post #2

the information of a program’s design is largely not present in its code And that's the problem. We need ways to make those higher level designs (~architecture) code.

I'm not sure that's possible in any truly meaningful way. Design is a very high level of abstraction that expresses a world, a particular view of that world with regards to a general set of problem domains, and a set of principles and theories about acting within that world. Code is a means (and not the only means) of achieving those actions.

This is not unlike the domains of philosophy, morality, ethics, and law. Attempting to express or enforce philosophy and morality via legalism is an exercise in futility, and even ethics which appears to be on the same level as law actually isn't since the presumption of ethics is behavior even in the absence of a law.

Re: The Design of Software is a Thing Apart

#32

Post by robotresearcher »

coldtea wrote: post #19
robotresearcher wrote: post #17

Earlier quoted context omitted.

Sure, I understand. The surrounding code would include the type of x, which, if char, would help understanding even more. But you’re channeling some crazy madness suggesting that someone would use ‘A’ to mean 65. Shudder. I guess we’ve all seen some horrors over the years.

> But you’re channeling some crazy madness suggesting that someone would use ‘A’ to mean 65. Or just an encoding scheme.

Where 65 means ‘A’? Madness.

Re: The Design of Software is a Thing Apart

#34

Post by sheepmullet »

vlovich123 wrote: post #15
robotresearcher wrote: post #7

return x >= ‘A’; Would be better than return x >= ASCII_A; surely. ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose.

In this strawman example, perhaps. However, code is usually surrounded by other code. So you could have the 'A' in multiple places. By using an explicit identifier you are protecting yourself against typos (depending on the language, it could be a compile-time error or at worst a very clear runtime error instead of a logic error). The other benefit of ASCII_A is that you are signalling that you are doing ASCII compar…

> The negative drawbacks of extracting constants is typically minimal

> ASCII_A

It comes down to naming and purpose.

The example, ASCII_A, is terrible because it doesn't describe the purpose with its name.

What will end up happening in any large codebase is ASCII_A will get reused in dozens of different places for dozens of different reasons.

If it was named minValidLetterForAlgorithmX it would convey intent and its more likely to be used correctly.

Re: The Design of Software is a Thing Apart

#35

Post by runevault »

panic wrote: post #5

Peter Naur's "Programming as Theory Building" also addresses this topic of a "theory" which is built in tandem with a piece of software, in the minds of the programmers building it, without actually being a part of the software itself. Definitely worth a read: http://pages.cs.wisc.edu/~remzi/Naur.pdf

Thanks for linking this, don't think I'd ever seen it before and as someone who's a second generation holder of a very large system's underlying theory it feels extremely accurate, but puts things into terms I never considered before.

Re: The Design of Software is a Thing Apart

#36

Post by mannykannot »

Chaebixi wrote: post #8

> Those who speak of “self-documenting code” are missing something big: the purpose of documentation is not just to describe how the system works today, but also how it will work in the future and across many versions. And so it’s equally important what’s not documented. Documentation also (can) tell you why the code is a certain way. The code itself can only answer "what" and "how" questions. The simplest case to sh…

The "why" is actually more relevant to the point made in the article title than "how it will work in the future and across many versions."

Re: The Design of Software is a Thing Apart

#37

Post by mannykannot »

phkahler wrote: post #23
coldtea wrote: post #18

Earlier quoted context omitted.

> ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose. I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g. const ASCII_A = 'A' // correct const ASCII_A = 'E' // wrong So: return x >= ASCII_A tell us the in…

return x >= "A"; // ascii A Gets the whole message across in one line, as does using 65 with the comment.

Be careful with your quotes (depending on which pseudo-language this is.)

Re: The Design of Software is a Thing Apart

#38

Post by vageli »

robotresearcher wrote: post #32
coldtea wrote: post #19

Earlier quoted context omitted.

> But you’re channeling some crazy madness suggesting that someone would use ‘A’ to mean 65. Or just an encoding scheme.

Where 65 means ‘A’? Madness.

A is 65 in ASCII. http://www.asciitable.com

Re: The Design of Software is a Thing Apart

#39

Post by jph »

Chaebixi wrote: post #8

> Those who speak of “self-documenting code” are missing something big: the purpose of documentation is not just to describe how the system works today, but also how it will work in the future and across many versions. And so it’s equally important what’s not documented. Documentation also (can) tell you why the code is a certain way. The code itself can only answer "what" and "how" questions. The simplest case to sh…

> Some might claim unit tests will solve this

Yes. Tests will solve this. Your point is perfect for tests.

If another experienced coder cannot comprehend from the tests why something is wrong, then improve the tests. Use any mix of literate programming, semantic names, domain driven design, test doubles, custom matchers, dependency injections, and the like.

If you can point to a specific example of your statement, i.e. a complex method that you feel can be explained in documentation yet not in tests, I'm happy to take a crack at writing the tests.

Post reply on HN