Re: Multiple assignment

From: Tony Proctor (tony_proctor_at_aimtechnology_NOSPAM_.com)
Date: 07/22/04 

Date: Thu, 22 Jul 2004 14:33:18 +0100

:-) I can almost guess your age from this reminiscing Russ. Compiler
listings? Yeah, I used them a lot too. These days, I'd settle for some
better display options in the IDE (e.g, paginated, cross-references,
variable usage, etc) -- similar thing, I guess, except a screen-based
version.

As for Split/Join/friends, I admit to being guilty of this myself. It's
usually an exercise in parallel thinking. However, sometimes, they do
achieve the job more efficiently because (a) VB6 doesn't have
state-of-the-art code generation, and (b) the VB runtime isn't written in VB
itself. I take your point though.

            Tony Proctor

"Russ Holsclaw" <russ@holsclaw.nyet> wrote in message
news:u#UXox#bEHA.2388@TK2MSFTNGP11.phx.gbl...
>
> "Tony Proctor" wrote
> > This is proving to be an interesting read Russ. It's rare to
> see a discourse
> > on language design from someone else who understands it to this
> extent.
> > Sadly, I moved on from most aspects of language design and
> implementation
> > once compilers became a commodity, and the case for specialised
> or
> > proprietary languages all but disappeared.
> >
> > I believe one of the arguments for C's (and all its
> derivatives) "elided
> > operator" syntax was for efficiency. However, a good modern
> optimising
> > compiler can achieve the same quality of generated code without
> most of the
> > hidden i++, i--, etc. It may have helped in the early
> compilers, but it now
> > serves only to "optimise" the writing of the source code,
> albeit obfuscated
> > in the process
>
> Yes, even back in the '60s a great deal of progress was being
> made in compiler optimization, even to the point of moving
> redundant code out of loops and such things as that. Then, C came
> along and fell back into the notion that optimization was the job
> of the programmer, partially to make the compiler easier to
> implement, I think. In many ways, C is nothing more than a
> relatively CPU-independent assembler language, rather than a true
> "High-level" language.
>
> Furthermore, I think that most programmers' idea of "efficiency"
> seems to be more closely related to squeezing the most
> functionality out of every line of code, as though the CPU
> executed "lines of code" at a fixed rate, rather than machine
> instructions. In these newsgroups, I often see programmers
> suggesting the most outrageously inefficient, and often
> incorrect, coding practices, just to keep some piece of
> functionality down to one line. I've noticed, for example,
> getting back to "classic VB", that people are using Split and
> Join functions to do parsing in all sorts of inappropriate ways,
> often in ways that fail to cover all the cases, just because they
> don't want to code even the simplest of loops. Ditto with the
> "Like" operator.
>
> In the first years of my career, we worked on code printed on
> stacks of fanfold paper, instead of looking at it on display
> screens. Although I really wouldn't want to go back to the days
> of keypunching lines on code on cards and waiting hours to get
> back a compiler printout, I've also noticed that this notion of
> looking at code only in the context of an IDE editor has created
> a sense of "tunnel vision", cause by the limitations on how much
> code we can actually make visible at one glance.
>
> This has resulted in a drastic reduction in good in-line
> documentation (comments) as well as a pathological desire to
> squeeze too much function onto each line, obfuscating the code,
> and falling prey to the guilty pleasures of impressing oneself
> too much with one's own "cleverness" writing trick-laden code.
> (This is an argument, actually, for giving programmers as big a
> display screen as can be accomodated, perhaps even multiple
> screens.)
>
> Sometimes I find it useful to engage in the "retro" activity of
> printing out code modules on paper so I can see more of the code
> at once, and mark it up with a pencil. Sadly, compilers no longer
> produce the kind of program listings we used to produce, where we
> used compiler directives that started new pages at appropriate
> breaks in the code, set page headings, and produced
> cross-referenced indexes of variable usage.
>

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: Statement on Schildt submitted to wikipedia today
    ... to working programmers and more with being "right all the time, ... so that compiler developers could be shed ... The major corporate interests were compiler developers, ... processors, committed to standard division semantics, and otherwise ...
    (comp.lang.c.moderated)
  • Re: Interesting article by Randall Hyde
    ... as you are the compiler optimization "expert". ... of the work that has gone into creating optimizing compilers. ... > Compilers generate better code than *most* programmers all of the ... learn without needing to know anything about assembly language. ...
    (comp.lang.asm.x86)
  • Re: FC4 good new tech, bad legacy support
    ... Often programmers abuse weaknesses in the strictness of how a ... >compiler implements a programming language. ... because an older compiler version seems to accept source code ... >which it should not accept according to programming language standards. ...
    (Fedora)
  • Re: Integer types in embedded systems
    ... Notice the integer type I've used, ... compilers for 8-bit micros have an option for telling the compiler not ... Most C programmers these days are woefully ignorant, ... At least as important as portability, ...
    (comp.lang.c)
Quantcast