[ale] MadDog and FORTRAN (wuz: Happy Birthday BASIC)
Leam Hall
leamhall at gmail.com
Sun May 19 21:27:24 EDT 2024
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)
More information about the Ale
mailing list