Dynamic linking with LD_PRELOAD - get it compiled
Johannes Bauer
I'm currently working on a tool which generates code that can be
compiled with gcc to form a shared object. This shared object then can
be preloaded with the LD_PRELOAD variable and shadows other library
functions (read, write, printf and such).
The intercepted functions do a dlsym with the RTLD_NEXT parameter on the
name of the actual function - then they are called. This gives me the
possibilty to hook code in before and after library calls and maybe
change the return value of those.
Anyways, it's working nicely with open(), close(), read(), write() and
such, but then I tried select() - suddenly the compiler complains:
$ gcc -O2 -Wall -fPIC -shared -ldl -o libtrapper.so libtrapper.c Custom.o
libtrapper.c:155: error: conflicting types for ‘select’
/usr/include/gentoo-multilib/amd64/sys/select.h:112: error: previous
declaration of ‘select’ was here
make: *** [libtrapper.so] Error 1
Well, of course I redefine it - however with different parameters. I
always use void* in my declaration. I know it is not 100% correct, but
it works (at least on x86_64) - but how do I convince gcc to compile the
code anyways?
Regards,
Johannes
--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e...@newsspool3.arcor-online.net>
Dildo Bogumil di Boscopelo
> Well, of course I redefine it - however with different parameters. I
> always use void* in my declaration. I know it is not 100% correct, but
> it works (at least on x86_64) - but how do I convince gcc to compile the
> code anyways?
>
why don't you use the correct parameters?
--
SF
Games are very educational. Scrabble teaches us vocabulary, Monopoly teaches
us cash-flow management, and Dungeons & Dragons teaches us to loot dead bodies.
David Schwartz
> Well, of course I redefine it - however with different parameters.
This it not legal. C does not permit two functions to have the same
name, nor does it permit a single function to have inconsistent
parameters.
> I
> always use void* in my declaration. I know it is not 100% correct, but
> it works (at least on x86_64) - but how do I convince gcc to compile the
> code anyways?
You can't. The code is simply not sensible. Why do you say "it works"
when it generates a compiler error? It doesn't work at all.
DS
Johannes Bauer
> On Mar 8, 7:44 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>
>> Well, of course I redefine it - however with different parameters.
>
> This it not legal. C does not permit two functions to have the same
> name, nor does it permit a single function to have inconsistent
> parameters.
I know it is not correct C. However I also know that at least on x86_64
compiled with gcc all pointers (including function pointers) have the
same length (64 bits) which is exactly the length of a void*. It
shouldn't matter for the prototype.
>> I
>> always use void* in my declaration. I know it is not 100% correct, but
>> it works (at least on x86_64) - but how do I convince gcc to compile the
>> code anyways?
>
> You can't. The code is simply not sensible. Why do you say "it works"
> when it generates a compiler error? It doesn't work at all.
It only generates a compiler error if I include the appropriate header
files - which I usually don't. For some functions, however, I need to
include them. Apart from you thinking the code is sensible or not - how
do I force the compiler to compile it anyways? Is there no way to
undefine a prototype?
Johannes Bauer
> why don't you use the correct parameters?
Because then the code generator needs to know the exact prototype -
which it doesn't. It doesn't need to look into the data, just pass on
the pointer. The function handling the data then might include the
headers and interpret the pointer correctly.
Greetings,
William Pursell
> It only generates a compiler error if I include the appropriate header
> files - which I usually don't. For some functions, however, I need to
> include them. Apart from you thinking the code is sensible or not - how
> do I force the compiler to compile it anyways? Is there no way to
> undefine a prototype?
Although I don't recommend it, you can do things like:
#define select(a,b,c,d,e) select(void *)
#include <unistd.h>
#undef select
Now, it's as if unistd.h made the declaration:
extern int select( void *);
Rainer Weikusat
> David Schwartz schrieb:
>> On Mar 8, 7:44 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
[...]
>>> I
>>> always use void* in my declaration. I know it is not 100% correct, but
>>> it works (at least on x86_64) - but how do I convince gcc to compile the
>>> code anyways?
>> You can't. The code is simply not sensible. Why do you say "it works"
>> when it generates a compiler error? It doesn't work at all.
>
> It only generates a compiler error if I include the appropriate header
> files - which I usually don't. For some functions, however, I need to
> include them.
"It only generates a compiler error if I want to compile incorrect
code" ...
> Apart from you thinking the code is sensible or not -
> how do I force the compiler to compile it anyways?
... "and how can I force the compiler to compile the incorrect code"?
The answer is 'not at all': Because the code is incorrect, no compiler
can possibly compile it to anything, because it has no defined
meaning. If you want to "fix" this, you have to change the
compiler. The usual course of action would be to fix the code the
compiler doesn't compile, for obvious reasons.
C still supports the possibility to declare a function with an
unspecified parameter list (actually, an emtpy 'identifier list'), eg
int select();
and any call to such a function will, in absence of other
informations, result in performing the 'default argument promotions'
on the actual parameters (any integer smaller than int is either
converted to int or unsigned, depending on representability of the
value, floats are converted to doubles) and then just invoke the
subroutine with them
Johannes Bauer
> Although I don't recommend it, you can do things like:
>
> #define select(a,b,c,d,e) select(void *)
> #include <unistd.h>
> #undef select
Ah! Thank you. That's the solution I was looking for.
Kind regards,
Johannes Bauer
>> Apart from you thinking the code is sensible or not -
>> how do I force the compiler to compile it anyways?
>
> ... "and how can I force the compiler to compile the incorrect code"?
> The answer is 'not at all': Because the code is incorrect, no compiler
> can possibly compile it to anything, because it has no defined
> meaning. If you want to "fix" this, you have to change the
> compiler. The usual course of action would be to fix the code the
> compiler doesn't compile, for obvious reasons.
*sigh*
Actually, I had here a paragraph about what I need and do not need to
do. About what gcc assumes about pointer types (which I happen to know).
I deleted it. It's pretty pointless.
Williams hack does what I want to be done. Period.
> C still supports the possibility to declare a function with an
> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>
> int select();
>
> and any call to such a function will, in absence of other
> informations, result in performing the 'default argument promotions'
> on the actual parameters (any integer smaller than int is either
> converted to int or unsigned, depending on representability of the
> value, floats are converted to doubles) and then just invoke the
> subroutine with them
This doesn't help me, however, as I need to access the parameters within
the function, not just make the call possible.
Rainer Weikusat
> Rainer Weikusat schrieb:
>
>>> Apart from you thinking the code is sensible or not -
>>> how do I force the compiler to compile it anyways?
>> ... "and how can I force the compiler to compile the incorrect code"?
>> The answer is 'not at all': Because the code is incorrect, no compiler
>> can possibly compile it to anything, because it has no defined
>> meaning. If you want to "fix" this, you have to change the
>> compiler. The usual course of action would be to fix the code the
>> compiler doesn't compile, for obvious reasons.
>
> *sigh*
>
> Actually, I had here a paragraph about what I need and do not need to
> do.
You believe that you need a language which is not C to express
something you would like a computer to do, but you want to use a
C-compiler to compile code written in this language. This doesn't make
sense, and that you don't understand why it doesn't make sense does
not cause it to make more sense.
[...]
> Williams hack does what I want to be done. Period.
And this 'hack' does exactly what I had written above: It uses the
preprocessor to modify a specific declaration in the incorrect code
you would like to feed into a C-compiler for some unknown reason such
that the code is again correct, assuming that this particular textual
substitution does not cause any other issues (which would need to be
checked by examining all headers in its 'scope').
In other words: As soon as you fix your incorrect code, it magically
compiles, which is what you want.
>> C still supports the possibility to declare a function with an
>> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>> int select();
>> and any call to such a function will, in absence of other
>> informations, result in performing the 'default argument promotions'
>> on the actual parameters (any integer smaller than int is either
>> converted to int or unsigned, depending on representability of the
>> value, floats are converted to doubles) and then just invoke the
>> subroutine with them
>
> This doesn't help me, however, as I need to access the parameters
> within the function, not just make the call possible.
Dear imbecile. a function declaration cannot 'access parameters'
because it is a declaration and not a definition.
Johannes Bauer
> In other words: As soon as you fix your incorrect code, it magically
> compiles, which is what you want.
There might as well have been a switch for gcc to ignore inconsistent
prototypes. This might qualify as broken code, yet the resulting
assembly would in no way be different. Pointers do not have a type at
machine level (at least on x86_64 they don't).
>>> C still supports the possibility to declare a function with an
>>> unspecified parameter list (actually, an emtpy 'identifier list'), eg
>>> int select();
>>> and any call to such a function will, in absence of other
>>> informations, result in performing the 'default argument promotions'
>>> on the actual parameters (any integer smaller than int is either
>>> converted to int or unsigned, depending on representability of the
>>> value, floats are converted to doubles) and then just invoke the
>>> subroutine with them
>> This doesn't help me, however, as I need to access the parameters
>> within the function, not just make the call possible.
>
> Dear imbecile. a function declaration cannot 'access parameters'
> because it is a declaration and not a definition.
Your "solution" is not helpful, as it does not change the need to use
preprocessor magic. I was talking about the function definition, not the
declaration.
I also might note that your derogatory style of writing and your
oh-so-whitty comments are sickening. You might notice that not all
people besides you are morons some day. Your postings would be of much
more easy reading when you could suppress that kind of insulting drivel.
David Schwartz
> I know it is not correct C. However I also know that at least on x86_64
> compiled with gcc all pointers (including function pointers) have the
> same length (64 bits) which is exactly the length of a void*. It
> shouldn't matter for the prototype.
It is almost always a mistake to take "magic platform knowledge" and
try to write C code based on it. The length of pointers is not the
only possible way this can go wrong. What happens, if with the next
version of the C compiler, the total size of all parameters becomes
part of the calling convention when it is known?
DS
Johannes Bauer
You're right, of course.
But the application is not intended to be portable. Not across different
platforms - not even across different versions of gcc or any of the
libraries it links my application against. Its a quick hack which I use
to reverse engineer some internals of a libusb-driver (no, ltrace is not
sufficient, it doesn't do what I need it to do).
I need to hack it once, get the data, never use it again. So, it is nice
if it is portable and well-written C - but it's definitely not a
requirement for this purpose. Broken, ugly C code is fully sufficient to
get the job done.
Kind regards,
phil-new...@ipal.net
| William Pursell schrieb:
|
|> Although I don't recommend it, you can do things like:
|>
|> #define select(a,b,c,d,e) select(void *)
|> #include <unistd.h>
|> #undef select
|
| Ah! Thank you. That's the solution I was looking for.
OK, so that works. It's a hack. What I'm curious about is why you could
not just define select to match the library declaration? Are you trying
to make this an intercept function that just passes on the arguments AND
can work no matter which way the function is declared/defined by libc?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
phil-new...@ipal.net
| Rainer Weikusat schrieb:
|
|> In other words: As soon as you fix your incorrect code, it magically
|> compiles, which is what you want.
|
| There might as well have been a switch for gcc to ignore inconsistent
| prototypes. This might qualify as broken code, yet the resulting
| assembly would in no way be different. Pointers do not have a type at
| machine level (at least on x86_64 they don't).
Generally pointers would generate code the same way on the same machine.
But the C compiler is doing more than that. It is making sure that you
don't link up code that would use the pointer in different ways that are
not consistent with each other. C++ is worse.
I'm curious exactly what you are doing. If your code is open source or
otherwise not restricted, can you show it?
Johannes Bauer
> OK, so that works. It's a hack. What I'm curious about is why you could
> not just define select to match the library declaration? Are you trying
> to make this an intercept function that just passes on the arguments AND
> can work no matter which way the function is declared/defined by libc?
Exactly. It's a code generator which just passes on pointers in the
gerneated code. It links together with user code which has knowledge
about the pointers (so it casts appropriately).
I've not thought about licensing the code itself, but if you want to see
it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
generates C code (that builds a shared lib which can be used to
LD_PRELOAD and reverse engineer certain other libraries/programs). Is
your mail valid? I'd send it to you then.
Regards,
David Schwartz
It's funny, you say this:
> I've not thought about licensing the code itself, but if you want to see
> it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
> generates C code (that builds a shared lib which can be used to
> LD_PRELOAD and reverse engineer certain other libraries/programs). Is
> your mail valid? I'd send it to you then.
Yet you say this:
> But the application is not intended to be portable. Not across different
> platforms - not even across different versions of gcc or any of the
> libraries it links my application against. Its a quick hack ...
So, you're going to GPL this for all the other people using the same
platform, same version of GCC, and the same libraries your application
links against?!
The moral is, never believe someone who says "it's not intended to be
portable", "it's a quick hack" or "nobody else will ever use this".
They're usually just lazy.
DS
Johannes Bauer
> On Mar 12, 7:53 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>
> It's funny, you say this:
>
>> I've not thought about licensing the code itself, but if you want to see
>> it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
>> generates C code (that builds a shared lib which can be used to
>> LD_PRELOAD and reverse engineer certain other libraries/programs). Is
>> your mail valid? I'd send it to you then.
>
> Yet you say this:
>
>> But the application is not intended to be portable. Not across different
>> platforms - not even across different versions of gcc or any of the
>> libraries it links my application against. Its a quick hack ...
>
> So, you're going to GPL this for all the other people using the same
> platform, same version of GCC, and the same libraries your application
> links against?!
Hey, someone asked for the code and I'm giving it away - what's wrong
with that? I do need the application for myself only, but will give it
away for free. Just because I choose the GPL for my code does not imply
that I'm distributing it (and I won't!)
> The moral is, never believe someone who says "it's not intended to be
> portable", "it's a quick hack" or "nobody else will ever use this".
> They're usually just lazy.
Nope, you're wrong. I never ever intended to give the app away in the
first place - if someone asks, however, that's fine with me.
David Schwartz
> Nope, you're wrong. I never ever intended to give the app away in the
> first place - if someone asks, however, that's fine with me.
You never intended to, but code has a way of being used outside the
designer's intentions.
The first thought is, "it's only ever going to be used on this
platform with this compiler, so there's no reason to make it
portable". The next thought is, "hey, maybe it works on this other
platform". Then, "hey, it seems to work, so let's use it". The next
thing you know, it breaks.
The best place to stop this chain is at the very first link. You
should need a damn good reason to do it wrong, not a good reason to do
it right.
DS
Johannes Bauer
> The first thought is, "it's only ever going to be used on this
> platform with this compiler, so there's no reason to make it
> portable". The next thought is, "hey, maybe it works on this other
> platform". Then, "hey, it seems to work, so let's use it". The next
> thing you know, it breaks.
>
> The best place to stop this chain is at the very first link. You
> should need a damn good reason to do it wrong, not a good reason to do
> it right.
So essentialy what you're saying is that I should respond with "My code
is poorly written, I'm not giving it out" rather then "My code is poorly
written, do whatever you want with it" (as I did)?
I think when it is explicitly stated that the code is of poor quality,
full of ridiculous hacks and induces undefined behavior as of the
C-standard - what else would anyone expect who tried to use it other
than the code breaking? And why do you blame me for this?
Actually I do not think anyone seriously wants to use the code - maybe
take a peek, that's it. With the discussion here, all warnings are
pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
guess he knows what he's doing).
David Schwartz
> > The best place to stop this chain is at the very first link. You
> > should need a damn good reason to do it wrong, not a good reason to do
> > it right.
> So essentialy what you're saying is that I should respond with "My code
> is poorly written, I'm not giving it out" rather then "My code is poorly
> written, do whatever you want with it" (as I did)?
No, please read what I wrote again. What I'm saying is that it was no
easier to write your code poorly, and your justification (that nobody
else would ever use the code with different libraries) turned out to
be bogus.
> I think when it is explicitly stated that the code is of poor quality,
> full of ridiculous hacks and induces undefined behavior as of the
> C-standard - what else would anyone expect who tried to use it other
> than the code breaking? And why do you blame me for this?
Because you chose to write code of poor quality and full of ridiculous
hacks, and you did so knowing that this was exactly what you were
doing.
> Actually I do not think anyone seriously wants to use the code - maybe
> take a peek, that's it. With the discussion here, all warnings are
> pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
> guess he knows what he's doing).
I hope not. But there's a lesson here -- code has a way of outliving
its expected life and decisions to do things in a dirty way have a way
of coming back and biting someone. So don't do that unless you have a
really good reason and always be suspicious when you find yourself
thinking "nobody else will ever use this for anything else".
Tell me, did you wrap your code with appropriate 'ifdef's and
'#warning's? How much longer would that have taken?
DS
Johannes Bauer
> On Mar 12, 1:26 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>
>>> The best place to stop this chain is at the very first link. You
>>> should need a damn good reason to do it wrong, not a good reason to do
>>> it right.
>
>> So essentialy what you're saying is that I should respond with "My code
>> is poorly written, I'm not giving it out" rather then "My code is poorly
>> written, do whatever you want with it" (as I did)?
>
> No, please read what I wrote again. What I'm saying is that it was no
> easier to write your code poorly, and your justification (that nobody
> else would ever use the code with different libraries) turned out to
> be bogus.
You make me sound like a liar, which I find kind of unfair. I did, in
fact, not know that anyone would have any interest in the code. My
assumtions turned out to be incorrect - but it's not like I knew that in
advance.
>> I think when it is explicitly stated that the code is of poor quality,
>> full of ridiculous hacks and induces undefined behavior as of the
>> C-standard - what else would anyone expect who tried to use it other
>> than the code breaking? And why do you blame me for this?
>
> Because you chose to write code of poor quality and full of ridiculous
> hacks, and you did so knowing that this was exactly what you were
> doing.
Yes, because it saved me an - warning, wild guess here - appriximate
300-500 lines of code in the generator which it would have taken if I
wanted to support all kinds of (pointer) types. It was a lot easier that
way.
>> Actually I do not think anyone seriously wants to use the code - maybe
>> take a peek, that's it. With the discussion here, all warnings are
>> pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
>> guess he knows what he's doing).
>
> I hope not. But there's a lesson here -- code has a way of outliving
> its expected life and decisions to do things in a dirty way have a way
> of coming back and biting someone. So don't do that unless you have a
> really good reason and always be suspicious when you find yourself
> thinking "nobody else will ever use this for anything else".
And they should come back and bite everyone who uses them! They
absolutely should. Because the one thing we both seem to agree on is
that the generated code is crap. Whoever uses crap gets UB. Period.
> Tell me, did you wrap your code with appropriate 'ifdef's and
> '#warning's? How much longer would that have taken?
It actually emits a warning for each generated #define which replaces a
prototype. Do you want me to send you the source? ;-)
David Schwartz
> > No, please read what I wrote again. What I'm saying is that it was no
> > easier to write your code poorly, and your justification (that nobody
> > else would ever use the code with different libraries) turned out to
> > be bogus.
> You make me sound like a liar, which I find kind of unfair. I did, in
> fact, not know that anyone would have any interest in the code. My
> assumtions turned out to be incorrect - but it's not like I knew that in
> advance.
Right, just like the people who wrote code with Y2K bugs didn't know
in advance that their code would still be in use 30 years later. Every
link in the chain has a justification, but the end result is disaster.
So you have to stop the chain at the first link.
> > Tell me, did you wrap your code with appropriate 'ifdef's and
> > '#warning's? How much longer would that have taken?
> It actually emits a warning for each generated #define which replaces a
> prototype. Do you want me to send you the source? ;-)
No, let's stop it from spreading any further. ;)
The point is not the particular thing you did in this particular case.
The point is that any time you find yourself thinking "this code will
never be used for anything other than precisely what I'm using it for
now", you're as likely to be wrong as right. And the next person will
find it "happens to work for me" and so on and so on.
At least try to document your assumptions when and where you make
them. Try to use appropriate 'ifdef's and '#warning's and whatever
else it takes.
DS
phil-new...@ipal.net
| phil-new...@ipal.net schrieb:
|
|> OK, so that works. It's a hack. What I'm curious about is why you could
|> not just define select to match the library declaration? Are you trying
|> to make this an intercept function that just passes on the arguments AND
|> can work no matter which way the function is declared/defined by libc?
|
| Exactly. It's a code generator which just passes on pointers in the
| gerneated code. It links together with user code which has knowledge
| about the pointers (so it casts appropriately).
|
| I've not thought about licensing the code itself, but if you want to see
| it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
| generates C code (that builds a shared lib which can be used to
| LD_PRELOAD and reverse engineer certain other libraries/programs). Is
| your mail valid? I'd send it to you then.
I'd rather you not email any code. If you want to make it public, put it
online somewhere and tell us where. If you don't, I'd rather not have it.
phil-new...@ipal.net
| On Mar 12, 12:06 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
|
|> Nope, you're wrong. I never ever intended to give the app away in the
|> first place - if someone asks, however, that's fine with me.
|
| You never intended to, but code has a way of being used outside the
| designer's intentions.
Lots of code gets used way beyond the intentions. Look at XML for example.
It was intended as a _document_ format. It's being used to store config
data and other non-document things. People are doing that because it has
parsers already built, ready to use. They don't want to write parsers for
what might otherwise be a more optimal format for what they are doing.
Just because code has a _narrow_ use doesn't mean someone else won't find
a reasonable use for it ... or merely be inspired by it.
| The first thought is, "it's only ever going to be used on this
| platform with this compiler, so there's no reason to make it
| portable". The next thought is, "hey, maybe it works on this other
| platform". Then, "hey, it seems to work, so let's use it". The next
| thing you know, it breaks.
And you want to protect people that are so stupid that they mis-port code,
by saying no one else should benefit by this narrow purpose code?
| The best place to stop this chain is at the very first link. You
| should need a damn good reason to do it wrong, not a good reason to do
| it right.
OTOH, maybe someone will look at that code, say "I can do better", and
write it all over from scratch to do the same thing, only better. I seem
to remember some Swedish speaking Finnish college student having that
attitude many years ago.
phil-new...@ipal.net
| On Mar 12, 3:13 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
|
|> > No, please read what I wrote again. What I'm saying is that it was no
|> > easier to write your code poorly, and your justification (that nobody
|> > else would ever use the code with different libraries) turned out to
|> > be bogus.
|
|> You make me sound like a liar, which I find kind of unfair. I did, in
|> fact, not know that anyone would have any interest in the code. My
|> assumtions turned out to be incorrect - but it's not like I knew that in
|> advance.
|
| Right, just like the people who wrote code with Y2K bugs didn't know
| in advance that their code would still be in use 30 years later. Every
| link in the chain has a justification, but the end result is disaster.
| So you have to stop the chain at the first link.
Ironically, over 90% of the code that failed Y2K where I was consulting
at the time specifically to rapidly deal with Y2K issues, had been written
within the prior 3 years.
David Schwartz
> | The best place to stop this chain is at the very first link. You
> | should need a damn good reason to do it wrong, not a good reason to do
> | it right.
> OTOH, maybe someone will look at that code, say "I can do better", and
> write it all over from scratch to do the same thing, only better. I seem
> to remember some Swedish speaking Finnish college student having that
> attitude many years ago.
You can almost always do it better from scratch if you get to start
out learning what goes wrong and what goes right when you try to do it
the way you thought was best. On the flip side, if you try to do it a
way that you know is wrong, you learn very little when it doesn't work
the way people hope.
A good programming adage is "do it once and throw it away". The second
time, you will be able to design it knowing the real strengths and
weaknesses of your first design.
The best code I've ever written has been at least the third of fourth
time I've tried to do something. Sometimes the re-writes are in-place,
sometimes they're total. It depends how wrong I got it the N-1th time.
But none of that will happen if you start out knowingly doing it
wrong.
DS
Rainer Weikusat
> On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
>> | The best place to stop this chain is at the very first link. You
>> | should need a damn good reason to do it wrong, not a good reason to do
>> | it right.
>
>> OTOH, maybe someone will look at that code, say "I can do better", and
>> write it all over from scratch to do the same thing, only better. I seem
>> to remember some Swedish speaking Finnish college student having that
>> attitude many years ago.
>
> You can almost always do it better from scratch if you get to start
> out learning what goes wrong and what goes right when you try to do it
> the way you thought was best. On the flip side, if you try to do it a
> way that you know is wrong, you learn very little when it doesn't work
> the way people hope.
>
> A good programming adage is "do it once and throw it away". The second
> time, you will be able to design it knowing the real strengths and
> weaknesses of your first design.
... which will lead to gathering actual experience with the real
'strengths and weaknesses' of the 'first improved design' ...
phil-new...@ipal.net
| On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
|
|> | The best place to stop this chain is at the very first link. You
|> | should need a damn good reason to do it wrong, not a good reason to do
|> | it right.
|
|> OTOH, maybe someone will look at that code, say "I can do better", and
|> write it all over from scratch to do the same thing, only better. I seem
|> to remember some Swedish speaking Finnish college student having that
|> attitude many years ago.
|
| You can almost always do it better from scratch if you get to start
| out learning what goes wrong and what goes right when you try to do it
| the way you thought was best. On the flip side, if you try to do it a
| way that you know is wrong, you learn very little when it doesn't work
| the way people hope.
I'm not talking about that. I'm talking about inspiration not in how to
do it, but in what to do. Someone will look at the bad code and see that
it clearly is done in a bad way, and decide to do it from scratch. But
they didn't get the idea to do it at all until the see that someone has
already written the code.
| A good programming adage is "do it once and throw it away". The second
| time, you will be able to design it knowing the real strengths and
| weaknesses of your first design.
I agree with this. But sometimes that "second time" is someone else.
| The best code I've ever written has been at least the third of fourth
| time I've tried to do something. Sometimes the re-writes are in-place,
| sometimes they're total. It depends how wrong I got it the N-1th time.
That's happened to me more than once.
| 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.
Jerry Peters
> On Mar 12, 3:13 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>
>> > No, please read what I wrote again. What I'm saying is that it was no
>> > easier to write your code poorly, and your justification (that nobody
>> > else would ever use the code with different libraries) turned out to
>> > be bogus.
>
>> You make me sound like a liar, which I find kind of unfair. I did, in
>> fact, not know that anyone would have any interest in the code. My
>> assumtions turned out to be incorrect - but it's not like I knew that in
>> advance.
>
> Right, just like the people who wrote code with Y2K bugs didn't know
> in advance that their code would still be in use 30 years later. Every
> link in the chain has a justification, but the end result is disaster.
> So you have to stop the chain at the first link.
Were you doing programming then? I was. When you have a machine with
perhaps 256KB of memory and 16 or so 100MB disks you store data as
efficiently as possible.
BTW, what exactly is your problem? Do you always need to get the last
word? The OP has a solution to _his_ problem, that it doesn't fit
_your_ ideas of perfection is of no matter. If he makes his code
available, with no warranty of course, for other people who may find
it useful it is certainly all the better.
Jerry
David Schwartz
> Were you doing programming then? I was. When you have a machine with
> perhaps 256KB of memory and 16 or so 100MB disks you store data as
> efficiently as possible.
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.
> BTW, what exactly is your problem? Do you always need to get the last
> word?
I don't always need to get the last word, but if I disagree with
someone and they raise new points, I will usually respond to them. If
I think there's a valuable lesson that might be missed, I'll usually
point it out.
> The OP has a solution to _his_ problem, that it doesn't fit
> _your_ ideas of perfection is of no matter.
It may not matter to the OP, but that's not how the give and take of
USENET works. It's not "you help me with this, and I'll help somebody
else". It's "you help me with this, and everybody will learn from it,
adding to the storehouse of knowledge we all have".
That's why when someone posts a very specific question about a very
specific one-in-a-million case, it's important that somebody somewhere
point out that this not the typical case and that following the
solutions in that thread will probably be wrong if you're not the
poster.
This preserves the usefulness of past USENET posts.
> If he makes his code
> available, with no warranty of course, for other people who may find
> it useful it is certainly all the better.
Maybe, maybe not. If it serves as an example or subsequently breaks in
production use in subtle and horrible ways, it is not all the better.
If people see this post and assume that's how things are typically
done, it is not all the better.
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.
When they are sacrificed for good reason, it is important that it be
understood that these are things we do when we have good reason.
DS
Michel Talon
> 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.
I am horrified by this prose. This is the reason why most software today
(OpenOffice, etc.) is horribly bloated and inefficient, so that you need
more and more powerful machines to get reasonable performance. All
developers should be trained to get performance out of their code.
--
Michel TALON
Rainer Weikusat
> David Schwartz <dav...@webmaster.com> wrote:
>> 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.
>
> I am horrified by this prose. This is the reason why most software today
> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
> more and more powerful machines to get reasonable performance.
This isn't exactly true. I mainly develop targetting an 'embedded'
ARM9-based system with a 200Mhz-CPU, no possibility for any paging
and 64M of RAM. While this would have been a top-of-line desktop some
dozen years ago, it is really 'limited' hardware nowadays. The base
operating system image has a (compressed) size of (presently) 2052K
(the uncompressed FS tree is 6M). The 'largest' application running on
these device has (on my development board) presently a RSS of 1020K,
mainly, because it needs to link against most of the Kerberos 5
libraries. All others are significantly smaller. Nothing running on
such a device has been 'heavily' optimized for either speed or space
efficiency. The most advanced thing I have done in this respect was to
rewrite the top-level AES- and MD5 interfacing code to avoid redundant
memory copies, of which there were plenty, and obviously useless
computations (like using cipertext stealing instead of padding
cleartext to the AES blocksize when encrypting IP datagrams to support
VPN functionality).
I am generally very much in favor of prefering simple, structured code
at the expense of both performance and speed except in situations
where there is a real need to do otherwise. Because I like to 'waste'
computer ressources in order to make code more accessible to humans,
I avoid obvious 'waste for no particular reason', to ensure that I
preferably never get into the situation where I have to contort the
code in order to make it faster or smaller. So far, this has proven to
be completely sufficient.
David Schwartz
> David Schwartz <dav...@webmaster.com> wrote:
> > 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.
> I am horrified by this prose. This is the reason why most software today
> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
> more and more powerful machines to get reasonable performance.
Nope, that's a myth. Reusable code is efficient.
> All
> developers should be trained to get performance out of their code.
Absolutely, by creating reusable code.
You could never have a product like OpenOffice if every element had to
be generated from scratch just for OpenOffice. And you could never
implement everything OpenOffice has to do efficiently if you had to do
it just for OpenOffice. But someone has written an efficient XML
parser. And someone has written an efficient text renderer. And with
those pieces, you can produce an efficient complete product with
reasonable effort.
If a bug is found in the XML parser, and you used that XML parser, you
just upgrade it to the version with the bug fix.
Sure, you could write your own XML parser that had just the features
you needed. But it will probably perform worse, because you don't need
enough XML features to justify optimizing it. And it sure as hell
won't be maintained, because you don't particularly care about XML
parsing.
It used to be that you had no choice. A general-purpose whatever would
be too bulky and slow to be an option. But now you have a choice.
Ironically, performance will typically be better, because more effort
can go into optimizing each component if it's reusable.
DS
Rainer Weikusat
> On Mar 14, 2:01 am, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
>> David Schwartz <dav...@webmaster.com> wrote:
>> > 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.
>
>> I am horrified by this prose. This is the reason why most software today
>> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
>> more and more powerful machines to get reasonable performance.
>
> Nope, that's a myth. Reusable code is efficient.
'Reusable code' is 'efficient' for people paying for software
development, provided they are not using it themselves. If they do,
any preceived benefit will be eaten over time.
>> All developers should be trained to get performance out of their
>> code.
>
> Absolutely, by creating reusable code.
>
> You could never have a product like OpenOffice if every element had to
> be generated from scratch just for OpenOffice.
Funnily enough, the people who wrote the original StarWriter did just
that. They even coded a signifcant part of it in assembly, because
this means it ran well (extremly well, actually) on then-current PC
hardware.
[...]
> But someone has written an efficient XML parser.
Considering that 'parsing XML' necessitates dealing with more than
enough overhead to make anything 'slow', optimizing the hell out of an
XML-parser to make it 'faster' is a stupid waste of time: Just not
using XML would increase the 'performance' of the thing using it and
decrease the time needed to develop it more.
But the crucial point is, of course, that _somebody else has written
an XML parser_ and that 'mere users', if only because of lack of
alternatives, are willing to accept that their 3.x Ghz-PCs with 4G of
RAM enable them to at least not spend more time waiting for the
computer than they already did wait for a 4.77Mhz-machine with 640M of
RAM twenty years ago. 'Fortunately', the waste of electricity and the
corresponding, ever incresing heap of toxic rubbish does not yet have
to be paid by the people causing it, so, their particular method of
socializing cost to increase private gain still works.
[...]
> If a bug is found in the XML parser, and you used that XML
> parser, you just upgrade it to the version with the bug fix.
It's more likely that 'you' just add some code to workaround this
particular issue in the 'frontend-code', because 'the bug in
the XML parser' will never be fixed, either, because the people who
wrote don't care or consider it to actually be a feature, or because
nobody feels comfortable touching this particular piece of code, given
that this could break one of the other 567 workarounds for bugs and
quirks in it nobody understand entirely anymore, too.
There is method to this madness, and the method cause each
'sufficiently complicated' program to exhibit a tumor-like growth over
time.
> Sure, you could write your own XML parser that had just the features
> you needed. But it will probably perform worse, because you don't need
> enough XML features to justify optimizing it.
Simpler, and especially, less code, will usually perform better than
more complicated or more code.
[...]
> Ironically, performance will typically be better, because more effort
> can go into optimizing each component if it's reusable.
If there is a need to even think about 'optimizing components', that's
usually a sign that the baby already drowned. Computers are fast
enough nowadays that simple code will almost always perform 'well
enough'. What remains to be done would be to convince the clever
people spending enormous amounts of time trying to fix their design
errors by means of 'hyper-clever optimimzations' to go looking for
another playing field. Maybe complicated crossword puzzles coud be
one. This would help to increase both the actual performance and
reliablity of software quite a bit, because suddenly, the time to
develop it sensibly would be there because the need to 'clever around'
350 KLoC of inerithed deficiencies would be gone.
jason.c...@gmail.com
> [a lot of stuff]
David, while everything you say about reusability and proper software
design is true and valid, unless you actually cite the specific source
for this "all software must be properly designed, modular, reusable,
and portable" that you seemed to have made up, your entire original
attack on poor Mr. Bauer completely falls apart.
Can you fill us all in on where that rule is? Is that part of a
standard or something? This may be hard to believe, but Johannes
Bauer's kludgey application is not the only one of it's kind out
there. In fact, there may be hundreds of thousands, even millions, of
programs that people have written that don't get the International
Organization of Perfectly Designed Application's 100% Seal of Quality
Approval. Millions! How can you sleep at night, knowing that somewhere
there is a program that compiles on somebody's computer, but not on
yours? How can you sleep at night, knowing that somewhere there is an
application with source code that can't be infinitely copied, pasted,
expanded, and reused? How do you feel knowing that your kids may be
using computers with poorly designed applications on them?? Your own
children, for God's sake! Using improperly designed applications! What
is this world coming to?
> It used to be that you had no choice. A general-purpose whatever would
> be too bulky and slow to be an option. But now you have a choice.
Precisely. The last sentence hits the nail on the head.
Jason
phil-new...@ipal.net
| David, while everything you say about reusability and proper software
| design is true and valid, unless you actually cite the specific source
| for this "all software must be properly designed, modular, reusable,
| and portable" that you seemed to have made up, your entire original
| attack on poor Mr. Bauer completely falls apart.
It's actually a rather common principle. OTOH, I think that principle
is overused and too often misapplied ... especially the reusable part.
I separate a lot of the software I write into library functions and main
programs. The library functions are intended to be reusable. The main
programs are not.
When writing a new program, I try to understand how widely it could be
used for its purpose. But I won't consider making it usable for purposes
I cannot imagine.
| Can you fill us all in on where that rule is? Is that part of a
| standard or something? This may be hard to believe, but Johannes
| Bauer's kludgey application is not the only one of it's kind out
| there. In fact, there may be hundreds of thousands, even millions, of
| programs that people have written that don't get the International
| Organization of Perfectly Designed Application's 100% Seal of Quality
| Approval. Millions! How can you sleep at night, knowing that somewhere
| there is a program that compiles on somebody's computer, but not on
| yours? How can you sleep at night, knowing that somewhere there is an
| application with source code that can't be infinitely copied, pasted,
| expanded, and reused? How do you feel knowing that your kids may be
| using computers with poorly designed applications on them?? Your own
| children, for God's sake! Using improperly designed applications! What
| is this world coming to?
Whenever I need to write something that is very machine specific to one
single machine, I have no qualms about doing that. I have done it many
times. And there are plenty of examples around of programs and functions
that are very machine specific. And device drivers are, too, but that is
an obvious special case.
|> It used to be that you had no choice. A general-purpose whatever would
|> be too bulky and slow to be an option. But now you have a choice.
|
| Precisely. The last sentence hits the nail on the head.
You mean we should still have a choice between a highly optimized machine
specific program and a (relatively) slow and bulky (but comfortably fast
on today's machines) portable version, where one can run 20 of the former
or 3 of the latter at the same time on a given modern machine?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
jason.c...@gmail.com
> [snip a lot of reasonable stuff that I agree with]
> |> It used to be that you had no choice. A general-purpose whatever would
> |> be too bulky and slow to be an option. But now you have a choice.
> |
> | Precisely. The last sentence hits the nail on the head.
>
> You mean we should still have a choice between a highly optimized machine
> specific program and a (relatively) slow and bulky (but comfortably fast
> on today's machines) portable version, where one can run 20 of the former
> or 3 of the latter at the same time on a given modern machine?
That's probably not what I meant, as it doesn't make sense in the
context of what I said. More likely, I meant that a programmer still
has a choice between a portable, reusable application (which doesn't
necessarily have to be slow and bulky, even relatively), and a non-
portable, not-so-reusable application that he puts together quickly
and gets the job done. I should have been less vague.
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).
Jason
phil-new...@ipal.net
| 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?
David Schwartz
<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?
> (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.
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
jason.c...@gmail.com
> On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
>
> <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, ...
Your reactions in this thread, especially your immediate reaction to
the original post, make it look like you are claiming that even though
you aren't explicitly saying it. Also, it is an attitude that I have
seen before and so, in my experience, it is not an uncommon claim to
make. Therefore it is reasonable to assume that is your attitude.
> > 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?
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).
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.
That is also not to say that I don't think it's a good idea to give
people advice with the intention of teaching them something new that
will help them in the future. Perhaps you see their source code or a
description of their application and say, "hey, by the way, I've found
that if you do X here you save yourself a lot of work because of A, B,
and C". It is nice to offer helpful advice. However, it is crucial to
be constructive here. In the following dialog:
Johannes Bauer writes:
> I
> always use void* in my declaration. I know it is not 100% correct, but
> it works (at least on x86_64) - but how do I convince gcc to compile the
> code anyways?
David Schwartz writes:
> You can't. The code is simply not sensible. Why do you say "it works"
> when it generates a compiler error? It doesn't work at all.
Johannes Bauer writes:
> It only generates a compiler error if I include the appropriate header
> files - which I usually don't. ...
> Apart from you thinking the code is sensible or not - how
> do I force the compiler to compile it anyways?
David Schwartz writes:
> It's funny, you say this:
> ...
> Yet you say this:
> ...
> So, you're going to GPL this for all the other people using the same
> platform, same version of GCC, and the same libraries your application
> links against?!
> The moral is, never believe someone who says "it's not intended to be
> portable", "it's a quick hack" or "nobody else will ever use this".
> They're usually just lazy.
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.
> > (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.
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. 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. That is your fundamental misunderstanding here. 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.
> 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 completely agree. Your example is a good example, as well. However,
there is one thing in your example I disagree with strongly:
> 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.
> 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.
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."
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"?
(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".
> 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.
>
> DS
Jason
jason.c...@gmail.com
> On Mon, 17 Mar 2008 09:33:26 -0700 (PDT) jason.cipri...@gmail.com <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
David Schwartz
<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
jason.c...@gmail.com
> On Mar 17, 9:39 pm, "jason.cipri...@gmail.com"
>
> <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.
This:
> If you don't want your code used as an example for others, good or
> bad, don't talk about it on USENET.
...is a completely general statement, that makes no sense in or out of
context, is, for the most part, untrue. Would you post code on
alt.porno.images and expect it to be used as an example? You do
realize that USENET is not just programming groups, please do not use
it to make generally incorrect statements like that. You also realize
that the code was not offered to you in the first place, you do not
have it, and that you are not using anybody's code as any kind of
example, good or bad.
Your vague statement about "USENET" as a whole also sidesteps every
single thing that I pointed out in the last post; such as the
harshness and uselessness of your criticism, the rule you made up
about all applications having to be reusable, portable, well-designed
pieces of code, and everything else. Feel free to stay with us here, I
think you can do it if you concentrate.
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".
>
> 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:
On Mar 18, 12:39 am, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
> On Mar 17, 11:04 pm, David Schwartz <dav...@webmaster.com> wrote:
>
> > On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
>
> > <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, ...
>
> Your reactions in this thread, especially your immediate reaction to
> the original post, make it look like you are claiming that even though
> you aren't explicitly saying it. Also, it is an attitude that I have
> seen before and so, in my experience, it is not an uncommon claim to
> make. Therefore it is reasonable to assume that is your attitude.
>
> > > 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?
>
> 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).
>
David Schwartz
<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
<foo bar="baz"/>
<foo bar='baz'/>
<foo bar='baz"/>
<foo bar=baz/>
Yeah, neither did he. Oops.
> > > 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.
> > 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
William Pursell
> 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.
Jerry Peters
> On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
> <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.
Jerry Peters
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
David Schwartz
Nah, I hate comments, even good ones. And I love senseless variable
names.
Yeah, you're right.
DS
David Schwartz
> > 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
David Schwartz
> > 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
Rainer Weikusat
[...]
>> (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.
David Schwartz
> > 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
David Schwartz
> | 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
Jerry Peters
> On Mar 18, 1:14 pm, Jerry Peters <je...@example.invalid> 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.
>
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
Jerry Peters
> On Mar 18, 1:21 pm, Jerry Peters <je...@example.invalid> 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
Rainer Weikusat
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 shit, 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.
David Schwartz
> > 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 shit, 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
moe
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.
phil-new...@ipal.net
|>>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.
David Schwartz
> 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
phil-new...@ipal.net
That could be another option. Code at least well enough written so that
it is easy to extend it to do more things would be good. Source helps.
I hate re-using code I don't have the source for (e.g. trying to rig the
environment around some binary to get it to achieve something it was not
originally written to do).
I'm also quite comfortable writing things from scratch, depending on the
scale of it. For example, I need a program to replicate a directory tree.
I could use "cp". But I've had some gotchas with the way "cp" behaves,
sometimes. For example, I want the source to replace the target, even if
the source is a file and the target is an existing subtree to replace.
The "cp" program won't do that for me. So I'll end up writing my own.
And I'll end up doing it smaller with little or no library needs so it
will keep the initramfs image smaller. Of course I could start with the
source to "cp" and tweak it. But I have written something like this once
before and it was not hard. I think it would be harder making sure I have
not overlooked something in "cp" (because the code is unfamiliar to me)
than to make sure my own code does exactly what I want.
But that's not for everyone or everything.
Timothy Baldwin
In message <e7kfa5x...@joeserver.homelan.net>, Johannes Bauer
<dfnson...@gmx.de> wrote:
> Dildo Bogumil di Boscopelo schrieb:
>
>> why don't you use the correct parameters?
>
> Because then the code generator needs to know the exact prototype -
> which it doesn't. It doesn't need to look into the data, just pass on
> the pointer. The function handling the data then might include the
> headers and interpret the pointer correctly.
Why not use C++?
For example:
extern "C" int test1(char a, unsigned short b);
template <typename T> struct decompose;
template <typename r, typename p1, typename p2>
struct decompose< r (*)(p1, p2) > {
typedef r R;
typedef p1 P1;
typedef p2 P2;
};
typedef decompose<__typeof__(&test1)> test1_decomposed;
extern "C" test1_decomposed::R
test1(test1_decomposed::P1 a, test1_decomposed::P2 b) {
}
__typeof__ is not part C++ standard but is provided by GCC, for a more
portable approach use Boost's Typeof library.