On Mar 17, 4:03 pm, phil-news-nos...@ipal.net wrote:
> On Mon, 17 Mar 2008 09:33:26 -0700 (PDT) jason.cipri...@gmail.com wrote:
>
> | My major point is that it's unreasonable to claim that all
> | applications should consist of portable and reusable code. Another
> | point I am making is that it is equally unreasonable to criticize
> | (even mildly) an application that does not consist of portable/
> | reusable code and that also makes no claims otherwise (of course, if
> | somebody claims to have written a "cross-platform food processing
> | library" but it only chops carrots on Windows, you're definitely
> | justified in smacking them around a bit).
>
> Windows? Isn't that for letting cherry pies cool down?

A compelling statement indeed, but I'm not so sure anymore. Nowadays,
I have generally come to believe that if all operating systems and
platforms were ants on a log, then Windows would be the peanut butter,
if not the celery... although that may go without saying.

Jason

On Mar 17, 9:39 pm, "jason.cipri...@gmail.com"
wrote:

> > Why not? What if the code would have been more robust, easier to
> > understand, portable, and reusable with even less effort than it took
> > to make it non-portable and not reusable? Would you still argue that
> > it's unreasonable to criticize it just because it doesn't claim to be
> > portable or reusable?

> Absolutely. It is unreasonable to criticize an application that does
> not consist of portable/reusable code and that also makes no claims
> otherwise. That is what I meant. It does not vary case-by-case. The
> reason I would still argue it is that the application was already
> complete, already got the job done, and criticizing it after the fact
> changes nothing unless the author specifically asked for advice or
> could be convinced to go back and rewrite the application (or apply
> the concepts in the future).

I don't know what to say except that I completely disagree with you.
If you don't want your code used as an example for others, good or
bad, don't talk about it on USENET.

I could respond to you point-by-point but there's really no reason.

DS

On Mar 17, 11:36 pm, "jason.cipri...@gmail.com"
wrote:

> You would have been better off not posting a reply at all, at least
> that way you could have pretended to have no longer cared about the
> topic. Now you've only shown that not only are you incapable of
> creating constructive criticism, and that you may be a questionable
> software engineer, but also that when presented with solid points, you
> instead choose to ignore them and make vague blanket statements about
> things like "USENET".

Your defense of bad engineering is laughable. It doesn't merit a point-
by-point refutation. It's easier and better to just do it right --
really.

> > I could respond to you point-by-point but there's really no reason.

> In fact, I doubt that you can. My last post was fairly solid. I am
> disappointed by the sudden change in the intensity of your interest in
> this discussion. I will include it again below, so that it is not lost
> in your attempt to change the subject:

I'll point out the more absurd points, just to entertain anyone who
reads this.

> > That is not to say that I don't think it's a good idea to try to write
> > robust, easier to understand, portable, and reusable code, especially
> > if it takes comparable or less effort than doing it otherwise. That is
> > a good goal to strive for. However, it is not a rule that needs to be
> > followed all of the time.

Which is precisely what I said.

> > Your criticism is harsh, contains no actual advice, no specific
> > constructive criticism on anything in particular, and has a very
> > aggressive attitude that is probably not conducing to teaching people
> > a skill that may help them in the future. So while I do believe that
> > criticism *can* be helpful, it also is reasonable to believe that your
> > criticism was not intended to be positive or helpful.

Just as with you, it starts out nice and then it gets not-so-nice when
the claims get more and more dangerous and outrageous. People
listening to you can cause real damage, and it's important important
to point out just how wrong you are to protect the people who read
this group.

> > > Bad design and bad code is still bad even if nobody claims it's good.

> > If it gets the job done and meets all of the requirements of the
> > problem it hand, then it's really not a problem if the design or the
> > code could have been improved.

Until the requirements change or someone uses it in a way that wasn't
anticipated.

Look, how much longer does it take to add code like:

#ifndef __LP64
#error This code has not been developed for or tested on LP64
platforms
#endif

How much time does that take?

You are also making the completely bogus argument that all solutions
that meet requirements are equally good. That's simply not true. There
are better and worse solutions, even among those that meet
requirements.

> > It also also not reasonable to say that
> > if the design or code has room for improvement, even a lot of room,
> > that it is bad.

I agree, and I never said that.

> > That is your fundamental misunderstanding here.

What, the position you foist on me is my understanding?

> > I have
> > a program on my Windows machine that does a quick image processing
> > task, it is written in about 100 lines of VisualBASIC. It could have
> > been designed better. It is nearly impossible to read. In two weeks if
> > I look at it again I will have no idea what I was trying to do. It
> > violates some of the most basic rules of thumb (rules of thumbs?) of
> > VisualBASIC programming. It is also a perfectly good, functional
> > application that did exactly what I needed it to do. It does not make
> > sense to call it "bad". The program was a kludge, not a text book
> > example for software design techniques. Calling it "bad" is like
> > saying that your car is a poorly designed truck which, while somewhat
> > amusing on further thought, isn't really a meaningful statement. Going
> > on to criticize the car manufacturer for producing poorly designed
> > trucks (because you really like trucks) is going to get you a few
> > raised eyebrows but it will be hard to convince them of anything
> > besides your desire to argue with them.

Nonsense, complete nonsense. A solution is not "good" just because it
meets requirements, it's adequate. There could be a universe of
possible soltions that meet requirements.

As a silly example, consider two programs otherwise identical. One has
no comments and variables like 'MyVariable1', the other is well-
commented and has variables with names that immediately suggest their
use. The former one is easier to understand, maintain, and debug. It
even took less time to write because the programmer knew what his
variables meant and occasionally found his own comments helpful to
remind him why he did things the way he did.

Now, will you seriously argue these are equally good?

> > > A good example would be writing your own XML library because you "only
> > > need a few simple capabilities". Not only is this likely to be more
> > > work than using one that's already made, ...
>
> > Absolutely. However:
>
> > > ... but it will likely mishandle
> > > a large number of corner cases that maintained XML libraries work hard
> > > to get right.

> > This should not be a motivating factor in your decision to use a pre-
> > existing XML library instead of your own in the situation you describe
> > (the situation where you only need a few simple capabilities). If you
> > only need a few simple capabilities, and the "XML" library you tossed
> > together meets all your requirements, then it does not matter if you
> > mishandle corner cases. Handling corner cases properly was not the
> > requirement, the requirement was "a few simple capabilities". If you
> > want strange corner cases to be handled properly, *then* you use the
> > pre-existing XML library -- but if that isn't one of your requirements
> > then it's not a factor in your decision. Of course, the "more work
> > than using a pre-existing XML library" reason is a very good one; but
> > of the two reasons you listed so far, that is the only valid one.

I picked this example because it really happened. Guess what, it turns
out he needed the corner cases. The thing is, he didn't make an
intelligent decision that he didn't need the corner cases because he
didn't know what the corner cases were because he wasn't an XML
expert.

Do you know which of the following are valid and which not


> > > matter anyway since the assumption was that this was a limited-purpose
> > > program. And, of course, that would be premature optimization.

> > This is the attitude that I was referring to when I said: "My major
> > point is that it's unreasonable to claim that all applications should
> > consist of portable and reusable code."

Huh? How so?

> > If you set out to design a limited-purpose program, and then you do
> > just that, then there is nothing wrong with that. There is no
> > "assumption that it is a limited-purpose program" -- you DECIDED that
> > it would be a limited-purpose program. When was the last time somebody
> > went to the Wendy's drive-thru and said "I'm assuming I would like a
> > Jr. Bacon Cheeseburger, although this may be premature optimization"?

I can't imagine how you think this responds to me or disagrees with
me. If you were going to a job site fifty miles away, would you take a
drill with a half-charged battery or a fully-charged one if you
thought you'd only need about half a battery's worth?

Sure, that means you don't add code outside the purpose. But it
doesn't mean that two choices are automatically equally good just
because they have no difference in effect outside the limited purpose.

> > (Ok, well, I can tell you that the next time I go to Wendy's will be
> > the *first* time somebody has said that). The programmer is the one
> > that sets the goals and requirements. If the requirement is for a
> > limited-purpose program that performs a specific task, then making the
> > program limited-use and able to only perform that task is not
> > "premature optimization", it's "writing the exact program you set out
> > to write".

That wasn't my example. My example was where you made a decision based
on performance even though performance wasn't important given the
limited purpose. In other words, the programmer *failed* to respect
the limitation in purpose and I'm criticizing him for that. I don't
know how you got it 100% backwards.

> > > It might take up less memory, but who cares? And in many cases, it
> > > actually won't.

> > This is true, but I don't think it is an important part of the
> > original decision. If you decide to hack together an "XML" library
> > because you only need some features, many times (sure, not every) the
> > rationale is not related to performance so much as "I really feel like
> > it would be easier for me to roll my own hacky XML library than to
> > learn about a pre-existing one right now". That is not to say that you
> > wouldn't benefit immensely in the future from learning how to use a
> > pre-existing XML parsing library, but that also does not mean that it
> > was wrong of you to base a decision on that logic.

Except, ironically, it turns out to be a lose all around. It takes
longer to make the hacky library (Oh, there are some XML tags that
aren't closed! Oh, where exactly are comments legal and when must I
remove them? Oh, ...). It fails in corner cases you had no idea
existed. It performs worse. And, the next time you really do need a
full-featured XML library, you have to learn it anyway.

It's a great example of a bad decision and it's precisely the type I'm
warning people about here.

DS

On 18 Mar, 09:05, David Schwartz wrote:

> As a silly example, consider two programs otherwise identical. One has
> no comments and variables like 'MyVariable1', the other is well-
> commented and has variables with names that immediately suggest their
> use. The former one is easier to understand, maintain, and debug.

s/former/latter/g

At least, I hope that's what you meant.

David Schwartz wrote:
> On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
> wrote:
>
>> My major point is that it's unreasonable to claim that all
>> applications should consist of portable and reusable code.
>
> Well, since nobody claimed that, ...
>
>> Another
>> point I am making is that it is equally unreasonable to criticize
>> (even mildly) an application that does not consist of portable/
>> reusable code and that also makes no claims otherwise
>
> Why not? What if the code would have been more robust, easier to
> understand, portable, and reusable with even less effort than it took
> to make it non-portable and not reusable? Would you still argue that
> it's unreasonable to criticize it just because it doesn't claim to be
> portable or reusable?

You can posit anything, of course, but reality tends to be less
theoretical.
You keep making statements like this. I tend to ignore, if not
openly ridicule statements that begin "what if".

>
>> (of course, if
>> somebody claims to have written a "cross-platform food processing
>> library" but it only chops carrots on Windows, you're definitely
>> justified in smacking them around a bit).
>
> Bad design and bad code is still bad even if nobody claims it's good.
> In many cases, it's actually harder to write the non-portable, non-
> reusable code than it would have been to do it right.
>

According to _you_.
You don't seem to consider little things like time constraints in your
view of reality. This is software engineering, and like any
engineering discipline, there are trade-offs.

> A good example would be writing your own XML library because you "only
> need a few simple capabilities". Not only is this likely to be more
> work than using one that's already made, but it will likely mishandle
> a large number of corner cases that maintained XML libraries work hard
> to get right.
>
> It's likely not even faster in execution. And if it is, that doesn't
> matter anyway since the assumption was that this was a limited-purpose
> program. And, of course, that would be premature optimization.
>
> It might take up less memory, but who cares? And in many cases, it
> actually won't.
>
> DS

David Schwartz wrote:
> On Mar 17, 9:39 pm, "jason.cipri...@gmail.com"
> wrote:
>
>> > Why not? What if the code would have been more robust, easier to
>> > understand, portable, and reusable with even less effort than it took
>> > to make it non-portable and not reusable? Would you still argue that
>> > it's unreasonable to criticize it just because it doesn't claim to be
>> > portable or reusable?
>
>> Absolutely. It is unreasonable to criticize an application that does
>> not consist of portable/reusable code and that also makes no claims
>> otherwise. That is what I meant. It does not vary case-by-case. The
>> reason I would still argue it is that the application was already
>> complete, already got the job done, and criticizing it after the fact
>> changes nothing unless the author specifically asked for advice or
>> could be convinced to go back and rewrite the application (or apply
>> the concepts in the future).
>
> I don't know what to say except that I completely disagree with you.
> If you don't want your code used as an example for others, good or
> bad, don't talk about it on USENET.
>
> I could respond to you point-by-point but there's really no reason.
>
> DS

You keep acting like a pedantic acedemic. You keep talking about
USENET as if it's something very special instead of a world spanning
public bulletin board.

Neither I, nor anyone else has to fulfill your expectations.

Yes, I'll agree code _should_ be readable and maintainable,
unfortunately there's an awful lot of _awful_ code out there (take a
look at some of the old BSD apps, for example). Old code that's had a
lot of different maintainers seems to fall into this category.o

Jerry

On Mar 18, 12:01 pm, William Pursell wrote:

> On 18 Mar, 09:05, David Schwartz wrote:

> > As a silly example, consider two programs otherwise identical. One has
> > no comments and variables like 'MyVariable1', the other is well-
> > commented and has variables with names that immediately suggest their
> > use. The former one is easier to understand, maintain, and debug.

> s/former/latter/g
>
> At least, I hope that's what you meant.

Nah, I hate comments, even good ones. And I love senseless variable
names.

Yeah, you're right.

DS

On Mar 18, 1:14 pm, Jerry Peters wrote:

> > Bad design and bad code is still bad even if nobody claims it's good.
> > In many cases, it's actually harder to write the non-portable, non-
> > reusable code than it would have been to do it right.

> According to _you_.

That's a great response. Save it. You can use it to respond to
literally anything. My personal favorite is -- "that's what you
think!" -- you are welcome to use that one.

> You don't seem to consider little things like time constraints in your
> view of reality. This is software engineering, and like any
> engineering discipline, there are trade-offs.

My whole post is about making sensible trade-offs. The section you are
directly responding to points out that it usually takes longer to do
it wrong than to do it right.

DS

On Mar 18, 1:21 pm, Jerry Peters wrote:

> > If you don't want your code used as an example for others, good or
> > bad, don't talk about it on USENET.

> You keep acting like a pedantic acedemic. You keep talking about
> USENET as if it's something very special instead of a world spanning
> public bulletin board.

Err, what?!

> Neither I, nor anyone else has to fulfill your expectations.

Really? And where did I say or imply otherwise?

That's a great generic reply -- you can use it to reply to any case
where one person gives another advice.

> Yes, I'll agree code _should_ be readable and maintainable,
> unfortunately there's an awful lot of _awful_ code out there (take a
> look at some of the old BSD apps, for example). Old code that's had a
> lot of different maintainers seems to fall into this category.

That code gets awful in various different ways. But one of the ways it
gets awful is people who made bad trade-offs. They thought they were
making a quick fix to code that wouldn't be re-used or wouldn't be
ported, so they didn't add good comments or use sensible variable
names, or whatever. My point is, quite often the very people who make
these decisions pay for them personally, when they do in fact later
have to modify or maintain the code.

Whenever you catch yourself saying one of the following things, you
need to make absolutely sure you understand what you're trading off
and what you're getting for it, because it's frequently these thoughts
that precede the making of a bad trade off:

1) Nobody's is ever going to use this code again.

2) This code will never be ported to another platform.

3) I just need this limited functionality, so I'll roll my own.

4) There's no need to comment this, nobody is going to look at this
code.

5) This works on my machine, so I'll do it that way.

And so on.

DS

David Schwartz writes:
> On Mar 17, 9:33 am, "jason.cipri...@gmail.com"

[...]

>> (of course, if
>> somebody claims to have written a "cross-platform food processing
>> library" but it only chops carrots on Windows, you're definitely
>> justified in smacking them around a bit).
>
> Bad design and bad code is still bad even if nobody claims it's good.
> In many cases, it's actually harder to write the non-portable, non-
> reusable code than it would have been to do it right.

I would still have to meet any such case. It is usually easier to not
'design' and (preferably) not 'write code' but to just add some hacks
to generic third party code to make it perform some functionality its
originators would never have dreamed of. The net result of doing so
will be a slow, bulky application exhibiting lots of weird behaviour
in various corner cases (nobody has yet added the necessary hacks to
deal with) and lots of basically unfixable bugs. But time-to-market
will be really little.

There you have the 'typical' proprietary, commercial application (I
had the mispleasure to deal with so far).

> A good example would be writing your own XML library because you "only
> need a few simple capabilities".

This is still a red herring: Someone needing 'a few simple
capabilities' would not use XML to begin with (Ideally, that is). That
someone would design a simple configuration language well adapted to
his particular problem and use that.

[...]

> It's likely not even faster in execution.

Parsing textual data is never fast. And neither should it ever matter
exactly how slow it is.

On Mar 19, 3:24 am, Rainer Weikusat wrote:

> > A good example would be writing your own XML library because you "only
> > need a few simple capabilities".

> This is still a red herring: Someone needing 'a few simple
> capabilities' would not use XML to begin with (Ideally, that is). That
> someone would design a simple configuration language well adapted to
> his particular problem and use that.

In the real example this was based on, XML was not the author's
choice. The "quick and dirty hack" had to interoperate with another
program that outputted XML. Things got ugly when the next version of
the program it had to interoperate with slightly changed the XML
output to output that is technically XML-equivalent.

DS

On Mar 13, 6:02 am, phil-news-nos...@ipal.net wrote:

> | But none of that will happen if you start out knowingly doing it
> | wrong.

> Not necessarily. I call it "prototyping". I see no reason not to let
> it loose, as as long as you don't make any claims that it is believed to
> be done right.

Yeah, that's a fair point. It may ultimately be more efficient to do
it a bit "fast and loose" the first time, rather than wasting time
improving an implementation you are probably just going to throw away.
If it happens to meet all of your requirements, and it turns out not
to be too horribly awful, you're done. If it turns out not to and to
be truly awful, at least you'll have gained some insight into what
works, what doesn't, and why.

I would still argue that you should at least put in appropriate
cautionary comments, #ifdef's and #warning's.

For algorithmic code, it's a very good idea to build in some test
cases and check out the code on startup. A good example would be an
application with a "quick and dirty" implementation of something like
MD5. If you haven't checked it on systems with a different size for
some of the types you use or a different endian-ness, a few quick
check hashes on startup will catch a problem before it results in
incorrect operation.

DS

David Schwartz wrote:
> On Mar 18, 1:14 pm, Jerry Peters wrote:
>
>> > Bad design and bad code is still bad even if nobody claims it's good.
>> > In many cases, it's actually harder to write the non-portable, non-
>> > reusable code than it would have been to do it right.
>
>> According to _you_.
>
> That's a great response. Save it. You can use it to respond to
> literally anything. My personal favorite is -- "that's what you
> think!" -- you are welcome to use that one.
>
No, I can keep using it because you keep asserting things without any
proof. I've been in the programming business long enough to know
copious quantities of MBE when I see it.

>> You don't seem to consider little things like time constraints in your
>> view of reality. This is software engineering, and like any
>> engineering discipline, there are trade-offs.
>
> My whole post is about making sensible trade-offs. The section you are
> directly responding to points out that it usually takes longer to do
> it wrong than to do it right.
>
> DS

Again according to you. No proof. Also I see you say "usually".

Jerry

David Schwartz wrote:
> On Mar 18, 1:21 pm, Jerry Peters wrote:
>
>> > If you don't want your code used as an example for others, good or
>> > bad, don't talk about it on USENET.
>
>> You keep acting like a pedantic acedemic. You keep talking about
>> USENET as if it's something very special instead of a world spanning
>> public bulletin board.
>
> Err, what?!

You keep telling the rest of us poor deluded fools how USENET works.

>
>> Neither I, nor anyone else has to fulfill your expectations.
>
> Really? And where did I say or imply otherwise?
>
Um, this thread perhaps?

> That's a great generic reply -- you can use it to reply to any case
> where one person gives another advice.
>
You've gone well past the point of giving advice, you've been
preaching for the past several days.

>> Yes, I'll agree code _should_ be readable and maintainable,
>> unfortunately there's an awful lot of _awful_ code out there (take a
>> look at some of the old BSD apps, for example). Old code that's had a
>> lot of different maintainers seems to fall into this category.
>
> That code gets awful in various different ways. But one of the ways it
> gets awful is people who made bad trade-offs. They thought they were
> making a quick fix to code that wouldn't be re-used or wouldn't be
> ported, so they didn't add good comments or use sensible variable
> names, or whatever. My point is, quite often the very people who make
> these decisions pay for them personally, when they do in fact later
> have to modify or maintain the code.
>
Or, as I keep trying to point out to you, they had a severe time
constraint to deal with. Perhaps a little thing like the bank can't
clear checks. Ever worked in a bank? That's a _major_ crisis,
something that has to be fixed _now_.

> Whenever you catch yourself saying one of the following things, you
> need to make absolutely sure you understand what you're trading off
> and what you're getting for it, because it's frequently these thoughts
> that precede the making of a bad trade off:
>
> 1) Nobody's is ever going to use this code again.
>
> 2) This code will never be ported to another platform.
>
> 3) I just need this limited functionality, so I'll roll my own.
>
> 4) There's no need to comment this, nobody is going to look at this
> code.
>
> 5) This works on my machine, so I'll do it that way.
>
> And so on.
>
> DS

Jerry

David Schwartz writes:
> On Mar 19, 3:24 am, Rainer Weikusat wrote:
>> > A good example would be writing your own XML library because you "only
>> > need a few simple capabilities".
>
>> This is still a red herring: Someone needing 'a few simple
>> capabilities' would not use XML to begin with (Ideally, that is). That
>> someone would design a simple configuration language well adapted to
>> his particular problem and use that.
>
> In the real example this was based on, XML was not the author's
> choice. The "quick and dirty hack" had to interoperate with another
> program that outputted XML. Things got ugly when the next version of
> the program it had to interoperate with slightly changed the XML
> output to output that is technically XML-equivalent.

If this was really a slight change, ie none affecting the semantic
structure of the text, this would rather appear to be a problem caused
by a badly written parser and/or lexical analyzer. But even then, the
original choice could have been sensible for other reasons, depending
on the situation. Eg, the w3c XML 'schema' page
(http://www.w3.org/XML/Schema) lists an awful lot of tools whose main
purpose is to get rid of XML in favor of something which can either be
used more easily in a program or (even) be understood by a human when
displayed. When a lot of people feel to need to program tools solving
particular programming problems in a generally useful way, instead of
solving real problems, this would be a strong hint that a certain
something is actually way too complicated to be used by the same large
number of people. The 'quick and dirty hack' was likely still more
useful to the people wanting to process the data than a statement like
"sorry, I don't understand this weird ****, go find someone else"
would have been. Especially taking into account that really believing
to understand something is very much different from actually
understanding it.

"We have (for some idiotic reason) chosen to use a utility which none
of the people we employ could comprehend anymore, therefore, sorry, no
product" doesn't exactly sound like a recommendation.

On Mar 19, 2:02 pm, Rainer Weikusat wrote:

> > In the real example this was based on, XML was not the author's
> > choice. The "quick and dirty hack" had to interoperate with another
> > program that outputted XML. Things got ugly when the next version of
> > the program it had to interoperate with slightly changed the XML
> > output to output that is technically XML-equivalent.

> If this was really a slight change, ie none affecting the semantic
> structure of the text, this would rather appear to be a problem caused
> by a badly written parser and/or lexical analyzer.

Bingo. That's often what happens when you "roll your own" that does
"just what you need". Often, and especially in "quick and dirty" mode,
you dont' know what you need.

> But even then, the
> original choice could have been sensible for other reasons, depending
> on the situation. Eg, the w3c XML 'schema' page
> (http://www.w3.org/XML/Schema) lists an awful lot of tools whose main
> purpose is to get rid of XML in favor of something which can either be
> used more easily in a program or (even) be understood by a human when
> displayed. When a lot of people feel to need to program tools solving
> particular programming problems in a generally useful way, instead of
> solving real problems, this would be a strong hint that a certain
> something is actually way too complicated to be used by the same large
> number of people. The 'quick and dirty hack' was likely still more
> useful to the people wanting to process the data than a statement like
> "sorry, I don't understand this weird ****, go find someone else"
> would have been. Especially taking into account that really believing
> to understand something is very much different from actually
> understanding it.

> "We have (for some idiotic reason) chosen to use a utility which none
> of the people we employ could comprehend anymore, therefore, sorry, no
> product" doesn't exactly sound like a recommendation.

I agree. Ironically, in this particular case, I think XML was in fact
badly chosen. I don't know the exact reasons since I wasn't involved
in any way with the tool he had to interoperate with, but I think it
was chosen just because XML was "cool".

DS

>>Right, but that mentality doesn't work any more. In the vast majority
of programming applications, maintainability, understandability, and
reusability are much more important than squeezing out a few bytes.
<<

> We need to lose the mentality from the 60s through the 90s that
> performance and space efficiency are priority one. For the bulk of
> code written today, correctness, understandability and maintainability
> are extremely important. They should never be sacrificed for
> performance or alleged convenience when there is no good reason to do
> so.
>

This is directed at no one in particular, just my 5 cents worth...

Professionally I nod and smile at this. And I agree in many cases. It
makes sense, and if your manager preaches such things then you esp. want
to get along. Maintainability and reuse should be kept in mind from the
beginning.

That being said, overall i've been kind of disgusted with the direction
that the academic types have taken software development over the last 15
years. I would include code bloggers with this group too. JoelOnSoftware
types, 'you're all doing it wrong, look at me, look at me'. bah

Its like we are writing source code now just for the sake of writing
source code. HELLO!! the point is the binary! the execution! the user
experience! and yes the performance! I use slow apps and slow websites
all the time. Just today I opened a GNOME file browser dialog and had to
wait 11 seconds for it to scan the folder. This on a very new machine.

And code reuse is a myth. Code is maintained, ported, or replaced. Just
like it always has been. I don't see how components have changed
anything. I predicted .Net wouldn't last 5 years and it didn't. It
lasted about 2 years and was replaced by .Net 2.0. Personally, the only
thing i've truly seen reused, over a span of tens of years is database
schema. Usually with new parts bolted on.

On Mon, 31 Mar 2008 16:44:38 -0700 moe wrote:
|>>Right, but that mentality doesn't work any more. In the vast majority
| of programming applications, maintainability, understandability, and
| reusability are much more important than squeezing out a few bytes.
| <<
|
|> We need to lose the mentality from the 60s through the 90s that
|> performance and space efficiency are priority one. For the bulk of
|> code written today, correctness, understandability and maintainability
|> are extremely important. They should never be sacrificed for
|> performance or alleged convenience when there is no good reason to do
|> so.
|>
|
| This is directed at no one in particular, just my 5 cents worth...
|
| Professionally I nod and smile at this. And I agree in many cases. It
| makes sense, and if your manager preaches such things then you esp. want
| to get along. Maintainability and reuse should be kept in mind from the
| beginning.
|
| That being said, overall i've been kind of disgusted with the direction
| that the academic types have taken software development over the last 15
| years. I would include code bloggers with this group too. JoelOnSoftware
| types, 'you're all doing it wrong, look at me, look at me'. bah
|
| Its like we are writing source code now just for the sake of writing
| source code. HELLO!! the point is the binary! the execution! the user
| experience! and yes the performance! I use slow apps and slow websites
| all the time. Just today I opened a GNOME file browser dialog and had to
| wait 11 seconds for it to scan the folder. This on a very new machine.

Maybe you have too many files in your folder. You know people like Joel
would never, ever, have more than 255 files in their folder :-)

FYI, I have too many files in my folder, too. The "ls" command can be
quite painful. Oh wait, I should say "directory" since I do command
line more.


| And code reuse is a myth. Code is maintained, ported, or replaced. Just
| like it always has been. I don't see how components have changed
| anything. I predicted .Net wouldn't last 5 years and it didn't. It
| lasted about 2 years and was replaced by .Net 2.0. Personally, the only
| thing i've truly seen reused, over a span of tens of years is database
| schema. Usually with new parts bolted on.

What I see happening way, way, too often is code _repurposing_ to do things
it was never expected to do, and in most cases, cannot do effectively.

There seems to be too much emphasis on code _quantity_ instead of _quality_.
Sure, if company A has a nice HR app then there's little reason company B
should have to have one written from scratch for their HR dept. To me, that
is the ultimate code reuse (use the same app in two or more instances of the
need for exactly that app).

Code should only be reused within the scope of what it was written for.
The idea, then, would be to write code that has a very wide scope.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-04-01-1108@ipal.net |
|------------------------------------/-------------------------------------|

On Apr 1, 9:14 am, phil-news-nos...@ipal.net wrote:

> Code should only be reused within the scope of what it was written for.
> The idea, then, would be to write code that has a very wide scope.

Or perhaps it's even possible to write code with a narrow scope but to
facilitate expansion of the scope. Perhaps we should be thinking about
extensible code.

DS