NYCPHP Meetup

[Tim Gales]

> -----Original Message-----
> From: talk-bounces at lists.nyphp.org
> [mailto:talk-bounces at lists.nyphp.org] On Behalf Of James Wetterau
> Sent: Wednesday, April 14, 2004 2:35 PM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] Is it worth learning Python too?
> 
> "Tim Gales" says:
> ...
> > > Another important practical distinction is that a high-level 
> > > language is presumably portable between different computers.
> > 
> > Who is doing the presuming in your view?
> 
> I am, but I think this is not an uncommon view of a key advantage of
> high-level languages.
> 
> > A language author creates a language to be useful.
> 
> At least in the case of C, a component of that usefulness was
> portability across platforms, and I think today it is commonly 
> expected that portability across platforms is a key aspect of the 
> utility of high-level languages.
> 
> Kernighan and Ritchie, the authors of C say about C in their

Kernigan has said, "C is entirely the work of Dennis Ritchie, 
I am but a popularizer..."
(http://www-2.cs.cmu.edu/~mihaib/kernighan-interview/)
  
> classic book "The C Programming Languages", 2nd ed., in the
> introduction: "Although C matches the capabilities of many computers, 
> it is independent of any particular machine architecture.  With a 
> little care, it is easy to write portable programs, that is, programs 
> that can be run without change on a variety of hardware.  The standard 
> makes portability issues explicit, and prescribes a set of
> constants that characterize the machine on which the program is run."

Early C certainly did match the capabilities of the 'Digital 
Equipment Corp.'-like  machines of its day on which 
the Unix operating system was born. C operators bear 
such an uncanny resemblance to the underlying DEC assembly 
language instruction set, that an experienced Macro-11 
programmer (again of that time) might have tried looking up 
information on the SWAPB operator in the C language reference 
manual.

C was popularly thought of in its early days as a special-purpose 
language for Ken Thompson's experimental operating system.
I think most people agree that this proved eventually to be a 
misconception. Perhaps what clouded things was the way C seemed 
to evolve from Thompson's B language (which really was a special 
purpose language).

I am guessing at this, but I think that by the time the 
the book came out, the authors realized the C language could have 
more applications than just facilitating the porting of Unix.

Either way, C was ported to other Non-DEC like hardware and OSs, 
but only by creating what approaches being a Unix emulation 
layer in the runtime library for the different architectures.

Early C developers on non-unix platforms often used to say that they 
got NUXI 'd when their runtime implementation didn't implement the 
proper Unix (DEC) byte ordering.

My point here is that Ritchie may well have discovered the more 
general nature that C could become when he tried to implement 
the runtime library on different architectures.
(this is just conjecture on my part of course)

> 
> I think the last sentence pertinent to the ANSI standard is
> particularly telling -- portability, which was implicit in the 
> language from very early on was made explicit in the standardization 
> process of the 70s - 80s.
> 
> I am humbled to report, in the spirit of full disclosure, that the
> text in the preface describes C as 'not a "very high level" language', 
> and the text in the introduction describes it thus: "C is a relatively 
> 'low level' language."
> 
> So we seem to be in a semantic muddle.  Perhaps the correct
> description would be: C is a standardized, portable relatively low 
> level language for a high level language which is not a very high 
> level language.
> 
> Maybe C would best be thought of as a middle level language; we could
> call it a "mezzanine" language.
> 
> > If he/she is successful, i.e. the language proves to be useful, 
> > other people port it to their systems so they can also take 
> > advantage of it.
> 
> Or in the caes of K&R, I believe they did the first couple of ports
> themselves.
> 
> > Maybe some authors of languages have a design goal of not burning 
> > any bridges when it comes to portability -- since
> 
> In the case of K&R they were going for portability from early on so
> that they could easily move this large program

Now who's guilty of over-simplification (just joking) -- 
but there exits more than one layer to an operating 
system (hardly one program now matter how large). 
You know, like Linux is a kernel not an operating 
system.

> they had
> written called "Unix" from one computer to another without having to 
> rewrite huge chunks of it ever time.
> 
> ...
> > different types of systems, but by and large computer languages are 
> > created to get something done in one environment.
> 
> You may be right, but I don't believe that's the case with C/C++ and
> Perl, to name just a few.
> 
> > Even Java, which now even runs on my cell phone, was designed to run 
> > in a closed environment -- namely set top boxes.
> 
> Well, this is a simplification.  The first prototype of Java (called
> "Oak") was meant to run on a variety of set-top boxes (to get ready
> for the coming "digital convergence").  It was meant to be processor 
> independent but to present a consistent programming environment and 
> language.

Here again though, the runtime environment would provide a layer 
of abstraction -- this time as byte codes in a virtual machine.

> Evidently a contingent
> at Sun expected that something that would be sort of a hybrid between 
> cable modems, web tv, movies-on-demand, and TiVO, probably working 
> over the internet, was going to be the next big thing in 1991.  Not 
> completely wrong, but not exactly right.
> 

Okay. The waters *are* rather murky here.
But maybe there is some relationship like:

B is to C as Oak is to Java.

If so, both roots of the languages seem to have started 
to help solve a specific problem as their main purpose for 
being, regardless of any later metamorphosis.


> ...
> > > The definition of a compiler or interpreter or virtual machine 
> > > includes the ability to read source code in a high-level language 
> > > and generate correct executable programs for different kinds of 
> > > computers.
> > > 
> > 
> > No, I don't think portability has anything to do
> > with being a high-level language.
> 
> Well, I think it's a commonly associated feature, and a
> non-portable high-level language would be a gross exception.  
> I suppose a vehicle doesn't have to have seats to be a car, 
> and I don't know if the definition of "car" should include 
> the idea that there are seats in it, but it seems to me to be 
> the convention.  Similarly, I think portability is a commonly 
> expected advantage to high level languages.

I would agree that people have come to expect a portable 
library with modern languages -- which in effect makes them 
portable.

It just strikes me that it is the level of abstraction or the 
distance from the hardware that is the main determining factor 
in where to place a language in terms of it being high level or 
low level.

And it was probably too harsh of me to say:
  "I don't think portability has anything to do
   with being a high-level language."

Sorry 'bout that.

T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com