Re: Real World Programming - It aint in the books!

-----Original Message-----
From: Hailedav <hailedav(at)erols.com>
To: HWG-theory <hwg-theory(at)hwg.org>
Date: dinsdag 2 juni 1998 12:51
Subject: Real World Programming - It aint in the books!


>Real programming, I suspect is more than making objects fly across
>pages.

Got that right, although making objects fly across pages is part of it. Real
programming extends into more areas than I would care to mention, including
compiler design, operating system design, parallel programming and
distributed systems (which are not really two separate things) and many
others.

>However, for the life of me, I cant find a book that really
>delves into PROGRAMMING.

You want A book about programming? A book, as in ONE book? Forget it. I
asked that question ("what is programming") of a some people two years ago;
when they finish giving me the answer (in about 4 years), I'm going to get
an engineering degree which will say that I am an engineer of Computer
Science.

>For example, WHEN is it best to use an array,
>versus a dynamic array,

When it suits you.
That is not a question a REAL programmer will ever ask himself. Someone who
writes REAL code, for actual use in some commercial (or otherwise important
system) solves the problem first. By the time he's done with that, the
answer to the question of what kind of data structure to use (array, linked
list, tree, etc) is either a present from the solution he's found, or a
design choice which logically yields the best results with respect to
performance and use of storage.

>and what the heck is a two-dimensional array?

An array of arrays. An array of which each element is itself an array.
If you know what an MxN matrix is in mathematics, that's what a 2D-array is.

>And where the heck are the examples!?!


Any good book has examples of the subjects it covers. There's just not one
single book to cover what you want to know.

>Now, lest you think I'm just lazy, I've got several books on
>JavaScript, VBScript, and ASP. ALL of which just show the basics of
>"For..Next" loops and "If..else if" type decision structures. After
>that, well they all just leave you hangin'. All that's left is a list
>of indexed keywords which (very briefly) explain what they do. Since
>my platform is Win95/PWS 4.0, I have tried to concentrate on VBScript
>(I'm also studying Visual Basic), but again once past the "basics" all
>"training" seems to stop. It all becomes "reference-like".


You're suffering from a misconception. Programming is not about knowing
languages. Programming is about finding solutions to problems which require
some calculation or another. Once you've found that solution, THEN you need
a language to implement your solution in. THAT is when you use references.

An example of a realistic problem:
Given a base number k and an exponent N, calculate k^N.

The obvious solution is a straightforward loop:

int r , i;
r = 1; i = 1;
while i < N do r = r*k; i = i++ od

That is a correct solution. However, it might not be the best solution.
Making use of the properties of exponentiation, you might be able to find a
better solution.
First, notice that:

k^0 = 1
k^n = | k^(n div 2) * k^(n div 2) if n mod 2 = 0
         | k^(n div 2) * k^(n div 2) * k if n mod 2 = 1

So, we find a better solution:

function exp(int base, int exponent){
  int res;
  if exponent == 0 then res = 1
   else
     if (exponent mod 2) == 0 then tmp = exp(base, exponent div 2); res =
tmp * tmp
     else tmp = exp(base, exponent div 2); res = tmp*tmp*base
; return res
}

int result = exp(k,N);


That is what programming is all about. First you find a solution to your
problem. Whether to use an array or not doesn't enter into it until later,
when you are ready to implement your solution.

>So what's the key? How do I learn the REAL power of programming (in
>VB), like doing calculations?

The calculations are all founded in mathematics. Get the maths right and the
problem is solved.
Then you worry about languages like VB.

>How does one decide the programming
>tasks?

That depends on the problem at hand. Sometimes it is straightforward,
sometimes you have to break it down into section. Sometimes that is easy,
sometimes you need lots of people to do it.

>How can I truly learn to get past the limitations of all of
>these "intro" type books and get into some real stuff?


The only real way is to spend some time studying. Following a real course,
given at a university or something like that.
And if you want REALLY REAL programming, that is going to take time. As I
said, the course I am following takes five years, and I'll probably take six
to complete it. And be a full engineer when I'm done.

Hey, nobody ever said it was EASY ;)

>How about real life programming scenario's? How the heck do I get
>beyond  simple statements when all my reading suddenly say's "That's
>it!"


Translate the problem into a (set of) calculation(s) to perform. Translate
those into a way you can easily perform the calculations (you might not be
able to easily calculate whether a < b, but a <= b might be easy; from
there, it's a small step to a < b).
Then find a way to do the calculations.
Then translate that into something you can feed through a compiler.

There was a fashion for using flow charts a while back. Try breaking a
problem up into chunks and modeling the flow of execution in a flow chart.
That's something to cling to at least.

>How does one logically go from the list of keywords to creating an
>algorithm?

You don't. That's the half-assed way of doing it. Also, it's backwards.
FIRST find a solution, then write the solution down using keywords.

>What are the FIRST things any programmer should do when
>designing a program? How does one begin to "think" like a programmer.


Analyse the problem. Rewrite the desired outcome in terms of a desired state
of the machine. Then from there, determine how to maneuver the machine into
that state.
We do it by finding a methematical relationship on the different variables*
to work with and to maintain. Change one, calculate what the effect on the
others is, adapt their values to maintain the relationship. Make sure the
program ends and your solution is found.

>From the example above, about exponentiation, during execution the program
strives to maintain the relationship exp = base^exponent. Once the program
terminates, result = exp(k,N) = k^N.

* actually not on the variables, but on what they represent.

>As an example let me pose this scenario:
>
>I want to create...say, a mortgage calculator for my (fictional)
>online real estate site.
>As a programmer, what are the steps to creating a successful
>application? I'm not looking for CODE, but the logical (identifiable)
>steps necessary to plan, test, and debug the application.


1. What is the desired result of the program? What answer is it that I seek?
Can I formulate that answer in some formal way? Maybe as a mathematical
formula?
2. Can I calculate the answer directly, or do I need several steps? If so,
what relationship(s) must I maintain between steps (for instance, after the
nth step, I might want a = b^n, for n in some range).
3. Am i certain that once my planned calculation is done, I will have the
answer I seek? Or at least that I can easily find the answer from the
result?
4. Can I initialize all my variables correctly? Do I have enough information
for that? Or have I come up with an initial state that is so strong, I can't
implement it? If so, can I do something about that?
5. If my calculation is to proceed in several steps, how will I set a step
(for instance, increasing n by one)?
6. How will taking a step affect the relationships I wish to maintain? How
must I alter the values of other variables to keep the relationship intact?
7. Am I sure my solution will complete its calculation in finite time?
8. Done.

Those steps can guide you through the basic programs.

>What should happen BEFORE I begin coding?

You should work out what your program must do and HOW it must do it.

>How to outline the STEPS
>necessary to create the application? What would you do?


See above.

Ben Z. Tels
optimusb(at)stack.nl
http://www.stack.nl/~optimusb/

"The Earth is the cradle of the mind, but one cannot stay in the cradle
forever."
                                                    --Tsiolkovsky

HWG hwg-theory mailing list archives, maintained by Webmasters @ IWA