The Design of Software is a Thing Apart

Post by jopsen » Wed, Jan 17, 2018, 7:59 AM UTC

borplk wrote: post #29

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.

See my recent comment: > We need model based editing environments that will allow us to have a much richer set of software building blocks. https://news.ycombinator.com/item?id=16117668

    // can be imported, and api.router() mounted in express
    let api = new API(...);
    module.exports = api;    

    api.declare({
      method: 'get',
      route: '/hello-world',
      description: `bla bla bla...`,
      scopes: {AnyOf: ['some-permission-string']},
      // (more properties)
    }, (req, res) => {...});

Post by kbenson » Wed, Jan 17, 2018, 8:42 AM UTC

jph wrote: post #85

kbenson wrote: post #62

Earlier quoted context omitted.

Do you think this still holds true if you name all your tests in the format test1, test2 ... testN? If not, then you're in the realm of documentation, not tests, and the descriptive names (which is a form of metadata, just as comments are) of the tests are what is communicating these special cases, and not the test content itself. Combining the two is good, but let's not act like the tests themselves immediately solv…

My opinion is that test names, function names, variable names, constant names, high level languages, literate programming, and well written commit messages, all help code to be understandable; I'm fully in favor of all using all these in source code and also in commit messages. My experience is that documentation is generally a shorthand word that means non-runnable files that do not automatically get compared to the…

Post by Chiba-City » Wed, Jan 17, 2018, 9:58 AM UTC

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?

Post by rimliu » Wed, Jan 17, 2018, 10:09 AM UTC

fooblitzky wrote: post #57

The OP doesn't seem to understand TDD: "So you update the code, a test fails, and you think “'Oh. One of the details changed.'" Some of the concerns they raise about writing tests are covered by Uncle Bob here: http://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrava... and here: http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTD...

Post by reacweb » Wed, Jan 17, 2018, 10:57 AM UTC

tome wrote: post #96

squeaky-clean wrote: post #83

Earlier quoted context omitted.

This doesn't satisfy the time constraint though. return 1.0f / sqrt(x) Passes a property based test but now your game doesn't actually run because it's much too slow of an operation on hardware at that time. You can also test execution time too, but that's finicky and doesn't help explain how to fix it if you break that test (if there's no accompanying documentation).

But at this point all you're saying is "I can't think of a way of testing performance".