The Design of Software is a Thing Apart
pathsensitive.com
The Design of Software is a Thing Apart
1–10 of 124 posts
Re: The Design of Software is a Thing Apart
#2the 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.
Re: The Design of Software is a Thing Apart
#3the 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.
It seems kind of magical to be able to encode the intent of a program outside of its actual function. Theoretically this is what comments are for, but obviously those have zero enforcement value at the compiler level.
Re: The Design of Software is a Thing Apart
#4the 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.
This is the problem that I've run into trying to use formal methods.
I love them, I can express some things very concisely and even clearly. But there's no direct connection to the code and so keeping things synchronized (like keeping comments synchronized with code) is nigh impossible.
We need the details of these higher level models encoded in the language in a way that forces us to keep them synced. Type driven development seems like one possible route for this, and another is integrating the proof languages as is done with tools like Spark (for Ada).
This will reduce the speed of development, in some ways, but hopefully the improvement in reliability and the greater ability to communicate purpose of code along with the code will also improve maintainability and offset the initial lost time.
And by keeping it optional (or parts of it optional) you can choose (has to be a concious choice) to take on the technical debt of not including the proofs or details in your code (like people who choose to leave out various testing methodologies today).
Re: The Design of Software is a Thing Apart
#5Peter 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
Re: The Design of Software is a Thing Apart
#6I misread the title as "the design of software is a thing of the past". I welcome the actual title and content though.
Re: The Design of Software is a Thing Apart
#7return 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.
Re: The Design of Software is a Thing Apart
#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 show this is a function with two possible implementations, one simple but buggy in a subtle way and one more complicated but correct. 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.
Some might claim unit tests will solve this, but I don't think that's true. All they can tell you is that something is wrong, they can't impart a solid understanding of why it is wrong. They're just a fail-safe.
Re: The Design of Software is a Thing Apart
#9I wish websites wouldn't change the browsers default scrolling behavior
Re: The Design of Software is a Thing Apart
#10return 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.
There's the theory that any hardcoded constant directly in code is bad idea. It may be used more than once, or used only once now, but in the future used more than once, or in the future the value may be changed and if it's used more than once, this is a source of issues.