Home > Archive > Compression > August 2007 > Good software development, a bit like "compression"?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Good software development, a bit like "compression"?
|
|
| collection60@googlemail.com 2007-08-09, 6:56 pm |
| Hows this for a software development idea?
Now, good code generally is tight code. The smaller the better,
because less code means less bugs.
Once you start copy/pasting lines all over the place, you start
getting unmaintainable code because you need to fix bugs in every
place you've copy/pasted the code!
And in general, the idea is to basically "identify patterns" in your
code. Where two pieces of code are doing mostly the same thing, so
much similar that they can be "refactored" out into their own helper
function, which just gets called with different parameters.
Just that description there, is 90% of software development summed
up ;)
So... isn't this similar to the idea of compression?
A good software developer, should create code with minimal repetition.
And a good compressor, creates a compressed file with minimal
repetition :)
Interesting connection eh?
Does that mean that many of the approaches that compressors use, could
help software developers? Or does it mean that many of the approaches
*good* software developers use in writing software, could help (or are
already helping) in making good compressors?
Does it mean that good software, is harder to compress? I'd say yes,
the better the code, the harder it is to compress it.
Obviously this assumes all other things are equal. For example you
don't have two apps, the "good" one being compiled for speed and the
"Bad" one being compiled for small size, and the optimiser creating so
much repetition for speed's sake that it throws off the comparsion.
I think a "good software developer" is good at identifying patterns.
So if he can see that in his code, there are many patterns in repeated
code, he can eliminate them. This way, he has "compressed" his app,
and made it smaller, tighter, less buggy, more maintainable.
Also, "compressing" is actually all what software is about! A software
developer's "function" is like a "word" in a compressor's dictionary.
By writing that function once, he doesn't have to write it 1000x over.
This "compresses" the time spent in developing the software! So a good
developer writes "compressed" software in a "compressed time
schedule".
Interesting ideas :)
| |
| Hans-Peter Diettrich 2007-08-09, 9:56 pm |
| collection60@googlemail.com wrote:
> A good software developer, should create code with minimal repetition.
Let repetition = redundancy.
Unfortunately simple typos are hard to detect, without redundancy. A
formal and general compression only can cover syntactic aspects, not the
semantics behind them.
DoDi
| |
| Claudio Grondi 2007-08-10, 6:56 pm |
| collection60@googlemail.com wrote:
> Hows this for a software development idea?
>
> Now, good code generally is tight code. The smaller the better,
> because less code means less bugs.
>
[... and so on ...]
From my point of view it's very simple:
the goals
good software development
has to follow
has as good as nothing in common
with the goals good
compression
has to follow
Why?
The most important reason is that good software development has much to
do with people (both developers and users) and processing of information,
where good compression don't bother about people and has to do with
processing of data and with hardware details only.
Claudio
| |
| cr88192 2007-08-10, 6:56 pm |
|
<collection60@googlemail.com> wrote in message
news:1186702051.840009.104330@z24g2000prh.googlegroups.com...
> Hows this for a software development idea?
>
> Now, good code generally is tight code. The smaller the better,
> because less code means less bugs.
>
> Once you start copy/pasting lines all over the place, you start
> getting unmaintainable code because you need to fix bugs in every
> place you've copy/pasted the code!
>
> And in general, the idea is to basically "identify patterns" in your
> code. Where two pieces of code are doing mostly the same thing, so
> much similar that they can be "refactored" out into their own helper
> function, which just gets called with different parameters.
>
> Just that description there, is 90% of software development summed
> up ;)
>
> So... isn't this similar to the idea of compression?
>
> A good software developer, should create code with minimal repetition.
>
> And a good compressor, creates a compressed file with minimal
> repetition :)
>
> Interesting connection eh?
>
things are not so simple.
ever worked on a several hundred kloc codebase?...
the link between copying/pasting, functions, and refactoring is not always
(or even often) quite so simple...
seperating a 'good' from a 'bad' developer based on such criteria is bound
to lead to bad reasoning...
most of this could just as easily been applied to natural language...
<snip>
| |
| Jim Leonard 2007-08-10, 6:56 pm |
| On Aug 9, 6:27 pm, collectio...@googlemail.com wrote:
> Also, "compressing" is actually all what software is about!
I think a better term for your insight is "efficiency". Compressed
data is an attempt at representing information as efficiently (in
terms of size) as possible.
| |
| Le Chaud Lapin 2007-08-10, 6:56 pm |
| On Aug 10, 8:34 am, Claudio Grondi <claudio.gro...@freenet.de> wrote:
> collectio...@googlemail.com wrote:
>
>
> [... and so on ...]
>
> From my point of view it's very simple:
>
> the goals
> good software development
> has to follow
>
> has as good as nothing in common
>
> with the goals good
> compression
> has to follow
>
> Why?
>
> The most important reason is that good software development has much to
> do with people (both developers and users) and processing of information,
> where good compression don't bother about people and has to do with
> processing of data and with hardware details only.
>
Hmm..I'm going to disagree here and agree with the OP. There are many
siutations where only 1 developer is involved in developing software,
and his observation is valid.
I have written a few blurbs myself that are consistent with the OP's
post. The "patterns" he refer to are called primitives. Thouse with
background in linear algebra will be familiar with the notion of
orthogonal basis, where a funamental set of vectors represent the
optimal set of primitives that eliminate redundancy and allows optimum
reachability in the vector space.
The same concept applies to some form of compression, and it also
applies to software development.
For example, are assigned the task of creating the same large-scale
program, undoubtedly, the two programms will be different in size,
speed, easy of use, bugs, etc.
All other things being equal, it should be apparent that the better
programmer will have found the optimal set of primitives for
reusability, thus reducing both the size of souce code and target
code.
But what if the sizes turn out to be identitcal, by freakish
coincidence. Then it would still be arguable that the "vector set" of
the bad programmer does not represent an orthogonal basis. The good
programmer will have found that orthogonal basis, and his program will
be more comprehensible.
I believe the steady-state mindset of a good software engineer, or any
kind of engineer for that matter, is one where the engineer pretty
much knows what vectors he will be use and the various "linear"
combination of those vectors, while the user of the system is
speaking, long before he enters his design lab.
The bad software engineer does not possess this forethought, and
struggles, making mistakes in real-time and correcting them as he
proceeds.
Of course, these are two extremes of a spectrum, most of us fall in
the middle somewhere, and we all strive to get to the good side as
quickly as we can in our careers.
-Le Chaud Lapin-
| |
| collection60@googlemail.com 2007-08-11, 9:56 pm |
| > The most important reason is that good software development has much to
> do with people (both developers and users) and processing of information,
> where good compression don't bother about people and has to do with
People can identify patterns too you know. Duh.
Some people just like expending mental energy in order to deny new
information, so that they don't need to learn anything.
This is the cause of stupidity.
| |
| collection60@googlemail.com 2007-08-11, 9:56 pm |
| So you want your users to enter the same details 1000x over, or just
make them enter it once? if I added a new feature to let them do it
once and have it done for them the other 1000x, I have identified a
user pattern, and "compressed" the time taken for him to do his job,
by 1000x. This is compression of a user's time!
Also, your idea is total nonsense. Simplest of examples: I've
"compressed" my error warning windows by reusing the error warnings
code over and over. Instead of copy/pasting it, I have it in one
place. This let me upgrade the error warnings from one place, and all
the error warnings get made sophisticated in one neat go!
| |
| Claudio Grondi 2007-08-13, 7:56 am |
| collection60@googlemail.com wrote:
> So you want your users to enter the same details 1000x over, or just
> make them enter it once? if I added a new feature to let them do it
> once and have it done for them the other 1000x, I have identified a
> user pattern, and "compressed" the time taken for him to do his job,
> by 1000x. This is compression of a user's time!
>
> Also, your idea is total nonsense. Simplest of examples: I've
> "compressed" my error warning windows by reusing the error warnings
> code over and over. Instead of copy/pasting it, I have it in one
> place. This let me upgrade the error warnings from one place, and all
> the error warnings get made sophisticated in one neat go!
>
What about cutting yourself into two parts in order to throw one away
and save others the time for dealing with redundancy and repetitions
when looking at you?
Claudio
| |
| collection60@googlemail.com 2007-08-14, 6:56 pm |
| On Aug 13, 12:03 pm, Claudio Grondi <claudio.gro...@freenet.de> wrote:
> collectio...@googlemail.com wrote:
>
>
> What about cutting yourself into two parts in order to throw one away
> and save others the time for dealing with redundancy and repetitions
> when looking at you?
>
> Claudio
You first, XXXXXXX.
| |
|
|
|
|
|