Any surveys about the premature optimization status nowadays?

[Francesco S. Carta]

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.

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

 

[Francesco S. Carta]

...


Thanks anyway. Hope dies last

You're welcome, and... "hope": here I am! the first among its
supporters ;-)

Cheers,
Francesco

 

[Francesco S. Carta]

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,
Francesco

 

[robertwessel2]

On 2 Ott, 00:43, "(e-mail address removed)" <[email protected]>
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]

 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.

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]

...


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...

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 J. Bourguignon]

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?


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.

 

[James Kanze]

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).

 

[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?

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[robertwessel2]

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]

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.

Yep.  Always use the tools that best fit the job at hand.  "Best," of
course, has to take in your familiarity with the tools.



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.

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]

Then you're missing the point of a prototype, and following some other
iterative methodology.

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.

 

[robertwessel2]

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.

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]

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.

 

[Rune Allnor]

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.

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]

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.

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 ;-)

*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."

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]

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! 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.

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[James Kanze]

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.

 

[jimxoch]

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.)


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.

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.

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[jimxoch]

Hi all,

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.

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/