Any surveys about the premature optimization status nowadays?
jimxoch
Having read many discussions about software optimization, I have
noticed that in most of them the premature optimization is regarded as
a very frequent habit of the professional software developers.
However, working as a professional programmer myself, I know for a
fact that the reality can differ a lot from these assumptions.
Furthermore, while I understand that premature optimization was
probably a frequent habit back in the 60s and 70s, when programming
was more like an art and less like a 9 to 5 job, I seriously doubt
that the situation remains the same till today.
In all the jobs I had till now, neither me nor my colleagues have ever
had the luxury of doing premature optimization frequently. Deadlines
are usually too tight, and often we barely have the time to complete
the features and debug our projects, working overtimes in many
occasions. Of course, back in my student days, when I was programming
mostly for fun, I can remember myself having the habit of optimizing
prematurely, but this habit quickly disappeared when I started to work
as a professional. Spending large amounts of time in premature and
unnecessary optimizations is very unrealistic for most (if not all)
the professional developers I have met till now! On the contrary,
while working under stress, it often happens to underestimate and
overly-delay some optimizations, hoping that we will probably avoid
them and save some valuable time, only to realize that sometimes in
order to have efficiency you have to design for it.
Noticing such a huge difference between the discussions I have read in
the internet and the reality I experience in my professional life, I
wonder if there exist any scientific surveys (or even indicative
polls) which can provide objective and complete information regarding
the way the programmers use to optimize nowadays. I will be extremely
grateful to anyone who can inform me about the existence of such
surveys.
Thank you very much,
Jim Xochellis
Homepage: http://jimxoch.freehost.gr/
Juha Nieminen
> Having read many discussions about software optimization, I have
> noticed that in most of them the premature optimization is regarded as
> a very frequent habit of the professional software developers.
> However, working as a professional programmer myself, I know for a
> fact that the reality can differ a lot from these assumptions.
> Furthermore, while I understand that premature optimization was
> probably a frequent habit back in the 60s and 70s, when programming
> was more like an art and less like a 9 to 5 job, I seriously doubt
> that the situation remains the same till today.
I think it depends on the exact definition of "premature
optimization". There are two possible definitions:
1) Micro-optimization (also called "hacker optimization"), often done
in places which don't need it and don't benefit from it at all, at the
cost of clarity and maintainability, for the sole reason that the
programmer has completely wrong priorities. Micro-optimization is seldom
motivated by actually profiling existing code and finding the need for
it (which is what makes it premature optimization).
2) The opposite of "premature pessimization". In other words, rather
than thinking "I will use a naive solution for this critical part of the
code and optimize it later", the programmer thinks of the optimal
solution first and only then implements that critical part. Unlike
micro-optimization, this kind of optimization happens at the algorithm
level, rather than at the hardware level.
IMO option 1 is a bad thing, and *not* doing option 2 is also a bad
thing. Option 2 *might* in some cases delay the implementation of the
software by some amount without any real benefit (ie. even though the
algorithm is efficient and sound, it never actually gets run on an
amount of data which would show a benefit). This would be what makes it
"premature optimization". However, IMO it's in no way a bad thing
because the code will be already prepared for the case that in the
future the domain of the application expands, so that it will be able to
handle expanded data sets efficiently without having to go over the
existing code to optimize naive algorithms.
Rune Allnor
> 2) The opposite of "premature pessimization".
What term is used for this? Pragmatic preparation?
> However, IMO it's in no way a bad thing
> because the code will be already prepared for the case that in the
> future the domain of the application expands, so that it will be able to
> handle expanded data sets efficiently without having to go over the
> existing code to optimize naive algorithms.
Agreed.
Rune
jimxoch
interesting thoughts.
However my question is not "what is the correct way to perform
optimizations". (Which is quite subjective by the way...) The question
is: How *actually* the professional programmers of our generation
perform the optimizations in the real world? What is more frequent, do
they optimize too late or too early? Do you happen to know any surveys
or polls which could enlighten us a little?
Best regards,
apat...@gmail.com
optimize it later". However this does not rule out applying well known
optimizations, algorithms or optimal library routines in the first
writeup of the code. For example, when calculating the value a high
degree polynomial, Horner's rule is an accuracy optimization that
could be applied in the first place, although this is rarely done
because it takes maybe ten minutes to write instead of one.
Obiously when time is a strict constraint something's gotta give.
Mostly this is quality, in any form, e.g. bugs or speed of execution
and one's manager has to be aware of this and not place absurd
demands. With regard to surveys, I think they are no replacement for
lessons learned from years of experience. Moreover, there is no
guarantee that just because most people use one approach, this is the
right one, or that it is the best one for the particular circumstances
one faces.
-Anthony Patrinos
Krice
> How *actually* the professional programmers of our generation
> perform the optimizations in the real world? What is more frequent, do
> they optimize too late or too early?
Don't try to think that there is a simple answer to that.
Optimizations are still required in software like games, but
I think premature optimization is not common in professional
development.
Rune Allnor
> How *actually* the professional programmers of our generation
> perform the optimizations in the real world? What is more frequent, do
> they optimize too late or too early?
I think if you asked, most people would probably say that
everybody else optimized to early or too late; they themselves
optimized just enough at just the right places.
The truth, however, is probably that results depend on the
environment where they are created.
I am not a professional programmer, but work in an enevironmet
where time is scarce and pressure to deliver results is high.
Much like - according to some people's claims - the programming
business.
My impression is that people in this kind of environment just
don't think. There is little planning or prioritazion of tasks.
Instead, people tend to react to stimulus: Whoever shoutest
loudest that "quit what you're doing and get *this* done ASAP!!"
will get their tasks moved to the top of the to-do list. Not
necessarily done, but moved to the top.
This is not at all a good environment for creating Great reults
in my day job, and I doubt if it is in programming.
Rune
Pascal J. Bourguignon
It is significative that you post that on C++.
Using C++ to develop most projects is in itself a premature
optimization and the main source of deadline overshooting.
If programmers wheren't thinking all the time about the processor
cycles and whether they should be using a std::vector or a std::list,
they wouldn't be optimizing unrelevant stuff, but would be thinking
about the user's problem and its solution within that domain, not that
of pointers vs. smartptr, references vs. copy, RIAA vs. exceptions,
etc. All these things are found only in programming languages, not in
domain problems.
--
__Pascal Bourguignon__
Francesco S. Carta
Pascal, can I ask you why you don't lose a chance to post things like
that?
It is significant that you post messages like that on c.l.c++, do you
enjoy language advocates flaming each other, eventually being one of
the contestants?
And apart of that, how can you call the choice of a language as being
a "premature optimization"?
Translating a complete, non-trivial program from a language to another
isn't exactly child-play and if a program has the chance of _needing_
to be implemented in a language, choosing another in first place is
not a "premature pessimization", it is a "serious project management
flaw", in my opinion.
But I'm an hobbyist and all of this stuff should be outside of my
worries.
@OP: Sorry Jim, I have no idea about the existence of surveys and
alike, wrt your original topic.
Have good time,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
Pascal J. Bourguignon
You don't have to translate the whole program.
Write your program in the highest level programming language you may
find.
If you determine that in fact it is too slow, and that it is not
because of a bad choice of algorithms, but because of fundamental
constraints due to the language, you can isolate the parts that are
too slow, and rewrite them in a low level language such as C or C++.
But only those parts.
--
__Pascal Bourguignon__
Francesco S. Carta
OK, I fully understand your position.
The thing that amazes me is the fact that you consider C++ as just a
low level programming language.
C++ is _also_ a low level programming language - the kind of languages
that have been called "close to the metal" somewhere else.
But it is also a high level language. And a pretty good one, in my
small experience.
I think that a stronger emphasis should be put on the experience of
the programmers available on a team.
If they're "proficient and well mannered" in C++, there is no need to
"force" them to use another language only because that language would
give them less potential freedom, "forcing" them (eventually, but not
necessarily) to "good manners".
On the other hand, if the available programmers happen to misuse C++
and can be equally productive and eventually less error prone using
another language, by all means they should either learn to use C++ in
a better way or choose to use that other language.
In other words, blame the experience level of the actual people that
write the code, don't blame the language itself.
ld
The problem is what you call a "high level programming language"
depend on the task to perform. Examples coming to my mind are:
C++ could be the _only_ "high level programming language" suitable
when the goal is to provide a library which allow to combine units of
code (classes) and generate optimized algorithms (aka generative
programming + specialization) as described in (p 429-431):
http://www-ia.tu-ilmenau.de/~czarn/gmcl/a4/matrix.gz
C could be the _only_ "high level programming language" suitable when
the goal is to implement a powerful object model on top of an
efficient language. An example is the C Object System which allows to
build non-intrusive efficient components like the proxy Locker to
remove deadlock in threaded programs or libraries.
So if by "high level programming language" you mean languages
dynamically typed, interpreted, or having a powerful macro system, you
are focusing on specific aspects which fits your needs.
cheers,
laurent.
ld
The answer varies widely if the software developers are writing
applications, libraries or operating system layers. The two lasts are
much more demanding since interfaces cannot be changed easily once
"published". Anticipating all cases of use is difficult which means
that components must be optimized somehow to fulfill the full range of
"possible" use. This could lead to a significant amount of extra work
comparing to the development of applications where the domain of use
is better known and controlled.
cheers,
ld.
Gert-Jan de Vos
wrote:
> Write your program in the highest level programming language you may
> find.
More general: write your program using the most appropriate tools for
the job. There is no single objective most appropriate tool, this
depends highly on context. This context includes:
- existing code base
- team experience with these tools
- available libraries
- external interfaces
- business goals
Most of these have little to nothing to do with inherent programming
language syntax or efficiency, yet I think they have a stronger
influence on the actual language of choice.
As an example: I consider myself a C++ programmer but I wouldn't
choose C++ for a substantial GUI project these days. Not because of
the language but because of availability of GUI libraries.
jimxoch
...
> With regard to surveys, I think they are no replacement for
> lessons learned from years of experience. Moreover, there is no
> guarantee that just because most people use one approach, this is the
> right one, or that it is the best one for the particular circumstances
> one faces.
I agree and I have no intention to use this survey as a guiding rule,
however I do consider such a survey very interesting, because of two
reasons:
1. In case the survey confirms the internet discussions and not what I
am experiencing, it is interesting for me to find out why do I have
such a wrong impression about the other programmers.
2. In case the survey results are very different from what most of the
internet discussions assume, this will be a very interesting paradox
and I love paradoxes, since investigating them might lead to very
important findings.
Of course there is always possible for such a survey to have
inconclusive results...
Best regards,
Jim Xochellis
jimxoch
At first I was sure that a relative survey should definitely exist.
Now I am not so optimistic...
jimxoch
Thank you Rune. I certainly share some of your impressions, but their
are still your/our impressions. I hope in finding something more
objective...
jimxoch
...
> @OP: Sorry Jim, I have no idea about the existence of surveys and
> alike, wrt your original topic.
Thanks anyway. Hope dies last :)
Best regards,
jimxoch
...
> The answer varies widely if the software developers are writing
> applications, libraries or operating system layers. The two lasts are
> much more demanding since interfaces cannot be changed easily once
> "published". Anticipating all cases of use is difficult which means
> that components must be optimized somehow to fulfill the full range of
> "possible" use. This could lead to a significant amount of extra work
> comparing to the development of applications where the domain of use
> is better known and controlled.
Thank you for answering. Any surveys that you might know?
Best regards,
robert...@yahoo.com
> Translating a complete, non-trivial program from a language to another
> isn't exactly child-play and if a program has the chance of _needing_
> to be implemented in a language, choosing another in first place is
> not a "premature pessimization", it is a "serious project management
> flaw", in my opinion.
While you said "complete," I think it's worth pointing out that
prototypes can often be usefully written in languages other than the
final implementation language. In situations where significant
uncertainly about the design exists, and a prototype is justified (and
frankly that's true in reality far more than happens in practice), the
prototype should be written in with a tool that make it easy to write
and modify (in the short term), while possibly ignoring many other
factors (like deployment and performance). A decided advantage of
using a different (and impractical to deploy) language is that you
don't end up with management insisting you turn the prototype into
production code.
Francesco S. Carta
wrote:
First of all, let me point out once more that I'm an hobbyist who has
always coded alone.
I'm highlighting it (again) because all of these points of mine should
be taken with a grain of salt: I'm speaking about things that I
_could_ dig and understand, but I never actually faced them in real
life.
Just to bring my words back to their real value.
That said, I suppose that "prototyping in a language which is _not_
going to be the production language" as "a way to safely halt-on-start
weird management requests" is an odd need - there must be something
wrong with the managers if they put the team on studying something
which isn't all that clear from start and then they push the team to
get something out ASAP.
But that wasn't your central point, of course. Your point was about
prototyping with a language that allows you to work out and test an
initial infrastructure more easily and more quickly than with C++, if
I got your words in the right way.
The main problem I'm facing here is that my knowledge about different
languages is very limited, hence I cannot tell how easily _I_ could
"prototype" in one language and then "produce" in another.
About that, I think that most of the initial design process should be
no-code stuff, but once that initial process is even just partly done
(components, interfaces, politics) I think it can be effectively
prototyped and tested expressing such stuff directly in the C++ code
(namespaces, class hierarchies, public vs protected vs private
interfaces, client vs implementation interfaces)... in other words, I
see C++ as a very effective language to express the main
infrastructure even in the first steps of the prototyping.
But once again, take my limited knowledge in account. Maybe all of
that can be more easily and more quickly implemented/modified in, say,
LISP... but I don't know LISP, that's the fact ;-)
OK, I've posted my fair amount of wanderings for today - maybe I would
be better having kept my full name reserved, in the perspective of
getting some job interview, someday ;-)
Cheers,
Francesco S. Carta
> On Oct 1, 12:07 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
> ...
>
> > @OP: Sorry Jim, I have no idea about the existence of surveys and
> > alike, wrt your original topic.
>
> Thanks anyway. Hope dies last :)
You're welcome, and... "hope": here I am! the first among its
supporters ;-)
Cheers,
Francesco S. Carta
> On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> wrote:
>
>
>
> > On Oct 1, 4:07 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
> > > Translating a complete, non-trivial program from a language to another
> > > isn't exactly child-play and if a program has the chance of _needing_
> > > to be implemented in a language, choosing another in first place is
> > > not a "premature pessimization", it is a "serious project management
> > > flaw", in my opinion.
>
> > While you said "complete," I think it's worth pointing out that
> > prototypes can often be usefully written in languages other than the
> > final implementation language. In situations where significant
> > uncertainly about the design exists, and a prototype is justified (and
> > frankly that's true in reality far more than happens in practice), the
> > prototype should be written in with a tool that make it easy to write
> > and modify (in the short term), while possibly ignoring many other
> > factors (like deployment and performance). A decided advantage of
> > using a different (and impractical to deploy) language is that you
> > don't end up with management insisting you turn the prototype into
> > production code.
[self-snip]
> But that wasn't your central point, of course. Your point was about
> prototyping with a language that allows you to work out and test an
> initial infrastructure more easily and more quickly than with C++, if
> I got your words in the right way.
Sorry, I obviously didn't mean to change your words.
The above should read:
"[...] more easily and more quickly than with /, say,/ C++, [...]"
or, more fitting:
"[...] more easily and more quickly than with /another language/,
[...]"
I hope the perceived sense of my post didn't change for that small
mistake.
Have good time,
robert...@yahoo.com
> On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> wrote:
> First of all, let me point out once more that I'm an hobbyist who has
> always coded alone.
>
> I'm highlighting it (again) because all of these points of mine should
> be taken with a grain of salt: I'm speaking about things that I
> _could_ dig and understand, but I never actually faced them in real
> life.
>
> Just to bring my words back to their real value.
>
> That said, I suppose that "prototyping in a language which is _not_
> going to be the production language" as "a way to safely halt-on-start
> weird management requests" is an odd need - there must be something
> wrong with the managers if they put the team on studying something
> which isn't all that clear from start and then they push the team to
> get something out ASAP.
Unfortunately that's too often the real world. You get to the point
where something *looks* like it works, and then everyone is suddenly
wanting to ship. Or your prototype gets demo'd to a customer, who
then starts jumping up and down screaming that they *need* that
*now*. It's a definite danger when doing a prototype, which is often
full of all sorts of crap code.
> But that wasn't your central point, of course. Your point was about
> prototyping with a language that allows you to work out and test an
> initial infrastructure more easily and more quickly than with C++, if
> I got your words in the right way.
Yep. Always use the tools that best fit the job at hand. "Best," of
course, has to take in your familiarity with the tools.
> The main problem I'm facing here is that my knowledge about different
> languages is very limited, hence I cannot tell how easily _I_ could
> "prototype" in one language and then "produce" in another.
>
> About that, I think that most of the initial design process should be
> no-code stuff, but once that initial process is even just partly done
> (components, interfaces, politics) I think it can be effectively
> prototyped and tested expressing such stuff directly in the C++ code
> (namespaces, class hierarchies, public vs protected vs private
> interfaces, client vs implementation interfaces)... in other words, I
> see C++ as a very effective language to express the main
> infrastructure even in the first steps of the prototyping.
There's not necessarily anything wrong with prototyping in C++. If
that suits your purpose, have at. My point was that there may be
better choices, since the prototype, by definition, will not have a
long life (we hope!).
> But once again, take my limited knowledge in account. Maybe all of
> that can be more easily and more quickly implemented/modified in, say,
> LISP... but I don't know LISP, that's the fact ;-)
And that's a limitation you *should* rectify. Every programmer should
learn a procedural language, an object oriented one, a functional one,
a couple of scripting languages, and probably at least dabble in some
assembler. And then deal with some related stuff like databases,
etc. If you want to use Lisp to cover some of that, great, if not,
something like Haskel or F#. The particular language really doesn't
matter. The paradigm does, but as you become a better programmer the
exact language does not.
Today you're writing C++ code, and tomorrow you might have to write
some C# (*yawn*, yet another OO language falling somewhere on the
Algol tree). Sure there will be quirks, and a learning curve, and
you'll be less productive for a while, but for languages within a
given paradigm, the change is, or should be, no big deal. But hitting
some of the major different paradigms is good for you, it gives you
insights into different approaches, and helps decouple your
understanding of programming from a particular language and
environment.
Rune Allnor
wrote:
This is the flaw of prototyping software: Any software prototype
that includes a GUI *will* be percieved as an almost-ready-to-ship
system, no matter how difficult it is to use, deploy, maintain
or code. I have no idea why, but that's just how the world works.
Rune
Pascal J. Bourguignon
On average, I would say that corporations are rather efficient at
optimizing the use of their resources. If they weren't they'd go
bankrupt rather sooner than later.
Therefore, I'd believe that at least in a corporate setup, there is
not a lot of premature optimization done. (It might be done closer to
50% than to 90% of the time).
--
__Pascal Bourguignon__
Pascal J. Bourguignon
Why not? Really, why the last prototype wouldn't be exactly the
production code? If you accept the notion that the code is the design.
Even more: while prototyping you will make the software evolve you
say, but in production too software has to evolve. Then why go into
the dead-end branch of rewriting it in a less maleable language?
Really, it seems to me that the correct way is to do like for
compiler. We don't write assembler anymore, we let the compilers do
that for us. When comes a new processor with vectorial instructions,
people in a hurry may use __asm__() to use these instructions, but
soon enough the compilers are updated to generate them when possible.
By the same token, if you write your program in a high level
programming language, and you need to have a function run faster than
what is provided by the default implementation, you could, if you are
in a hurry, write it in C and use FFI to call the C function, but the
right way would be to update the compiler to generate better code.
--
__Pascal Bourguignon__
James Kanze
wrote:
> jimxoch <dpxguard-goo...@yahoo.gr> writes:
> > On Oct 1, 9:35 am, "apatri...@gmail.com" <apatri...@gmail.com> wrote:
> > ...
> On average, I would say that corporations are rather efficient at
> optimizing the use of their resources. If they weren't they'd go
> bankrupt rather sooner than later.
"Premature optimization" is a pessimization of corporate
resources, not an optimization of them; it is a case of
exchanging a rare resource (the time of competent programmers)
for a rather cheap and readily available resource (machine
time).
--
James Kanze
jimxoch
> "Premature optimization" is a pessimization of corporate
> resources, not an optimization of them; it is a case of
> exchanging a rare resource (the time of competent programmers)
> for a rather cheap and readily available resource (machine
> time).
Not only machine time! Clients time as well and clients time is
valuable, don't you think so?
robert...@yahoo.com
wrote:
> "robertwess...@yahoo.com" <robertwess...@yahoo.com> writes:
> > On Oct 1, 4:07 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
> >> Translating a complete, non-trivial program from a language to another
> >> isn't exactly child-play and if a program has the chance of _needing_
> >> to be implemented in a language, choosing another in first place is
> >> not a "premature pessimization", it is a "serious project management
> >> flaw", in my opinion.
>
> > While you said "complete," I think it's worth pointing out that
> > prototypes can often be usefully written in languages other than the
> > final implementation language. In situations where significant
> > uncertainly about the design exists, and a prototype is justified (and
> > frankly that's true in reality far more than happens in practice), the
> > prototype should be written in with a tool that make it easy to write
> > and modify (in the short term), while possibly ignoring many other
> > factors (like deployment and performance). A decided advantage of
> > using a different (and impractical to deploy) language is that you
> > don't end up with management insisting you turn the prototype into
> > production code.
>
> Why not? Really, why the last prototype wouldn't be exactly the
> production code? If you accept the notion that the code is the design.
>
> Even more: while prototyping you will make the software evolve you
> say, but in production too software has to evolve. Then why go into
> the dead-end branch of rewriting it in a less maleable language?
Then you're missing the point of a prototype, and following some other
iterative methodology. A prototype is deliberately throw away, and is
used to explore the design space for the application. It will
typically be woefully incomplete, full of horrible shortcuts, and
architecturally a mess. If it's not those things, you're probably
doing it wrong. This is a major distinction from prototyping in the
manufacturing world, where the last (if, as often happens, more than
one is built) prototypes are often very close to what's supposed to
come down the production line, since a major issue in that world is
manufacturability (which is obviously not an issue in software).
Software prototyping is more like early R&D in the manufacturing
world.
Prototyping is a tool to help decide what it is you're *really* doing,
and one it's helped with that, you throw it away. If you've gone
ahead and refined your prototype to the point of being essentially a
complete implementation, you've missed the point. Prototypes are not
appropriate in all situations (probably not in most), but can be
extremely useful is there's considerable uncertainty about the task to
be accomplished. There is a danger, however, that what starts as a
prototype gets evolved into product - that almost always is a bad
idea, and results in a lot of bad stuff (architecturally, etc.) in the
product.
Francesco S. Carta
wrote:
> On Oct 1, 6:26 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
>
>
>
> > On 2 Ott, 00:43, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> > wrote:
> > First of all, let me point out once more that I'm an hobbyist who has
> > always coded alone.
>
> > I'm highlighting it (again) because all of these points of mine should
> > be taken with a grain of salt: I'm speaking about things that I
> > _could_ dig and understand, but I never actually faced them in real
> > life.
>
> > Just to bring my words back to their real value.
>
> > That said, I suppose that "prototyping in a language which is _not_
> > going to be the production language" as "a way to safely halt-on-start
> > weird management requests" is an odd need - there must be something
> > wrong with the managers if they put the team on studying something
> > which isn't all that clear from start and then they push the team to
> > get something out ASAP.
>
> Unfortunately that's too often the real world. You get to the point
> where something *looks* like it works, and then everyone is suddenly
> wanting to ship. Or your prototype gets demo'd to a customer, who
> then starts jumping up and down screaming that they *need* that
> *now*. It's a definite danger when doing a prototype, which is often
> full of all sorts of crap code.
I think that the team shouldn't need to recur to any trick in order to
get rid of managerial or customer's pressure.
The target of the team is strictly coupled with managerial one:
getting things out to get money in, possibly in a steadily increasing
flow. The sooner the product gets home, the sooner and the happier the
customer will hand the money - modulo bugs, addressed below.
When Admin ships out my non-production-language-prototype to Paying
Joe and Joe starts waving banknotes, I'll have to hurry and re-
implement it from scratch in production language, not to speak about
the bugs I'll introduce meanwhile. Not really fine.
Hence, to align my target to the managerial one, I think it is better
to prototype directly in the production code. The sooner the bugs have
a chance to show up, the sooner I'll start fixing them.
> > But that wasn't your central point, of course. Your point was about
> > prototyping with a language that allows you to work out and test an
> > initial infrastructure more easily and more quickly than with C++, if
> > I got your words in the right way.
>
> Yep. Always use the tools that best fit the job at hand. "Best," of
> course, has to take in your familiarity with the tools.
>
> > The main problem I'm facing here is that my knowledge about different
> > languages is very limited, hence I cannot tell how easily _I_ could
> > "prototype" in one language and then "produce" in another.
>
> > About that, I think that most of the initial design process should be
> > no-code stuff, but once that initial process is even just partly done
> > (components, interfaces, politics) I think it can be effectively
> > prototyped and tested expressing such stuff directly in the C++ code
> > (namespaces, class hierarchies, public vs protected vs private
> > interfaces, client vs implementation interfaces)... in other words, I
> > see C++ as a very effective language to express the main
> > infrastructure even in the first steps of the prototyping.
>
> There's not necessarily anything wrong with prototyping in C++. If
> that suits your purpose, have at. My point was that there may be
> better choices, since the prototype, by definition, will not have a
> long life (we hope!).
As above - and as Pascal pointed out in the parallel reply to this
post - I think it's better to prototype in the production language,
giving prototypes a long and prolific evolving life.
Maybe at one certain point I'll have to bring down the whole
infrastructure and rebuild it from scratch, but chances are that at
least some component will have been coded correctly - eventually, I'll
have to change their interfaces to adapt to the whole new main
structure of the program.
> > But once again, take my limited knowledge in account. Maybe all of
> > that can be more easily and more quickly implemented/modified in, say,
> > LISP... but I don't know LISP, that's the fact ;-)
>
> And that's a limitation you *should* rectify. Every programmer should
> learn a procedural language, an object oriented one, a functional one,
> a couple of scripting languages, and probably at least dabble in some
> assembler. And then deal with some related stuff like databases,
> etc. If you want to use Lisp to cover some of that, great, if not,
> something like Haskel or F#. The particular language really doesn't
> matter. The paradigm does, but as you become a better programmer the
> exact language does not.
>
> Today you're writing C++ code, and tomorrow you might have to write
> some C# (*yawn*, yet another OO language falling somewhere on the
> Algol tree). Sure there will be quirks, and a learning curve, and
> you'll be less productive for a while, but for languages within a
> given paradigm, the change is, or should be, no big deal. But hitting
> some of the major different paradigms is good for you, it gives you
> insights into different approaches, and helps decouple your
> understanding of programming from a particular language and
> environment.
Luckily, my limited knowledge still contains some experience with many
paradigms and different environments (loose meaning of environment) -
started linear with MPF-II BASIC, continued somewhat OO with VB,
momentarily halted on multi-paradigm with C++, also with a small
modular and functional back-step on C after that.
It will surely help me, stepping back again and concentrating on
single paradigms by forcing myself into a new language and a new forma
mentis.
JavaSript and PHP have been a nice start on that - but I'm still just
at the very first steps, the language basics are OK, but most of the
work should be around the facilities, I suppose.
Coming back to the beginning of your last paragraphs, it seems to me
that you're not just suggesting me to learn something new, but also
strongly hinting to LISP or similar.
I'll have a try.
Francesco S. Carta
wrote:
Hence Pascal's (and mine) definition of prototype is broader than
yours - your concept of prototype is more stricter.
You call it prototype as long as the team is in research mode: as soon
as it switches to preliminary production implementation you stop
calling it prototype, while we still go on calling it so till the
first "official" release.
I think that both POVs stand fine.
robert...@yahoo.com
The term is unfortunately overloaded. Throwaway (or rapid)
prototyping is a useful design/analytical tool. In that sense the
term goes back to at least Brooks* (and almost certainly is older than
that). I've always considered what's now sometime called evolutionary
prototyping to be more an incremental development methodology,
somewhere in the vicinity of the XP end of the spectrum. And
certainly the notion of using a non-production-worthy language for the
latter is silly.
*So I pulled my copy of "The Mythical man Month" off the shelf, and
Brooks quotes Harel's definition of a prototype " [A version of a
program that] reflects only the design decisions made in the process
of preparing the conceptual model, and not decisions driven by
implementation concerns." (Although that definition is actually from
after the first edition was published.) And of course there's Brooks'
comment in support of (rapid) prototyping that one should "Plan to
throw one [version] away, you will anyway." In the context of:
"In most projects the first system built is barely usable. It may be
too slow, too big, awkward to use, or all three. There is no
alternative but to start again, smarting but smarter, and build a
redesigned version in which these problems are solved. The discard
and redesign may be done in one lump, or it may be done piece-by-
piece. But all large-system experience shows that it will be done.
Where a new system concept or new technology is used, one has to build
a system to throw away, for even the best planning is not so
omniscient as to get it right the first time."
"The management question, therefore, is not *whether* to build a pilot
system and throw it away. You *will* do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers. Seen this way the answer is much
clearer. Delivering that throwaway to customers buys time, but it
does so only at the cost of agony for the user, distraction for the
builders while the do the redesign, and a bad reputation for the
product that the best design will find hard to live down."
James Kanze
> On Oct 2, 7:57 pm, James Kanze <james.ka...@gmail.com> wrote:
> > "Premature optimization" is a pessimization of corporate
> > resources, not an optimization of them; it is a case of
> > exchanging a rare resource (the time of competent programmers)
> > for a rather cheap and readily available resource (machine
> > time).
> Not only machine time! Clients time as well and clients time is
> valuable, don't you think so?
And how. If you deliver late, that's time the clients don't
have the software to use, so the lose money. And nothing costs
client time more than bugs. Using your programmers effectively
can ensure on time delivery and fewer bugs.
--
James Kanze
Rune Allnor
From the client's POV, *not* having a SW tool can be far better
than having a buggy SW tool:
A) The ideal, desired case: The SW tool is available, works
smoothly and gets the job done in no time at little cost.
B) One *knows* one does not have the perfect tool for the job,
one plans for that situation: Uses inefficient, time- and
resource-consuming ways to get the job done anyway. In this
case one *knows* the job will take time, and plan and act
from that realization.
C) One *thinks* one has a SW tool for the job, but in reality
has a bug-infested useless program.
Case C) is the killer, since one *thinks* one his in case A)
and plan according to being in situation A). Once mayhem and
misery break out, one is unprepared and far more vulnerable
to damage than one would be in case B). In case B) one has a
realistic view on the situation, and can either avoid the
really bad cases or maybe prepare for them.
Rune
Francesco S. Carta
Evolutionary prototyping and incremental development are both fine
with me (I mean, as names for that process).
If the definition happens to be shared in a certain context, sticking
to the stricter "prototype == throwaway pilot implementation" is fine
too.
Luckily, we succeeded clarifying this without any bloodletting -
likely to happen within "stack" or "heap" discussions, to name the
most (in)famous ;-)
Nice read, thanks for reporting it. At this point I suppose we all
agree that delivering a throwaway (the stricter-meaning prototype) to
customers is really a bad move on the managerial part, while shipping
out a beta version (a somewhat evolved production-prototype) to be
tested can be fine - as long as it is correctly labeled as such to the
customer.
The discussion about all of this stuff can become quite long, but I
suppose we have already high-jacked this topic enough - we have also
drifted off-topic enough, wrt clc++... whatever, if these thread-
branches will grow, will grow, and wouldn't be that bad.
jimxoch
In case the product is unacceptably slow you might loose even more
clients/money! The MS-Word 6.0 for Macintosh is a very notable example
of this. This Word edition was so slow, that almost all the Mac users
I knew back then quickly moved back to Word 5.1. According to
Wikipedia (http://en.wikipedia.org/wiki/Microsoft_Word): "many accused
it of being slow, clumsy and memory intensive. In response to user
requests, Microsoft offered a free "downgrade" to Word 5.1 for
dissatisfied Word 6.0 purchasers."
My conclusion is that, of course time of delivery is important, but
even more important is to deliver a product which behaves correctly.
Delivering on time a low-quality product (quality includes acceptable
performance) rarely works. Not even for the mighty Microsoft! Clients
has been repeatedly proven that often prefer less/delayed
functionality from bad functionality.
James Kanze
> On Oct 3, 12:53 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Oct 2, 7:13 pm, jimxoch <dpxguard-goo...@yahoo.gr> wrote:
> > > On Oct 2, 7:57 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > > "Premature optimization" is a pessimization of corporate
> > > > resources, not an optimization of them; it is a case of
> > > > exchanging a rare resource (the time of competent
> > > > programmers) for a rather cheap and readily available
> > > > resource (machine time).
> > > Not only machine time! Clients time as well and clients
> > > time is valuable, don't you think so?
> > And how. If you deliver late, that's time the clients don't
> > have the software to use, so the lose money. And nothing
> > costs client time more than bugs. Using your programmers
> > effectively can ensure on time delivery and fewer bugs.
> In case the product is unacceptably slow you might loose even
> more clients/money!
So don't deliver a product that is unacceptably slow. That
seems obvious. If you need the profiler to do this, then you
use the profiler. Optimization after profiling, when actual
experience has shown it necessary, is not premature
optimization. (In fact, premature optimization can often make
the necessary optimization more difficult.)
> My conclusion is that, of course time of delivery is
> important, but even more important is to deliver a product
> which behaves correctly.
Where did I say the opposite. I specifically said "nothing
costs client time more than bugs". A program which doesn't meet
its requirements is an error; if the requirements involve some
minimum performance (and all do, in practice, even if the
requirement is unstated), then meeting those is part of writing
correct software.
--
James Kanze
jimxoch
Well, I have to apologize now.
I didn't noticed in your first mail that you were talking about
"Premature optimization" and not about optimization in general. And of
course I agree 100% with everything you say in your last e-mail.
Sorry about the misunderstanding.
jimxoch
Good news! I have suggested a relative survey to CodeProject and its
now a fact.
You can vote at the bottom of the www.codeproject.com page. (Please
do...)
Please note that this survey is not asking directly about the
premature optimization, but aims get answers about more basic
questions. (In which project-phase the programmers tend to optimize.)
However, its a start. To ask directly about premature optimization,
without knowing this basic stuff might not be a good idea, since there
is an strong dispute among programmers regarding the definition of
"premature" optimization. Nevertheless some possible answers in this
survey can be very interesting...
Nedless to say that the results of a survey are not proofs, but I
believe they are at least useful indications.