[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT programming languages/ systems for advanced applications on Linux



On 2011-12-24 14:06:20 -0800, David Christensen wrote:
> As you can see, there's more than one way to do it (TIMTOWTDI).  (And,
> probably more than I found.)  There are even more ways that appear correct
> upon casual coding, but either generate errors/ warnings (lucky you) or have
> some subtle bug (you poor slob). (My example surely contains the later.)

You can also write less concise code and have fewer bugs.

> Once you find enough no-error-or-warning-message choices and lay them out
> side by side, some method to the madness can be observed.  But, finding all
> the possibilities, finding a choice you like, or even just finding a choice
> that works can be very daunting, especially when faced with a blank screen.

You don't have to find all possibilities! Just take the first one
that comes to your mind. You can improve it later, but this is like
optimizing code in any language...

> Understand that there is no specification for Perl 5; the implementation and
> regression tests serve as the de facto standard.  So, finding the rules for
> enumerating all the correct possibilities for a given decision means
> analyzing the source code of Perl itself.  I'm not going there.

There is documentation. Just avoid what isn't clearly documented.
You do not have to read the Perl source code!

> As best I can figure, writing a computer program involves making some
> number, N, of key decisions.  With a Python motto, you make 1**N = N
> decisions and you're done.  With a Perl motto and M choices per decision,
> you need to explore M**N possibilities.  Both presume at least one correct
> choice for each decision.  (That's why a comprehensive and high-quality
> library is required for a language/ system to be "general purpose" and
> generally usable.)

You do not need to explore all the possibilities. Just take one.

I sometimes hesitate between several solutions, but very often, it's
from an algorithmic point of view. There would be the same problem
with any language.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


Reply to: