[ale] MadDog and FORTRAN (wuz: Happy Birthday BASIC)

Jon "maddog" Hall jon.maddog.hall at gmail.com
Sun May 19 18:08:25 EDT 2024 

Leam,

I had a bit of a hard time following everything you said, but I will do my
best to answer:

>FORTRAN and the struggling....

I learned FORTRAN II using punched cards, and taught FORTRAN IV in the
years 1977 to 1980.   Our school had a FORTRAN IV compiler on a PDP-11/70
running RSTS/E.   FORTRAN 77 was out at that time, but we did not have the
budget to buy a compiler from DEC.   I remember giving my students the task
of writing a pre-compiler in FORTRAN IV to convert FORTRAN 77 statements
into FORTRAN IV, and the pre-compiler had to be written in FORTRAN IV.

FORTRAN IV only had arithmetic IF and no string manipulation statements, so
you can imagine how hard this was to do.   I think two out of 20 students
actually got something close to working.

>"Blazingly fast"

Yes, there are many ways to implement an interpreter and many job loads.
The example given was on an HPC system where number crunching rules, and
you probably spend 50-60% of your real time on user-written code.   But in
many applications today you spend a significant amount of your time in code
written by someone else (graphic code, database code, system library code,
etc) so from a speed of execution of the total program standpoint the speed
of the language's code in execution is small.



Of course since then there was Fortran 90 (I think that was when the name
became mixed case) High Performance Fortran (HPF) and  some other issues of
Fortran....

As to portability, that is a problem in many languages that are implemented
by different vendors with relative levels of success.   DEC spent a lot of
time and money on their compiler suites, and we spent a lot of time on
standards bodies.   We even spent a LOT of time making VAX "C" compatible
not only with AT&T "C" but with gcc.   The goal was to try and re-compile
the entire X Window System Server with VAX "C", hopefully seeing a large
increase in speed due to our optimizers.

But we did not see that increase in speed, because the people who wrote the
X Window System Server knew the gcc compiler so well they wrote their code
to be very optimized in the first place.

On the other hand, Boeing standardized on gcc across all their vendor's
systems (and hired Cynus to support them) because the gcc compilers had
*exactly* the same syntax and semantics across all those systems.  This, of
course, reduced the number of ifdefs and testing threads they had to have
across their many systems  from many vendors.

>In those environments, the OS came with C compilers and that would have
been our choice if shell or whatever version of Perl or Python didn't do
what we >needed.

Some OS came with the compilers, and some did not.   In the early days of
Unix you HAD to have the "C" compilers because you HAD to compile the
kernel as you were installing the system (on servers that did not have
pre-installed systems, anyway).   First you booted the tape drive to pull a
small kernel into memory, just enough to recognize the (hardcopy, serial)
console, memory, CPU, tape drive and one disk.  Then you edited the
configuration file to type in the devices, addresses of the devices,
interrupt addresses (are readers remembering this?) and you then ran the
configuration program to create the module that could be compiled and
linked into the kernel.   Then you would place that kernel on the disk and
boot it.

BUT AS SOON AS WE GOT THE KERNEL OF THE DISTRIBUTION TO PROBE THE DEVICES
SO WE DID NOT HAVE TO COMPILE THE KERNEL we moved the compilers off the
system and created a second product to sell to customers.  Oh well.  It was
not just DEC.  Sun did it too.

Personally I use only GNU compilers.   They do everything I want them to
do, with the efficiency I need.   If I want the solution to go any faster I
either look for a better algorithm, or buy a faster CPU (GPU, FPGA, etc.)

Peace be with you all.

md


On Sun, May 19, 2024 at 11:40 AM Leam Hall via Ale <ale at ale.org> wrote:

> My opinion, based solely on what you wrote below, is that "struggle" would
> be an understatement. That they could do anything in FORTRAN seems like a
> win to me. In the early '90's I took a Pascal class from a teacher who had
> taught it for a while, and I could still only do simple stuff.
>
> The "compiled vs interpreted" question has another aspect: portability.
> I'm more of a tool builder than an application developer, I'd rather give
> someone the code so they can do whatever they need to be doing. Python is
> blazingly fast enough for everything I've done, but it is less and less
> portable.
>
> A lot of coders assume you can "pip install X" or use whatever the latest
> version is of Python, and that's not the case for a lot of us. A quick
> count of my career shows seven of forty-two years *not* spent in a
> restricted environment; all we got was whatever came with the OS. Those are
> almost always outdated even when the OS is brand new, and not everything on
> PyPI is available. In those environments, the OS came with C compilers and
> that would have been our choice if shell or whatever version of Perl or
> Python didn't do what we needed.
>
>
> Leam
>
>
>
> On 5/17/24 12:02, jon.maddog.hall--- via Ale wrote:
> > So you seem to have completely ignored my statement about the issue of
> development vs running where I specifically pointed out that in an
> educational environment you compile many more times than you run.
> >
> > in 1977 I had the task of taking students who had never seen a computer
> in real life, never logged into an account, never used a text editor of any
> type and try to teach them FORTRAN in a eight-week summer-school course of
> three hours of lecture each week.
> >
> > I asked the administration of the school if anyone had ever taught this
> before in this time frame and was told "Oh yes".
> >
> > In was a time-sharing system (RSTS/E on a PDP-11/70), so I had to teach
> them what "logging in" was, what a file was, what data was, what a
> text-editor did (and how to use the commands), what compiling did, what
> linking did, how to use an interactive debugger, then programming itself
> and the FORTRAN language itself.
> >
> > None of the students had access to computers at home, and there were not
> many people who could help them at home.   No online forums for help.
> >
> > They struggled.  I struggled.  And after eight weeks they were barely
> getting started with very, very simple FORTRAN programs.
> >
> > On the other hand I often taught a ten-week course in FORTRAN to
> students who already had BASIC as part of a entry-level course called
> "Introduction to Data Processing".  The students of that course thrived due
> to a much greater familiarity to everything other than the
> edit/compile/link/run/debug process (and even editing and debugging were
> easier because the concept of that was already known).
> >
> > BASIC allowed simple editing just by retyping the line number with the
> statement.   It allowed interactive "debugging" by being able to print out
> the variables using the source code variable name, or setting the variable
> to a different value before telling the interpreter to "continue".   in
> RSTS/E you were talking to the BASIC interpreter as soon as you logged in.
> The BASIC interpreter was much like the shell interpreter in UNIX/Linux
> today.
> >
> > The student could type in:
> >
> > Print 5*3
> >
> > then hit return and the machine would print:
> >
> > 15
> >
> > No editor, no compiler, no linker...
> >
> > To be complete I know of no reason why FORTRAN could not be implemented
> in an interpreted fashion and after a program's source code is fully
> debugged sent through a "real" compiler to get a smaller, perhaps faster
> object.   Once the program has been debugged you do not need the
> interactive debugger part of the program in memory.
> >
> > And of course a more modern, fully functioning IDE could make the
> compile/link/execute/debug path significantly easier these days.  And of
> course students today have used computers in so many ways through their
> phones, etc. that many of the concepts which I took up time in class the
> students already know.
> >
> > Finally, I will say that when I finished the eight-week summer course in
> FORTRAN to what I felt were disastrous results I went back to the
> administration and questioned again if that course had ever been taught
> successfully before.
> >
> > The answer was "no".....they had lied before.
> >
> > /*But when the eventually approved and compiled code will be run every
> hour or so for the next 3-5 years, and that code requires MPI
> interconnection to 100-800 other nodes to run on every hour, devel/compile
> time starts looking to be less of a problem.
> > Pretty sure the heat generated to predict the weather has small but
> non-zero impact on the weather :-)*/
> >
> > Quite frankly for this type of problem I might look at GPU or FPGA
> accelerators just like years ago we invented floating point accelerators
> instead of doing floating point using integer only CPUs.
> >
> > Depending on the type of problem, a language like Erlang or Haskell
> would probably help with such a distributed problem
> >
> > md
> >
> >
> >> On 05/17/2024 11:19 AM EDT Jim Kinney via Ale <ale at ale.org> wrote:
> >>
> >>
> >> The backend compile process is horrifyingly slow. But when the
> eventually approved and compiled code will be run every hour or so for the
> next 3-5 years, and that code requires MPI interconnection to 100-800 other
> nodes to run on every hour, devel/compile time starts looking to be less of
> a problem.
> >>
> >> Pretty sure the heat generated to predict the weather has small but
> non-zero impact on the weather :-)
> >>
> >> On Fri, May 17, 2024, 6:04 AM Jon "maddog" Hall <
> jon.maddog.hall at gmail.com mailto:jon.maddog.hall at gmail.com> wrote:
> >>
> >>> It all depends on the implementation, but some interpretive languages
> are fairly fast at execution.  The interpreter takes the source down to
> atoms (or "beans" if you go that way) and then feeds them to a very
> optimized run-time system.
> >>>
> >>> Interpretive vs compiled also needs to be looked at the ratio of run
> time vs development.  In a learning situation you may only run a program
> once for every time you compile it.  An interpretive language is much
> "faster" (and less of a resource hog) than running an
> edit/compile/link/execute cycle.
> >>>
> >>> md
> >>>
> >>> On Thu, May 16, 2024, 21:36 Jim Kinney via Ale <ale at ale.org mailto:
> ale at ale.org> wrote:
> >>>
> >>>> Compiled code. Still do FORTRAN when it has to be fast. Still do C if
> I need to burn up a monitor (oops!). But you can't learn it if you can't
> see it, touch it, and change it. The scripting languages are easier to
> learn and definitely have a place. And they are now the gateway to
> programming. They're not perfect and they slurp down hardware. I can't
> imagine python trying to run in the days of BASIC on an early  pc jr.  :-)
> >>>>
> >>>> On Thu, May 16, 2024, 8:33 PM jon.maddog.hall--- via Ale <ale at ale.org
> mailto:ale at ale.org> wrote:
> >>>>
> >>>>> Chuck,
> >>>>>
> >>>>> Many people did not recognize the benefit of pulling down the source
> code and typing it in by hand.
> >>>>>
> >>>>> "Wow!  What does that error mean?   I typed it in just
> like....oh...I made a mistake!"
> >>>>>
> >>>>> You had a syntax error, and BASIC showed it right away (most of the
> time anyway).
> >>>>>
> >>>>> But maybe your syntax was correct and your program still did not
> work.  Maybe the error was that you meant to type "2" and you typed "3' by
> mistake....a "run-time error".
> >>>>>
> >>>>> You do not get to create or fix these problems if all you do is pull
> binaries off the web or load them from a CDROM.
> >>>>>
> >>>>> This was EXACTLY why the professors at Cambridge University started
> the Raspberry Pi project.   They realized that the freshmen of today often
> knew less about computers than the freshmen of 20 years ago...the ones who
> 20 years ago downloaded source code and (in some cases) even had to COMPILE
> it and LINK it in order to run it.
> >>>>>
> >>>>> Happy Birthday, BASIC!
> >>>>>
> >>>>> md
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 05/08/2024 8:10 AM EDT Chuck Payne via Ale <ale at ale.org mailto:
> ale at ale.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>> I am surprised that this one didn't get an email. Happy Birthday
> BASIC, it turned 60. It only three years older than me, and has more
> functions than me too.
> >>>>>>
> >>>>>>
> https://www.tomshardware.com/software/programming/the-basic-programming-language-turns-60-dartmouth-basic-started-it-all-in-1964
> >>>>>>
> >>>>>> As a kid, I got into BASIC because it was the way to get games. I
> forgot the name of the magazine, but I would buy it every month and sit at
> my VIC 20, trying the code in, playing such games and Oil, where you drill
> to get oil hoping to hit a pocket with a devil in it. Or trying to
> understand what the data fields were doing.
> >>>>>>
> >>>>>> Since I missed the 4th as well, here some BASIC Code for you guys
> >>>>>>
> >>>>>> https://www.goto10retro.com/p/star-wars-theme-in-basic
> >>>>>>
> >>>>>> Yes, I was one of those kids that would type some weird messages on
> the computers tha would repeat, like
> >>>>>>
> >>>>>> 10 print "Long live ALE, bring more beer"
> >>>>>> 20 goto 10
> >>>>>>
> >>>>>> Happy Computing guys
> >>>>>>
> >>>>>> --
> >>>>>> Terror PUP a.k.a
> >>>>>> Chuck "PUP" Payne
> >>>>>> -----------------------------------------
> >>>>>> Discover it! Enjoy it! Share it! openSUSE Linux.
> >>>>>> -----------------------------------------
> >>>>>> openSUSE -- Terrorpup
> >>>>>> openSUSE Ambassador/openSUSE Member
> >>>>>> skype,twiiter,identica,friendfeed -- terrorpup
> >>>>>> freenode(irc) --terrorpup/lupinstein
> >>>>>> Register Linux Userid: 155363
> >>>>>>
> >>>>>> openSUSE Community Member since 2008.
> >>>>>> _______________________________________________
> >>>>>> Ale mailing list
> >>>>>> Ale at ale.org mailto:Ale at ale.org
> >>>>>> https://mail.ale.org/mailman/listinfo/ale
> >>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
> >>>>>> http://mail.ale.org/mailman/listinfo
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Ale mailing list
> >>>>> Ale at ale.org mailto:Ale at ale.org
> >>>>> https://mail.ale.org/mailman/listinfo/ale
> >>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
> >>>>> http://mail.ale.org/mailman/listinfo
> >>>>>
> >>>> _______________________________________________
> >>>> Ale mailing list
> >>>> Ale at ale.org mailto:Ale at ale.org
> >>>> https://mail.ale.org/mailman/listinfo/ale
> >>>> See JOBS, ANNOUNCE and SCHOOLS lists at
> >>>> http://mail.ale.org/mailman/listinfo
> >>>>
> >>>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> https://mail.ale.org/mailman/listinfo/ale
> >> See JOBS, ANNOUNCE and SCHOOLS lists at
> >> http://mail.ale.org/mailman/listinfo
> >>
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > https://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
>
> --
> DevSecOps Engineer         (reuel.net/resume)
> Scribe: The Domici War     (domiciwar.net)
> General Ne'er-do-well      (github.com/LeamHall)
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20240519/68bab339/attachment.htm>

More information about the Ale mailing list