Re: Aspiring highest-order programmer

From: Programmer Dude (Chris_at_Sonnack.com)
Date: 06/08/04 

Date: Tue, 08 Jun 2004 08:23:04 -0500

Edward G. Nilges writes:

> Some programmers, not all, think that their compiler defines the
> syntax when in fact the abstract rules of the language define the
> syntax. The result in my experience is that a BROKEN compiler can
> replace the abstract rules which entraps the company into
> dependence on the vendor of the broken compiler.

I think you're overstating on several counts. I'd say few programmers
feel their compiler defines the *language*, but many understand that
compiler idosyncrasies can define how they *use* a compiler. (Better
programmers will avoid such things, obviously.) And while I can
imagine a (foolish) dependent relationship with an implementation,
I doubt the parties involved are unaware of the realities.

> There are two types of programmers.

There are 10 types of programmers.
Those who know binary and those who don't.

> Type A retains an awareness prior to the computer, that human beings
> evolve abstract ideas [...that...] are independent of any one mind
> and yet would not exist without a network of minds.
>
> Type B is postcomputer and occludes the instantiation of the idea
> with hardware and software artifacts which to type B have a false
> authority.

Foibles of youth. They'll learn.

>> Short-circuiting of boolean operators is defined by the LANGUAGE
>> DEFINITION, and programmers MUST know what their LANGUAGE defines
>> for these operators--we do agree on that.
>
> Then why is it, dear boy, that many programmers are unaware of these
> types of semantic issues?

Same reason many drivers are unaware of driving skills. Many people
are ignorant.

My guess: your hanging with the VB crowd has given you a biased view
of programming ineptitude. I don't know of ANY professionals who
think the compiler defines language or that are unaware of boolean
evaluation modes. VB is bad for programming in the same way that AOL
is bad for amUSENET: it let in the riff-raff.

If you got over yourself and hung with a better crowd you might (A)
learn a few things to good use and (2) realize how many skillful and
intelligent, thoughtful programmers there really are. Case in point,
the guy who's place I'm taking in my new job. Wish he wasn't moving
on--I'd enjoy working with him. As I have many others.

>>> And if we proceed deeper into "the inner workings of the compiler"
>>> we find that at no level is it a black box such that we can safely
>>> and at all times ignore its inner workings.
>>
>> Sure there is. I've never needed to know about any compiler's
>> internal symbol table or token handling sub-systems. I've never
>> needed to know about LOTS of compiler sub-systems, and I've found
>> a number of languages where treating the compiler as a black box
>> was perfectly appropriate.
>
> You need the symbol table when you debug.

Not the compiler's internal one! Not the one inside the blackbox.
You get a *published*, public one in a standard format.

> As to token handling, the way it works defines the lexical syntax.

In fine detail, anyway--larger syntax elements might be handled during
parse. But, again, there is no need to look inside the blackbox to
see how it works. Could be little daemons chewing off the bits for
all I care.

> I concur with your obvious respect for levels and I am only trying to
> deconstruct the notion that a program is a machine and not a text.

That's a little odd coming from the guy who's been touting literary
programming here and who has, I'm quite sure, declaimed many times
how programs ARE, in fact, text.

>>> For example, in debugging, we have to know how the compiler optimizes.
>>
>> Nonsense. I've debugged very successfully for decades while leaving
>> compiler optimization completely alone. And it is best left alone
>> most of the time.
>
> In many compilers you at a minimum have to know it exists and when to
> turn it off in order to debug, for if you do not turn it off, the
> generated ML can be completely opaque.

Assuming you're needing to debug down to that level at all,... maybe.
But do you see the recant in "HAVE to know how the compiler optimizes"
and "know it exists and [how/when] to turn it off"?

You really need to stop seeing the world in such lurid superlatives
and binary absolutes. 

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Relevant Pages

  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: Why C for operating systems
    ... This kind of modification of the language is something that is useful ... extensions in the compiler. ... That's where Lisp shines: you can easily ... Homoiconicity is when the syntax to write data is ...
    (comp.programming)
  • Re: Compiler and an interpreter
    ... >> Suppose in a source-code file, the 4th line contains the first syntax ... >> error.Can anybody please tell me how the compiler and interpreter will ... Some small unit of the language is an acceptable input. ... Perl does not to my knowledge in any way require the reading of the ...
    (comp.programming)
  • Re: RFC : SOME IDEAS FOR THE APPLE II FPGAers
    ... that only a few system programmers really needed. ... After porting a compiler to a new machine, ... use the other half of the machine's memory for profile counters ... etc. and hand craft the critical sections in assembly language. ...
    (comp.sys.apple2)
  • Re: Multiple assignment
    ... > on language design from someone else who understands it to this ... > compiler can achieve the same quality of generated code without ... I think that most programmers' idea of "efficiency" ... functionality out of every line of code, ...
    (microsoft.public.vb.syntax)