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

71–80 of 124 posts

Re: The Design of Software is a Thing Apart

#71

Post by jiggunjer »

hinkley wrote: post #67
Chiba-City wrote: post #45

This is a lovely article. Software is a possibly a) errant and b) misinterpreted operational semantics of some other semantic horizons of contractual or implicit expectations. Knuth's Literate Programming was onto something. We inhabit a world of word problems and even faulty realizations of rarer formal specifications. Claims concerning "phenomena in the world" drive maintenance and enhancement regimens.

Worse still, most of us walk around under the delusion that we know what we want while others can see it doesn’t make us happy. How do you get the product you want when you don’t know what you want?

Just buy Apple. They know what you want.

Re: The Design of Software is a Thing Apart

#72

Post by azernik »

jacobolus wrote: post #59
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

The biggest problem is when users of software, programmers of software, and the software code itself have 3 different incompatible theories of how it works. Sometimes it gets worse still: you can have different theories according to (a) scientists doing basic research into physics or human perception/cognition, (b) computer science researchers inventing publishable papers/demos, (c) product managers or others making…

This is why during software design the first thing I talk about is not the UX flow or the software architecture, but the user's mental model (or the mental model we want to give them).

Re: The Design of Software is a Thing Apart

#73

Post by azernik »

kbenson wrote: post #61
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…

> If you don't explain in documentation (e.g. comments) why you went the more complicated route, someone might come along and "simplify" things to incorrectness, and the best case is they'll rediscover what you already knew in the first place, and fix their own mistake, wasting time in the process. I've done this to myself . It sucks. Revisiting years old code is often like reading something someone else entirely wro…

Reminds me of the theoretical model of stored-data encryption - it's the same as encrypting communication, only you're sending data from your past self to your future self :-D

Re: The Design of Software is a Thing Apart

#74

Post by kazagistar »

squeaky-clean wrote: post #56
jph wrote: post #39

Earlier quoted context omitted.

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

Old and somewhat contrived example, but the first thing to pop into my head is the famous fast inverse square root function. float FastInvSqrt(float x) { float xhalf = 0.5f * x; int i = *(int*)&x; // evil floating point bit level hacking i = 0x5f3759df - (i >> 1); // what the fuck? x = *(float*)&i; x = x*(1.5f-(xhalf*x*x)); return x; } I can't think of a way to write a test that sufficiently explains "gets within a c…

Write a property based test, ie generate a bunch of random inputs, then assert that all of them are within some (loose) margin of error.

Re: The Design of Software is a Thing Apart

#75

Post by maxerickson »

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 guess that is at least sort of what they are working on at VPRI.

http://www.vpri.org/

Re: The Design of Software is a Thing Apart

#76

Post by robotresearcher »

coldtea wrote: post #52
robotresearcher wrote: post #47

Earlier quoted context omitted.

(Ignoring the typo "A" != 'A') return x >= 'A'; already and only means ascii A. Is there a C compiler anywhere where or likely in future where 'A' in C is NOT ascii A? The comment is redundant if correct, and could be wrong after an edit, so it has no value.

> return x >= 'A'; already and only means ascii A. See, here's where you are wrong. ASCII_A = "A" alphas = ["Α", "А", "Ꭺ", "ᗅ", "ꓮ", "Ａ", "𐊠", "A", "𝐀", "𝖠", "𝙰", "𝚨", "𝝖"] for c in alphas: print c == ASCII_A Output? False False False False False False False True False False False False False Several of the numerous possible utf-8 alphas. Those are not A in different fonts -- they are different unicode characte…

I deliberately used the character literal ‘A’ and not any of your UTF8 strings. I think you are mistaken to confuse a character with your strings. Is this wrong?

Re: The Design of Software is a Thing Apart

#77

Post by fiddlerwoaroof »

jiggunjer wrote: post #71
hinkley wrote: post #67

Earlier quoted context omitted.

Worse still, most of us walk around under the delusion that we know what we want while others can see it doesn’t make us happy. How do you get the product you want when you don’t know what you want?

Just buy Apple. They know what you want.

You may be joking, but I think the way in which this is true explains Apple’s success, even though they’ve generally released products that are less featureful and significantly more expensive than their competition.

Re: The Design of Software is a Thing Apart

#78

Post by zb »

coldtea wrote: post #18
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.

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

You must be one of those people who writes stuff like #define TWO 2

Re: The Design of Software is a Thing Apart

#79

Post by taneq »

jacobolus wrote: post #59
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

The biggest problem is when users of software, programmers of software, and the software code itself have 3 different incompatible theories of how it works. Sometimes it gets worse still: you can have different theories according to (a) scientists doing basic research into physics or human perception/cognition, (b) computer science researchers inventing publishable papers/demos, (c) product managers or others making…

This is why dogfooding is so important - you're updating the programmers' model to align with the users' model, reducing the total problem space (and thus the available avenues to get it wrong) by many degrees of freedom.

Re: The Design of Software is a Thing Apart

#80

Post by taneq »

hinkley wrote: post #66
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…

Probably four times a year I find out that defending my bad decision in writing takes more energy than fixing it. You start saying you did X because of Y, and Y is weird because of Z, and so X is the way it is because you can’t change Z... hold on. Why can’t I change Z? I can totally change Z. Documentation is just the rubber duck trick, but in writing and without looking like a crazy person.

I do the same. If I'm finding it too hard to describe what I'm trying to achieve in a one-liner comment, I'm probably doing something wrong.

Also, writing it down lets someone else, later, take the role of the duck and benefit from your explanation to yourself.

Post reply on HN