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

Jon "maddog" Hall jon.maddog.hall at gmail.com
Sun May 19 22:55:57 EDT 2024


Thanks for the clarifications.

md

On Sun, May 19, 2024, 21:27 Leam Hall via Ale <ale at ale.org> wrote:

> My apologies for the lack of clarity. My hope was to convey two main
> points:
>
> 1. Having to cover that many topics in a 8 week class would definitely
> cause many of us to struggle, no matter what the topic.
> 2. Time to develop and time to run are factors in choosing a language. I
> find portability another.
>
> Leam
>
> On 5/19/24 17:08, Jon "maddog" Hall wrote:
> > 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
> >>
> >
>
> --
> 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/616bf53f/attachment.htm>


More information about the Ale mailing list