Searching \ for '[EE] Obituary - John Backus, FORTRAN team leader' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=obituary+john+backus
Search entire site for: 'Obituary - John Backus, FORTRAN team leader'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Obituary - John Backus, FORTRAN team leader'
2007\03\24@190006 by Jinx

face picon face
en.wikipedia.org/wiki/John_Backus

2007\03\25@074428 by Vasile Surducan

face picon face
God rest him in peace!
Fortran tortured a lot of people  (I was one of them in the era of
holes in carton cards). I'm not sure but I've seen a fortran compiler
for PIC (or it was forth?)


On 3/25/07, Jinx <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
> http://en.wikipedia.org/wiki/John_Backus
>
> -

2007\03\25@083512 by olin piclist

face picon face
Vasile Surducan wrote:
> Fortran tortured a lot of people

Maybe you didn't mean it that way, but it sounds like a very unfair
statement.  Fortran was the first high level language, and as such it was a
brilliant idea and a major breakthru.  It's unfair to judge it against more
modern languages that had the luxury of seeing what worked and what didn't
in practise.  Even despite that, Fortran got a lot of things right.  The
first attempt at a high level language without real experience with any high
level language could have been a lot worse.  You can only judge a idea in
the context of its own time.

Now if you want to complain about C I won't argue.  The state of compiler
development and the experience with how humans make coding mistakes and how
a compiler can help was far enough along that many design decisions in C
were irresponsible in my opinion, even when judged against the information
available at the time.  C only became popular because it tagged along with
Unix.  I shudder to think of the millions of man-hours wasted over the years
due to bad choices where the C designers should have known better.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\25@094734 by wouter van ooijen

face picon face
>> Fortran tortured a lot of people
>
> Maybe you didn't mean it that way, but it sounds like a very
> unfair statement.

I totally agree. Fortran was quite an achievement for its time. IMHO it
was used far after its date-of-last-consumption, but that was not John
Backus's fault. After Fortran he made interesting contributions to the
field of functional languages.

> Now if you want to complain about C I won't argue.

Now I think you fall into the same trap. C (as a contribution to the
field of programming languages) has to be judged not only with respect
to the thepry available at the moment, but also against the objectives
and resources the designer(s) had at the moment. In that respect it is
also a major contribution (compare it to BCPL and PL/1). IMHO it is
(just like Fortran) usef far beyond it date-of-last-consumption, but
that's the users fault, not C's. IMHO Chill and Ada would have been good
alternatives.

But we are all held down by existing investments: C and Fortran
compilers and libraries are probably the best around, so anyone who
wants to use another language starts with a hughe disadvantage. Only
incremental steps like C++ seem to take a foothold. IMHO C++ is both a
brilliant design, and seriously flawed by its basic assumption: (almost)
full backwards compatibility with C. But any other choice would have
made it a marginal language...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\03\25@100011 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> The first attempt at a high level language without real experience with
> any high level language could have been a lot worse.  You can only judge
> a idea in the context of its own time.

I wholeheartedly agree.


> Now if you want to complain about C I won't argue.  The state of compiler
> development and the experience with how humans make coding mistakes and
> how a compiler can help was far enough along that many design decisions
> in C were irresponsible in my opinion, even when judged against the
> information available at the time.  C only became popular because it
> tagged along with Unix.  

I think there's a major but common misunderstanding. IMO C is not a high
level language, it is a structured (and reasonably portable) assembler. As
such, it works quite well (for me; YMMV, of course -- and in your case it
clearly does :)  

The origins of C support that: it was created to provide a (low level)
implementation language of an OS, designed for being able to port the
system to different hardware. That people then used it for everything else
under the sun is not a wrong choice of the language designers.

See also
<http://en.wikipedia.org/wiki/C_%28programming_language%29#Philosophy>.


> I shudder to think of the millions of man-hours wasted over the years due
> to bad choices where the C designers should have known better.

Or maybe also: I shudder to think of the millions of man-hours wasted over
the years due to bad choices where the system architects should have known
better (and should've chosen another language).

But then, there's a reason why both Fortran and C are used to this day in
applications where many better languages are available: huge libraries and
large amounts of code that are already there and that are most easily
interfaced from Fortran resp. C. (In a way, that is similar to the
discussion about the choice of metric vs US domestic sized hardware we had
a time ago.)

Gerhard

2007\03\25@102314 by olin piclist

face picon face
wouter van ooijen wrote:
> C (as a contribution to the
> field of programming languages) has to be judged not only with respect
> to the thepry available at the moment, but also against the objectives
> and resources the designer(s) had at the moment. In that respect it is
> also a major contribution (compare it to BCPL and PL/1).

Hmm.  Care to name a few of these major contributions to the field of
computer languages?  I don't think there was much ground breaking in the
design of C, and certainly a few steps backwards.  Type checking and its
advantage in creating more reliable code was already well known.  C might
possibly have been the first language where something like a assignment
statement also had a value, and therefore could be used as a expression.
This should have been a obviously bad idea, even at the time.  Both Algol
and Pascal predate C and must have been known (or certainly should have been
known) to the creators of C.

According to Dennis Ritchie, "The C programming language was devised in the
early 1970s ..." (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html).  The
original officially published definition of Pascal came out in 1971, but
Pascal was being taught to students as early as the late 1960s, and was
itself based on concepts of Algol from 1960
(http://www.engin.umd.umich.edu/CIS/course.des/cis400/pascal/pascal.html).

So I find it hard to make excuses for C given the knowledge and experience
from languages that were known in 1970, including Fortran, Algol, PL/1, and
Pascal.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\25@102901 by olin piclist

face picon face
Gerhard Fiedler wrote:
> The origins of C support that: it was created to provide a (low level)
> implementation language of an OS, designed for being able to port the
> system to different hardware. That people then used it for everything
> else under the sun is not a wrong choice of the language designers.

But there were irresponsible design choices made for C even within the
context of those goals.  For example, strong type checking with specific
syntax to disable it in those relatively unusual cases (even in operating
system code) where you need it would not have defeated their goals and not
made the resulting code less efficient.  Likewise allowing a expressions to
also perform assignments had no other advantage than a quick expedient at
the time of coding, with considerable disadvantage later.  Again, even with
compiler technology of the day the resulting code would not need to be any
different.

> In a way, that is
> similar to the discussion about the choice of metric vs US domestic
> sized hardware we had a time ago.

No, it's the other way around.  It would be as if metric had been around for
a while, but someone then deliberately created and had adopted english units
afterwards.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\25@114819 by Vasile Surducan

face picon face
On 3/25/07, Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> wrote:
> Vasile Surducan wrote:
> > Fortran tortured a lot of people
>
> Maybe you didn't mean it that way,

No one deny fortrans success at his time. I've just said it was a
torture for those who learn and practice it.
I'm one of the people which has very clear in mind the whole aspects
of that time technology, mostly because I still have on the wall a
16kbyte of ferrite memory
and the last computer running fortran with a HDD of 40Kbytes was
broken last month so I've taken a deep look inside...

I don't complain, just remember the facts...

but it sounds like a very unfair
{Quote hidden}

> -

2007\03\25@124248 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop)
> So I find it hard to make excuses for C given the knowledge and
> experience from languages that were known in 1970, including Fortran,
> Algol, PL/1, and Pascal.

Olin, this debate cannot possibly achieve anything useful. If you want
to use a straightjacket language, by all means, use one. As you say,
there are some out there that are even more mature than C.

C was designed to both generate reasonably efficent code for -- and also
have the compiler itself run on -- highly resource-constrained machines,
typically PDP-11 minicomputers with a maximum of 64KB of memory (at
least initially). As such, the design focus was on providing useful
abstractions regarding expression evaluation and control flow without
limiting access to the types of things you could do in assembly
language. Additional type-checking would not necessarily have affected
the generated code, but the compiler itself would have had to be larger
and more complex.

A lot of computer science and electical engineering students did their
first programming on such machines, so naturally C got a significant
"mindshare" for that reason alone. The same attributes that made it work
well on minicomputers also carried over to the early microprocessors,
giving it exposure to another group of budding programmers.

Yes, the flexibility of C gives you the power to easily do bad things,
but telling people not to use it is like telling me not to use a claw
hammer to build fine cabinetry just because the guy at the next bench
over keeps hitting his thumb with his.

No language feature -- including strong type checking -- is universally
an advantage. Sometimes you need to be able to treat a chunk of memory
as just a chunk of memory, particularly when writing operating systems
and device drivers. Strongly-typed languages can be a royal PITA when
doing such tasks. As always, you need to be free to pick the right
tool for the job.

-- Dave Tweed

2007\03\25@130100 by John Chung

picon face

>
> > Now if you want to complain about C I won't argue.
>  The state of compiler
> > development and the experience with how humans
> make coding mistakes and
> > how a compiler can help was far enough along that
> many design decisions
> > in C were irresponsible in my opinion, even when
> judged against the
> > information available at the time.  C only became
> popular because it
> > tagged along with Unix.  

 Programming languages need to get fame somewhere. At
that time it was Unix. Nowadays it is the companies .
Look at Java and C#.

{Quote hidden}

<en.wikipedia.org/wiki/C_%28programming_language%29#Philosophy>.
{Quote hidden}

 C was written basically to write the Unix OS. The
friendship between Dennis and Brian must be a
motivation for Dennis to actually write a new
language; tailored for such a task. He was kind enough
to add in portability into the language as he saw a
need for future porting for Unix. C may not be perfect
but does allow the programmer to have plenty of
expression at the lower level without the worry of
platform dependence*if he maintains good coding
practices*. Yes there were plenty of hours wasted on
debugging the kernel due to the C language but if the
OS was written using C++ can you imagine how much
greater the cache miss would be? Nothing is perfect
but C is very close to machine level and no closer. As
for me I can imagine the output in assembly for C
languages pretty quickly so it is not much of an issue
to me. I still prefer C if I can use it. Okay, I have
affection to the language 2nd to assembly.

I do find C++ and C libraries pale in comparison to
Java. The amount of Java libraries are HUGE!

John



____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
tools.search.yahoo.com/toolbar/features/mail/

2007\03\25@181544 by William Chops Westfield

face picon face

History of fortran:
  http://www.ibiblio.org/pub/languages/fortran/ch1-1.html

Fortran I was written 1954 to 1957 (wow!)

One must also remember the intended application space for fortran.
It's STILL not a bad language for the sorts of math-intensive
numeric processing that it was designed to do in the first place.
Yeah, it didn't do strings very well.  That wasn't the point.


On Mar 25, 2007, at 7:19 AM, Olin Lathrop wrote:

> Care to name a few of these major contributions to the field of
> computer languages [made by C]...

C was (one of?) the first language to separate the definition of
the language from the definition of libraries and IO behavior of
the runtime environment.  As such, C compilers were comparatively
easy to port to small systems like CP/M, MSDOS (and eventually
microcontrollers.)  Also, this led to some formal thinking about
library behavior (you might not recognize this as important unless
you've tried to do something like add formatted output functions
to Pascal and been frustrated by the way the language itself violates
the syntax defined for users' programs...)

Also, it's one of the few languages that allows explicit manipulation
of pointers to the degree necessary to write device drivers and similar
directly in the HLL.

As a result, C is portable, without changing the language syntax
specification, to a much wider variety of targets and applications
than any other language I can think of.  I'm not sure that these
issues SHOULD have been important (I mean, BASIC has flourished
largely by simply ignoring inconvenient parts of its original
specification as suited to a particular target, for example.)  But
I do think they HAVE helped be responsible for the proliferation of C.


> The original officially published definition of Pascal came out
> in 1971, but Pascal was being taught to students as early as the
> late 1960s, and was itself based on concepts of Algol from 1960

Existence in obscure corners of the world doesn't mean that it was
"well known" (especially back in those days.)  IIRC from my early
days of computing (mid to late 1970s) algol was relegated to obscure
researchers in algorithm design, and Pascal was an up-and-coming
"teaching language" (but not for "real" applications.)  (C was
similarly obscure unless you had unix, of course.)  All "real
programming" was done in Fortran, Cobol, or Assembly language,
unless you had IBM equipment, in which case you were grudgingly
converting to PL/1...  Complaining about C not using concepts from
Pascal or Algol is like complaining that JAL didn't pay enough
attention to Ada or Prolog...

That said, I don't think C did anything that was really "new" in
the field.  It's innovations, if you can call them that, were more
in the things that it LEFT OUT.

BillW


2007\03\25@194626 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> The origins of C support that: it was created to provide a (low level)
>> implementation language of an OS, designed for being able to port the
>> system to different hardware. That people then used it for everything
>> else under the sun is not a wrong choice of the language designers.
>
> But there were irresponsible design choices made for C

"Irresponsible"? You're clearly leaving the ground of facts here :)

> For example, strong type checking with specific syntax to disable it in
> those relatively unusual cases (even in operating system code) where you
> need it would not have defeated their goals and not made the resulting
> code less efficient.  

Maybe, maybe not. I'm not sure I need to remind you of Python (created much
later and has quite a number of followers) and the duck-typing concept. No
type checking at all.

> Likewise allowing a expressions to also perform assignments had no other
> advantage than a quick expedient at the time of coding, with
> considerable disadvantage later.  Again, even with compiler technology
> of the day the resulting code would not need to be any different.

It's always easier to be smarter later. Quick, efficient coding is /still/
a major goal, at least of professional coders. I'm not sure there's to this
day a better language to write a portable multi-user OS for smallish
systems. (No big need for this today, but there was at the time.)


> No, it's the other way around.  It would be as if metric had been around for
> a while, but someone then deliberately created and had adopted english units
> afterwards.

I disagree. The concepts of the SI have been around for quite a while --
enough for the rest of the world being able to convert to its units,
usually decades ago --, but many in the US still deliberately create
designs in US units (not English units; I don't think many English units
are still in use, at least not in the US) with the resulting errors in the
many needed conversions.

Gerhard

2007\03\26@074515 by olin piclist

face picon face
Gerhard Fiedler wrote:
>> For example, strong type checking with specific syntax to disable it in
>> those relatively unusual cases (even in operating system code) where
>> you need it would not have defeated their goals and not made the
>> resulting code less efficient.
>
> Maybe, maybe not.

Oh, and how would it not?  Type checking is only done at compile time.  It
should have no effect on the resulting code.

> I'm not sure I need to remind you of Python (created
> much later and has quite a number of followers) and the duck-typing
> concept. No type checking at all.

I'm not familiar with Python, but this sounds like a very good reason not to
bother.  I'm not sure what your point is about it having a large following.
That only makes it successful, we are talking about good design.

>> Likewise allowing a expressions to also perform assignments had no
>> other advantage than a quick expedient at the time of coding, with
>> considerable disadvantage later.  Again, even with compiler technology
>> of the day the resulting code would not need to be any different.
>
> It's always easier to be smarter later.

But my point was that enough was known about compilers at the time that this
was a bad design decision even within its own context.

> Quick, efficient coding is
> /still/ a major goal, at least of professional coders.

Wrong!  Professionals know that maintainence is usally a much larger cost
than initial coding, and that a little extra typing for clarity pays back
many times over later, and often immediately.  If you follow your argument,
you'd never type a single comment.

Besides, what's the big deal typing:

 i = j + 27;
 if (i > k) ...

versus:

 if ((i = j + 27) > k) ...


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\26@080429 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]
>On Behalf Of Olin Lathrop
>Sent: 26 March 2007 12:47
>To: Microcontroller discussion list - Public.
>Subject: Re: [EE] Obituary - John Backus, FORTRAN team leader
>
>
>
>Besides, what's the big deal typing:
>
>  i = j + 27;
>  if (i > k) ...
>
>versus:
>
>  if ((i = j + 27) > k) ...
>

No big deal as C allows either, and a professional wishing to write clear, self explanitory code would choose the former.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\03\26@084256 by Alexandre Guimar„es

face picon face
Hi,

>>Besides, what's the big deal typing:
>>
>>  i = j + 27;
>>  if (i > k) ...
>>
>>versus:
>>
>>  if ((i = j + 27) > k) ...
>>
>
> No big deal as C allows either, and a professional wishing to write clear,
> self explanitory code would choose the former.

   Not really.... What about the bunch of code that is already made ? The
language should encourage good coding practices and C does not do that at
all !

Best regards,
Alexandre Guimaraes

2007\03\26@090253 by wouter van ooijen

face picon face
>     Not really.... What about the bunch of code that is
> already made ? The
> language should encourage good coding practices and C does
> not do that at all !

I agree to some extent, but:
- no language (nor any other tool!) enforces "good practices", that's up
to the people
- what is considered "good coding practices" is surprisingly
context-dependent. the 2 and 1 line example (that I just trimmed out) is
an example: in *most* contexts the 2-line version would be preferred (if
not mandatory), but I can imagine contexts where the 1 line version
would be preferred.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu




2007\03\26@092314 by olin piclist

face picon face
wouter van ooijen wrote:
> - no language (nor any other tool!) enforces "good practices", that's up
> to the people

Yes you can make a mess in any language, and careful people can do a good
job in any language.  However good language design can make it more likely
mistakes are caught and not allow irresponsible programmers to do some
really irresponsible things.

> - what is considered "good coding practices" is surprisingly
> context-dependent. the 2 and 1 line example (that I just trimmed out) is
> an example: in *most* contexts the 2-line version would be preferred (if
> not mandatory), but I can imagine contexts where the 1 line version
> would be preferred.

Let's see some.  I find it hard to believe that whatever minimal benefit the
1 line version might provide in rare cases isn't far outweighed by it being
used irresponsibly.  Besides I'm not convinced you can come up with a
legitimate case where the 1 line version is of any real advantage.  I'm no
compiler expert, but I'm pretty sure that compiler technology of the early
1970s would have produced the same code for the two cases.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\26@095451 by wouter van ooijen

face picon face
> Yes you can make a mess in any language, and careful people
> can do a good job in any language.  However good language
> design can make it more likely mistakes are caught and not
> allow irresponsible programmers to do some really
> irresponsible things.

I don't think we will ever agree on this :) but:

What exactly was your opinion on assembly language?

> Let's see some.  I find it hard to believe that whatever
> minimal benefit the 1 line version might provide in rare
> cases isn't far outweighed by it being used irresponsibly.  

I agree that it might be hard to find an environment that favours
the 1-liner in this particular case, but I won't agree with a
blanket statement that it is always wrong.

> Besides I'm not convinced you can come up with a legitimate
> case where the 1 line version is of any real advantage.  I'm
> no compiler expert, but I'm pretty sure that compiler
> technology of the early 1970s would have produced the same
> code for the two cases.

Readability! And readability depens *a lot* on the context. Comments
that help my first-year students to understand a code construct will
only hinder 4y students, and comments that help hem might hinder me.
Certain (more or less obscure) C constructs are an easily recoginsed
'idom' in certain circles. If such an idom is more easily read by its
intended audience it might well be preferred over an alternate form that
is more readable by a wider audience.

Like I always try to remember my students: nearly all opinions are
context dependent. That's not bad, as long as you don't forget it!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\03\26@102911 by olin piclist

face picon face
wouter van ooijen wrote:
> I don't think we will ever agree on this :) but:
>
> What exactly was your opinion on assembly language?

The goals of assembly language and a high level language are very different.
I agree that the very flexibility that is essential to assembler also makes
it difficult to prohibit or discourage irresponsible programming.  Although
it's possible to make a mess in any language, and especially so if the
programmer has the attitude that he is using a high level language and that
therefore less care is required.  And of course you can write clear and well
constructed programs in assembler too.  Good programming discipline is
essential with all languages.

> I agree that it might be hard to find an environment that favours
> the 1-liner in this particular case, but I won't agree with a
> blanket statement that it is always wrong.

Maybe.  But I think the common downside versus the rare upside together with
good alternatives in the rare cases makes it advantageous to disallow it
altogether.

> Certain (more or less obscure) C constructs are an easily recoginsed
> 'idom' in certain circles.

Yes, but this is only because they are allowed in the language.  We are
talking about overall desirable language design, not how hard it would be
for existing programmers used to one language to convert to another.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\26@104602 by Peter P.

picon face
Olin Lathrop <olin_piclist <at> embedinc.com> writes:

> Let's see some.  I find it hard to believe that whatever minimal benefit the
> 1 line version might provide in rare cases isn't far outweighed by it being
> used irresponsibly.  Besides I'm not convinced you can come up with a
> legitimate case where the 1 line version is of any real advantage.  I'm no
> compiler expert, but I'm pretty sure that compiler technology of the early
> 1970s would have produced the same code for the two cases.

I think that the compound inline statement is hard to replace if written as the
condition of a loop, e.g.:

 while((i = getbyte()) > 0) {
   ...
 }

I also don't think that the ability of control statements to 'accept' compound
statements is a deliberate door opened for obfuscation. Rather, the C compiler
has a powerful and uniform expression interpreter that allows compounding on a
line and that the control statements simply use it, as everything else. The
system is symmetrical. C is not a teaching language, it was defined as a
portable macro set used to implement portable operating systems. I don't think
that compound statements are the hard part. Pointer 'magic' (not) and especially
pointers to functions are clear winners imho.

Peter P.


2007\03\26@104710 by William Chops Westfield

face picon face
>> Besides I'm not convinced you can come up with a legitimate
>> case where the 1 line version is of any real advantage.

I think I've always found the:
 while ( (c=getchar(file)) > 0) {
       /* do stuff with c */
 }
slightly clearer than the versions that separate the assignment
from the check...

BillW

2007\03\26@114414 by Constant, Colin (Innovatia) n/a

flavicon
face

A legacy indeed.  A friend of mine was once asked what would be the most
common programming languages in coming years.  His response:

I have no idea what they will be.  But they will be called Fortran and
Cobol.


-----Original Message-----
From: EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu [piclist-bouncesspamspam_OUTmit.edu] On Behalf
Of Jinx
Sent: Saturday, March 24, 2007 8:00 PM
To: pic microcontroller discussion list
Subject: [EE] Obituary - John Backus, FORTRAN team leader

http://en.wikipedia.org/wiki/John_Backus

2007\03\26@120954 by Herbert Graf

flavicon
face
On Mon, 2007-03-26 at 07:47 -0700, William Chops Westfield wrote:
> >> Besides I'm not convinced you can come up with a legitimate
> >> case where the 1 line version is of any real advantage.
>
> I think I've always found the:
>   while ( (c=getchar(file)) > 0) {
>        /* do stuff with c */
>   }
> slightly clearer than the versions that separate the assignment
> from the check...

Similarly when dealing with pointers, I fine the "one line" much more
understandable, i.e.:

if ((file_handle=fopen(stuff)) == NULL)
       printf ("File open failed!");
else
  /* do c stuff with file */

This is personal opinion though.

All I'll add, is despite how "dangerous" some people claim C is, it's
extremely wide spread use seems to indicate that the danger level is
acceptable.

Personally I much prefer C to any other language I've used, but that's
just my opinion.

TTYL

2007\03\26@123458 by William Chops Westfield

face picon face

On Mar 26, 2007, at 9:08 AM, Herbert Graf wrote:

>> I think I've always found the:
>>   while ( (c=getchar(file)) > 0) {
>>        /* do stuff with c */
>>   }
>> slightly clearer than the versions that separate the assignment
>> from the check...
>
> Similarly when dealing with pointers, I fine the "one line" much more
> understandable, i.e.:
>
> if ((file_handle=fopen(stuff)) == NULL)
>
Of course, these are really due to weaknesses in the usual
libraries.  Using a "special" return value to indicate an
error condition on a function that ought to be returning
a character or structure pointer is rather gross.  But the
use of NULL pointers for such cases is deeply entrenched in
the unix mindset, and really dangerous stuff like getchar()
is "historical"  (IIRC, we broke out getchar() equiv when we
went to a compiler that supported function prototypes.  I mean,
it returns a char, right?  (nope!  All sorts of 8bit and BREAK
support died real quick.))

  if (fopen(stuff, &myfile) != OK) then {
       /* open error */
  }
  while (!fileerror(myfile)) {
       c = getchar(myfile);
        :
  }

BillW

2007\03\26@132203 by olin piclist

face picon face
Herbert Graf wrote:
> if ((file_handle=fopen(stuff)) == NULL)
> printf ("File open failed!");
> else
>   /* do c stuff with file */

This and the getbyte() example others pointed out do seem to be a bit more
convenient when assignment statements also have values.  Still...

> All I'll add, is despite how "dangerous" some people claim C is, it's
> extremely wide spread use seems to indicate that the danger level is
> acceptable.

No, it only means it is widespread.  Things catch on for lots of reasons.
Technical merit is usually a minor one at best once you get to the "good
enough" level.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\03\26@140726 by Orin Eman

picon face
On 3/26/07, William Chops Westfield <@spam@westfwKILLspamspammac.com> wrote:
>
>    if (fopen(stuff, &myfile) != OK) then {
>         /* open error */
>    }
>    while (!fileerror(myfile)) {
>         c = getchar(myfile);
>          :
>    }

Does the above work for a zero length file?  At EOF?

Orin.

2007\03\26@145247 by William Chops Westfield

face picon face

On Mar 26, 2007, at 11:07 AM, Orin Eman wrote:

>>    while (!fileerror(myfile)) {
>>         c = getchar(myfile);
>>          :
>>    }
>
> Does the above work for a zero length file?  At EOF?
>
Your guess is as good as mine, since the example uses functions
that (AFAIK) have not actually been implemented.  This sort of
construct was standard for Pascal programs, though, so it should
be possible.  An error status doesn't get set for the file till
you actually try to read beyond the end of file.

> while not eof(File1) do
> begin
>       readln(File1,Score);
>  end;

(had to look that up.  Didn't remember what Pascal looked like.)

BillW

2007\03\26@194739 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>>> For example, strong type checking with specific syntax to disable it in
>>> those relatively unusual cases (even in operating system code) where
>>> you need it would not have defeated their goals and not made the
>>> resulting code less efficient.
>>
>> Maybe, maybe not.
>
> Oh, and how would it not?  Type checking is only done at compile time.  It
> should have no effect on the resulting code.

My response was to your "would not have defeated their goals".

>> I'm not sure I need to remind you of Python (created much later and has
>> quite a number of followers) and the duck-typing concept. No type
>> checking at all.
>
> I'm not familiar with Python, but this sounds like a very good reason not to
> bother.  I'm not sure what your point is about it having a large following.
> That only makes it successful, we are talking about good design.

What design is good depends a lot on personal preference. I know an
apparently pretty good designer (not personally, but anyway, somewhat :)
who threw out all type checking altogether and works in a language that
provides even more freedom to do nasty things than C. No type checking at
all, for example. That's his preferred language, and he thinks that's a
good choice.


>> Quick, efficient coding is /still/ a major goal, at least of
>> professional coders.
>
> Wrong!  Professionals know that maintainence is usally a much larger
> cost than initial coding, and that a little extra typing for clarity
> pays back many times over later, and often immediately.  If you follow
> your argument, you'd never type a single comment.

I don't think you have spent a great deal of reflection on what I could
have meant with "efficient". You probably have read enough from me to know
that I'm an ease of maintenance freak.

Later you wrote:

> The goals of assembly language and a high level language are very
> different. I agree that the very flexibility that is essential to
> assembler also makes it difficult to prohibit or discourage
> irresponsible programming.  Although it's possible to make a mess in any
> language, and especially so if the programmer has the attitude that he
> is using a high level language and that therefore less care is required.
>  And of course you can write clear and well constructed programs in
> assembler too.  Good programming discipline is essential with all
> languages.

I agree with most of this. The only thing we seem to differ is the first
phrase. There's no such thing as a clearly defined "high level language".
The "height" of a language is quite subjective, it's not an objective
criterion. The goal (in a professional environment) is almost always
efficient programming, and you choose your tool (the language) using a
number of considerations, of which the language structure is only one.

I wrote before that IMO C is more of a portable and structured assembler
than actually a HLL (and the history of why and how and with what goals C
was created supports this). But if you /really/ found rigorous type
checking important, you wouldn't program in assembler. So your argument
that C is bad because it doesn't provide rigorous type checking sounds just
a weeny bit phony -- assembler (your choice) provides even less type
checking.

You say assembler and C are in different classes -- I say they aren't. For
the tasks we do (I just assume I know enough about your projects to be able
to say this, but I know I may be wrong), you can find some good engineers
who would choose C and create good solutions, and you can find some good
engineers who would choose assembler and create good solutions. So they are
not in different classes; they are in the same class.

The solutions would be not far off in size or speed or efficiency,
generally. C is more portable, once you're above the IO port and
configuration register bit fiddling. C provides an assembler-like
flexibility to do pretty much everything you might need to do in a small OS
kernel, the flexibility that allows you to make your own choice between
efficiency and maintainability (in the rare cases where it's needed). Not
quite as much as assembler, but enough.

That's why C is not really a HLL. It was designed as an implementation
language for an OS, specifically to make porting it to different hardware
(and small hardware, by our current standards) easier. I think this design
goal has been achieved pretty well. It sure is not necessarily a good
choice for all the other cases where it has been chosen, but that doesn't
reflect on the language design, it reflects on the architecture and design
choices of these other applications.

Anyway, once you start putting away the categorizations (HLL, assembler,
etc) and look at the features (portability, maintainability, flexibility,
etc), you'll see that C is somewhat in between assemblers and HLLs,
providing a few HLL features with almost the flexibility and code/execution
time efficiency of assembler. It has (or had?) a rather unique place in the
language spectrum. It is not a language that teaches good coding; if you
want a language that teaches, use Pascal -- it was designed for teaching :)

What would be your choice of language if you had to write a multi-user OS
that should run on 15 different micros?

Gerhard

2007\03\26@205548 by Alexandre Guimar„es

face picon face
Hi,

> You say assembler and C are in different classes -- I say they aren't. For
> the tasks we do (I just assume I know enough about your projects to be
> able
> to say this, but I know I may be wrong), you can find some good engineers
> who would choose C and create good solutions, and you can find some good
> engineers who would choose assembler and create good solutions. So they
> are
> not in different classes; they are in the same class.

   You are forgetting one thing that is essential ! Assembler is not really
a "language" as it's own name imply, it is not a compiler neither a
interpreter. It is just a tool for easier writing of machine language
instructions. The choices there are more hardware than software choices,
specially in the 60's and 70's :-) It is like comparing apples and oranges !


Best regards,
Alexandre Guimaraes

2007\03\27@014937 by wouter van ooijen

face picon face
>     You are forgetting one thing that is essential !
> Assembler is not really
> a "language" as it's own name imply, it is not a compiler neither a
> interpreter. It is just a tool for easier writing of machine language
> instructions.

So are all compiled languages.

> The choices there are more hardware than
> software choices,

that's true for the instruction set, but only for that part! in all
other aspects an asm language designer is free, unless he/she wants to
resemble existing asmmeblers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\03\27@040938 by Alan B. Pearce

face picon face
>Similarly when dealing with pointers, I fine the "one line"
>much more understandable, i.e.:
>
>if ((file_handle=fopen(stuff)) == NULL)
>printf ("File open failed!");
>else
>   /* do c stuff with file */
>
>This is personal opinion though.
>
>All I'll add, is despite how "dangerous" some people claim C
>is, it's extremely wide spread use seems to indicate that the
>danger level is acceptable.

I suspect there are two things here about figuring that the danger level is
"acceptable"

1. Any good C programmer will recognise the dangers of the construct

2. Many C programmers would run the program by one of the many versions of
Lint to make sure they don't have any stupid typos that they have missed
(like a single = before the NULL).

2007\03\27@061647 by Ruben JŲnsson

flavicon
face
If instead done like:

if (NULL == (file_handle=fopen(stuff))) ...

the single = error would automatically be checked at compile time. Of course,
this only works if one of the comparees is a constant.

/Ruben

{Quote hidden}

> -

2007\03\27@090741 by Gerhard Fiedler

picon face
Alexandre Guimarães wrote:

>> You say assembler and C are in different classes -- I say they aren't.
>> For the tasks we do (I just assume I know enough about your projects to
>> be able to say this, but I know I may be wrong), you can find some good
>> engineers who would choose C and create good solutions, and you can
>> find some good engineers who would choose assembler and create good
>> solutions. So they are not in different classes; they are in the same
>> class.
>
> You are forgetting one thing that is essential ! Assembler is not really
> a "language" as it's own name imply,

"Assembler" is often used as a shortcut for "assembly language" -- so what
does this name imply? :)

Wikipedia, for example, definitely classifies the various assembly
languages as programming languages
<http://en.wikipedia.org/wiki/Assembly_language>


> it is not a compiler neither a interpreter. It is just a tool for easier
> writing of machine language instructions.

Doesn't this go for pretty much all tools that in the end create machine
language? Maybe it's time for looking a bit at the involved terms:

Machine language: Usually represented in Intel hex format or binary. The
language that actually runs on the target hardware. Not less of a
programming language: it provides structural elements, assignment, math and
logic operations, just like the other programming languages we're talking
about here. It is traditionally implemented partly in hardware and partly
in microcode, but it may be implemented completely in software (VHDL, for
example). Just because it's usually not implemented in a tool that you can
run on your PC doesn't make it less of a language. (But it may be
implemented in a tool that you can run on your PC: simulators are such
tools that implement machine language on a PC. Sometimes they can even be
used to make the PC do things: in the cases where the simulator provides
direct access to the PC hardware, like serial ports etc.) Machine language
is by definition the lowest level language that's accessible on a system.
Some (but not all) higher level languages generate machine language output.

Assembly language: Designed to be (within limits :) readable by humans. The
core of it is usually a mnemonic representation of the machine language.
But there's more to it; macros and relocatable code generation/linker are
probably the most prominent features that go beyond a representation of
machine language. There may be multiple assembly languages for one machine
language (e.g. for the 14-bit PIC machine language there's at least MPLAB
assembler and Hi-Tech assembler; I think there used to be a Parallax
assembler, and there may be others.). A program written for one in general
can't be translated by the other, which I take as a clear indication that
there's a difference between the machine language (implemented by the
target hardware) and the assembly language (implemented by a tool). Some
higher level languages generate assembly language output.

Higher level languages: In general may be compiled or interpreted. Let's
just consider the compiled ones; they usually generate either machine
language output or assembly language output (for a certain assembler).


I'd say for a typical program, it's probably just as much work to manually
translate from C to assembly as it is to translate from assembly to machine
language. I agree that there is more (maybe much more) complexity in the
first task, but that's not the point. I wasn't talking about the of the
tools and their complexity, I was talking about the languages.


> The choices there are more hardware than software choices,

Not necessarily, but even if it were so, so what? Who says that a
programming language has to be implemented in software?

> It is like comparing apples and oranges !

I can't do much with this analogy; it doesn't seem to tell much -- both are
fruit :)  What characteristics of assembler or C are analog to what
characteristics of apples and oranges?

Gerhard

2007\03\27@153416 by John Ferrell

face picon face
Is this function "fileerror(myfile)" part of the standard library of this
compiler or is it a function in the scope of this program? I think it
depends on the compiler.

Most c zealots would rather write it something like
while (c = getchar(myfile););

the syntax is probably in error but the gist is that as long as the standard
function "getchar()" returns a true the while continues to execute.

I cannot seem to get the knack of thinking in that manner so I am at a loss
to read another programmer's code.

C is OK with me if you follow Pascal Formatting!

John Ferrell    W8CCW
"Life is easier if you learn to plow
      around the stumps"
http://DixieNC.US

{Original Message removed}

2007\03\29@030011 by Apptech

face
flavicon
face
> Now if you want to complain about C I won't argue.  The state of compiler
> development and the experience with how humans make coding mistakes and
how
> a compiler can help was far enough along that many design decisions in C
> were irresponsible in my opinion, even when judged against the information
> available at the time.

Yes and no.
C was, and is, a  4 edged sword - two on the blade and two on the
'handgrip'. Handled by a suitable skilled master (for whom it's useful also
to be adept with double ended light sabre) it is second equal* to assembler
for its power and usefulness. With the power comes all sharp edges and great
danger. The 'problem' with C is as much that people who should know better
allow people who don't know enough to use it to use it :-). The same goes
for assembler, but it is so sharp edged that most people who can't use it at
all don't try and it often enough (but not always) becomes evident in time**
that the half incompetent are half incompetent.

One 'advantage' of C is that it sometimes allows you to do things that any
hald respecting assmbly language compiler won't let you do ;-).


       Russell

* I don't know all the languages that what it's second equal WITH but there
are a few other candidates. eg PL1 ? :-).

** 'In time' has (at least) two meanings. Both apply here.


2007\03\29@032859 by wouter van ooijen

face picon face
> * I don't know all the languages that what it's second equal
> WITH but there are a few other candidates. eg PL1 ? :-).

BCPL, CPL, Midial, CHILL. The name for this class of languages (among
which C ranks quite 'high') is MOHLLs: Machine-Oriented High Level
Languages. PL/1 and Ada are a step above this, combining MOHLL with
'normal' HLL features.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\03\29@035231 by William Chops Westfield

face picon face

>> Assembler is not really a "language" as it's own name imply

This is quite true, since there is a separate "assembly language"
for each CPU (sometimes more than one for each CPU.)  While there
is frequently enough similarity that one might count oneself as
knowing "assembly language" in general, it's not infrequent to come
across some aspect of a particular assembly language that is at
least a bit disorienting.  Banking on a PIC.  Strong typing on
an x86.  Three operands on some RISC cpus.  Single character opcode
names on a Cray.  Harvard vs Von Neuman vs executable registers.

Saying "I know assembly language" is a bit like saying "I know
high level language."   That'll be accurate to a greater or
lesser degree, but it covers a lot of ground (as in "any C programmer
can probably write a C++ or a Java program, but it'll probably look
like a C program"  :-)

BillW



2007\03\29@051306 by Apptech

face
flavicon
face
> >> Assembler is not really a "language" as it's own name imply

> This is quite true,

No. Not true at all :-).
Lack of generality doesn't make a language not a language - it just smakes
it a specialist one.
The thing which makes it very very sharp is what also makes it less
portable, and vice versa.
HLL's are to a variable extent machine dependent and the H'er the L the less
so. To achieve this the differences may need to be accomodated inside the
language where the user camn't see them than outside where the user can
twiddle the knobs. Assembler is the ultimate HLL, but all the exceptions are
carried in the user's brain rather than in the compiler writer's brain.

The ultimatenon-language is acually "above" assembler in position 0 - ie han
writing machine code - try it, you won't like it :-).
Long long long ago I spent a happy few years doing just that, as no
assembler (let alone compiler) was usefully available at an accessible
price. An interesting grounding in microprocessors was thereby provided, but
it's not something I'd ever care to do again. Fortunately the processor
used, the Motorola 6800, was *FAR* more amenable to this treatment as it
grouped bits in related fields adjacently rather than sprinkling them all
over the command word as some do, and it had a reasonably well ordered
instruction set. Doing the same thing with most other microprocessors would
be substantially harder. As it is I could probably still write some 6800
code from memory :-).


       Russell





2007\03\29@081000 by Gerhard Fiedler

picon face
Apptech wrote:

> The 'problem' with C is as much that people who should know better allow
> people who don't know enough to use it to use it :-). The same goes for
> assembler, but it is so sharp edged that most people who can't use it at
> all don't try and it often enough (but not always) becomes evident in
> time** that the half incompetent are half incompetent.

I don't know if this is true... I think in terms of proportion (to the
overall amounts of code I've seen), I've seen as much badly written
assembly as I've seen badly written C. Whoever has -- out of usually
strange reasons -- taken over a job that included work on someone else's
assembly code knows what I mean :)

There's nothing inherent in being able to write assembly that makes a
person a good programmer. It needs more understanding of the processor, but
that's not related to good programming. And I think it's easier to find
good literature about how to write well-written C than it is to find
material about how to write well-written PIC assembly. (Even though most
principles are the same, the examples will be easier to find in C than in
PIC assembly.)

> One 'advantage' of C is that it sometimes allows you to do things that
> any hald respecting assmbly language compiler won't let you do ;-).

I saw the ;-), but didn't understand it nevertheless :)  Care to explain,
maybe with an example?

Gerhard

2007\03\29@105046 by Timothy Weber

face picon face
Russell wrote (under the alias 'Apptech'):
> C was, and is, a  4 edged sword - two on the blade and two on the
> 'handgrip'. Handled by a suitable skilled master (for whom it's useful also
> to be adept with double ended light sabre) it is second equal* to assembler
> for its power and usefulness. With the power comes all sharp edges and great
> danger. The 'problem' with C is as much that people who should know better
> allow people who don't know enough to use it to use it :-). The same goes
> for assembler, but it is so sharp edged that most people who can't use it at
> all don't try and it often enough (but not always) becomes evident in time**
> that the half incompetent are half incompetent.

I'd just like to point out that Russell commands the most humorous
sentence structure in the history of the English language.
--
Timothy J. Weber
http://timothyweber.org

2007\03\29@134142 by James Newtons Massmind

face picon face
> > use it :-). The same goes for assembler, but it is so sharp
> edged that
> > most people who can't use it at all don't try and it often
> enough (but
> > not always) becomes evident in time** that the half
> incompetent are half incompetent.
>
> I'd just like to point out that Russell commands the most
> humorous sentence structure in the history of the English language.

You should hear him speak. He talks so fast that after the third sentence,
you are just parsing the first. All my conversations when he was visiting
included long pauses after he finished speaking while my poor mind caught
up. Most of the time, when I started talking, it was to respond to a point
he made three points ago.

Say what you will, the man is a genius. If not in the quality of thought,
then in the prodigious quantity of it and the speed with which he puts it
out. Anyone who can think, speak, and process that fast is going to
eventually pull ahead of the rest of us.

People complain about the volume and range of Russell's posts, but I am here
to tell you, that is most likely a small fraction of his daily output.

Has anyone seen "Over the Hedge"?

---
James.


2007\03\29@144337 by Timothy Weber

face picon face
James Newtons Massmind wrote:
>> I'd just like to point out that Russell commands the most
>> humorous sentence structure in the history of the English language.
>
> You should hear him speak.

It is now on my list of life goals.
--
Timothy J. Weber
http://timothyweber.org

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...