Re: OT: programming (was OT More pens)
From: | Andreas Johansson <andjo@...> |
Date: | Tuesday, June 10, 2003, 17:11 |
Quoting Stone Gordonssen <stonegordonssen@...>:
> > > ::pet peeve:: As a programmer/analyst, I am immensely tired of
> todays
> > > point&click programmers who have no idea of the wasted overhead and
> bad
> > > code
> > > they generate when they let the interpreter/compiler generate the
> real
> > > code.
> >
> >Knowing that compilers aren't too efficient is very good alright, but
> >writing
> >everything in ASCII isn't really a realistic alternative, is it? Or am
> I
>
> There are very few people today who would need to write ASCII or EBCDIC,
> but
> there are a few rare instrances when this might be the solution (e.g.
> patches to bugs in existing modules/applications).
As I wrote in my correction, "ASCII" was a braino for "Assembler". But it
seems I indeed misunderstood you ... ;
> >misunderstanding you? "Point&click" doesn't really seem to fitting to
> my
> >(amateurish) programming habits.
>
> It goes deeper than that, and depends on scape - is the code intended
> for
> personal use? or distribution to thousands worldwide.
>
> I'm not sure this list needs lessons in the hows, why & methods of
> efficent
> programming.
>
> But let's take a simple but exagerated (I hope) example:
>
> I want to add two numbers together and display the result using
> programming
> language X.
> In language X and I have two choices:
> write 2 lines of primitive code: A + B = C and DISPLAY C
> or
> write 1 line using a built-infunction: DISPLAYSUM (A, B).
>
> On the surface, the 2nd seems simpler - only one line.
> But behind DISPLAYSUM is a long list of code -
> 1. determine via many steps how many arguments are given
> 2. determine via many steps the type of each argument, and extract the
> digists from each
> 3. use those digits to create internal floating-point numbers
> 4. run a loop to add together all the floating-point numbers from as
> many
> arguments as were initially given.
> 5. convert the result from that loop into a a format a human can
> readily
> understand
> 6. display that result.
>
> If the point&click GUI (graphical user interface) always uses
> DISPLAYSUM, a
> lot of processing power has been wasted to do a very simple operation.
I've never yet used any graphical programming tools; I write F code in NotePad
or MSEdit and operate the compiler via a command prompt. You see way I didn't
think point&click apply to me.
Andreas