Thanks for that "word to the wise"...
Thanks for that "word to the wise"...
Thanks for that "word to the wise"...
-------------------------------
Digression, but - I used Quick Basic for my first attempts at programming back in 1996 - so 30 years ago. I could have used the "built-in" BASIC within "MSWindows" then for what I was doing, but well - whatever. I got a first result showing my algorithm did work as a computational solution. I realised things got really serious if you were to make the solution
3-Dimensional - one "serious" being that a 3-Dimensional takes the cube of the amount of memory for my first 1-Dimensional solution (there were almost no 3-Dimensional solutions around then 30 years ago (?)).I was pitched into supercomputing at that juncture. My world became "unix" ("Linux"), programmed in "C". Within a very few months the academics in the Department of Mathematics and Computer Science where talking with some amazement at each other as they absorbed what I had discovered or deduced myself - which they considered what only an expert could comprehend. Another "conversation" was a young lady who was a post-doctoral researcher, who paused for a long time after looking through my code - then picked-up on the "pointers" I had used - per possibilities I had read-of in the couple of books I had on programming in "C" (including Kernighan and Ritchie's "the" book). Where it turns out I had done about the same as a trainee pilot who had learned about the necessity of flying low, and the necessity of flying fast, and had just returned from a first solo training flight in less than half the time it was supposed to take, with a thin haze of smoke coming off the aircraft and leaves and twigs jammed in bits of the aeroplane, where they were deducing that the pupil on an early solo flight had just flown at Mach 2 at treetop height (which would if so leave them handling "PR" issues like windows broken by the supersonic boom at just over head height, cows needing psychotherapy, etc.). Happy days... :-)
I used Quick basic a little earlier than that. I was struggling with Algebra with irrational solutions in college, so I wrote some program to calculate graphs and data points to help me get close. It was so fast I had to add a time delay for visual affect before I showed it to my Algebra professor. Brilliant guy. From that he learned QB and started using it for generating fern graphics. (a fractal set) I showed him how much faster C+ was and he rewrote it in C+ and started writing his own graphic libraries to go with it, because he didn't get all the libraries with his copy of C+. I never really figured out how to write the answer as a complete expression, but I learned how to calculate it close enough to a gazillion decimal places.
A little after (or maybe it was before, well around that time) my Geology professor was showing off his basic interpretor executing a groundwater saturation study he was working on and proud of how much faster the new 386 he had for his department was executing the program than the older XTs or even the 286. He was really proud of the fact that it only took a few days to run. I showed him how to use an editor to semi automatically convert it into Quick basic compatible code and compile. The next model ran in a couple hours.
One of my part time jobs back then was working as a lab tech in the computer lab. Mostly just supervising, but I did spend a fair amount of time teaching other people how to code or how to be power users.
Where it turns out I had done about the same as a trainee pilot who had learned about the necessity of flying low, and the necessity of flying fast, and had just returned from a first solo training flight in less than half the time it was supposed to take, with a thin haze of smoke coming off the aircraft and leaves and twigs jammed in bits of the aeroplane, where they were deducing that the pupil on an early solo flight had just flown at Mach 2 at treetop height (which would if so leave them handling "PR" issues like windows broken by the supersonic boom at just over head height, cows needing psychotherapy, etc.). Happy days... :-)
--------------------------------- The reward may be like mine, doing engineer work for technician pay.
Yeager wrote about flying low enough to leave propeller tip marks in a dirt road as a cadet. Pacific ace Richard Bong got in trouble for flying through San Francisco at second (your first) floor level. A mast height B-25 bomber skipping bombs across the waves into the side of a ship near New Guinea returned with part of the ship's log book stuck in the radial engine. A B-17 flying low enough for the belly turret gunner to shoot into a beach bunker sanded the paint off the tail on pullout. A B-24 on sea patrol near Indonesia relieved the boredom by flying between rows of Japanese barracks with waist guns blazing. The Fifth Air Force in New Guinea perfected attacking with medium bombers, locally stuffed with up to a dozen extra .50 machine guns, flying at coconut tree top height to approach and surprise radar-less Japanese air bases. Once the bullet spray had chased the defenders into trenches they dropped parachute-retarded frag bombs that shredded planes and supplies which couldn't be buried in the wet ground of the only level areas.
I got all of that stupid cadet stuff out of my system in a simulator. I don't have the reflexes to fly low down the Grand Canyon or through New York or Chicago.
Speed of computation - he went from interpreted BASIC to compiled binaries from "QuickBASIC"?
They warn these days that an interpreter running the sparse "script" can often far better use the computer's hardware that a "clunky" compiled program in eg. "C".
There is thought that programs like "C" now only belong down in the operating system or when writing the core of interpreters? Linus Torvalds of the Linux project says that to this day he delights in "polishing" code to get optimised fastest run-times for core components of the operating system.
This nearly three decades ago I realised anything done once like the "set-up" where the program "comes-alive" - "just" make the program obvious to follow and forget about run-speed because you do it once. But when you get into the "working tips" of the program where pieces of resultant code will be used million(s) of times a second - do optimise the code for run-speed. In those parts of the code I made code with no branching decisions, etc., and made separate "nuggets" of code which were mostly identical but hard-encoded different circumstances. [in my code it was different geometric positions / situations] The compiler's "optimiser" broke at far below the final size of the program, so I was very glad I wrote it to be "fast as written" - as I had to set the compiler's optimiser option to zero - don't try to optimise at all - write binary code exactly as expressed in the program. That was one of the "amazement" things - that I had come to this level of perception.
When I was writing an I2C driver in QB I needed to time the data and clock bit durations and had an attached oscilloscope to measure them. A compiled integer FOR NEXT loop used two clock cycles per pass, 500MHz (2nS) on a 1GHz CPU. The To count was a variable I could change. One I/O write to LPT was hardware limited to around 1 microsecond, varying between computers. The few other instructions I looked at ran impressively fast.
The servo loop to set the count started long and reported how many RTC clock ticks had passed, then made a slightly low correction and repeated up or down until the I2C bit rate was acceptably close to 100Kbps, or at least I could detect a failed connection. My timing scheme needed patching as CPU speeds rapidly rose and fell apart when SpeedStep was introduced.
They make those arguments when using a mid level programming language to write code for an operating system written in a mid level programming language. You are functionally running through two levels of the same libraries of included functions. I don't know if its still true, but Windows used to mostly be written in C, so using C meant there were included libraries at multiple levels if you write to run compatibly under windows. I don't know if its truly even valid, but I can see it as a case for making the argument. I haven't written any real code in over 20 years, so I would have to test it. It also of course depends on how the code was written.
Computers are so fast now by comparison it probably doesn't matter which is faster.
I can literally render multiple machine operations and complex CAD image simultaneously on my desktop PC, and its not even the fastest computer I own.
As somebody who wrote, basic, C+, QuickBasic, Cobol, and assembler. Compiled code was always faster then interpreted code back then. Of all of those assembler created the fastest executable and CHASM (cheap assembler) wrote the fastest executable of assemblers I used. When I was learning to write assembler I found machine function calls were much faster than OS (DOS) function calls, but not all BIOS were created equal. Sometimes you would make a bios function call and it would trash all the registers. For class work on a deadline I would then switch to using the DOS calls because generally they used a different method to preserve working parameters. For fast personal code I would PUSH the register values on the stack, and then POP them back after the function. It was still faster than using the DOS function calls, but error checking everything took longer to code.
I don't recall which BIOS' or revisions anymore, but I documented more than a couple issues like that with different supposedly cross compatible BIOS.
So the true answer I suspect is, "it depends." In this age when an operating system source code is a hundred million lines and documenting it all across dozens of ever changing programmers it may just be "easiest" to trust the OS to handle everything, unless your program wrests total control of the machine.
As somebody who wrote, basic, C+, QuickBasic, Cobol, and assembler. Compiled code was always faster then interpreted code back then. Of all of those assembler created the fastest executable and CHASM (cheap assembler) wrote the fastest executable of assemblers I used.
--------------------------------------------
I began at the bottom and clawed my way up.
After completing an 8080 training module the company awarded me a CPU, which I used to design and wire-wrap a computer with engineering sample memory chips and data and address entry switches. They entered a bootstrap loader that could read a boot program on Teletype tape, top down so the last write jumped to executing it. I found and added an octal keyboard which sped up programming hand-assembled code considerably. The 8080 instruction makes sense in octal, each digit specifies an accumulator register. At the time Radio Shack carried Intel and Motorola processors and peripheral chips.
I coded a simple operating system that could write to and read from first the Teletype, then a modem I designed and a cassette recorder. The first serious app was a text editor, then an assembler/disassembler function within it that documented the code I had hand-written to a printed text file.
By then the 8080's lack of relative jumps was becoming a hindrance, applications all had to run the the space they were written for. I had acquired enough hardware and software experience to set it aside for night school that helped me take up testing, engineering and Pascal programming on an LSI-11 project.
Rest clipped, I need to stop blabbing and hammer sheet metal for the car.
I resemble that remark.
I should add when I was taking most of my programming classes at home I had a Tandy1400HD (V20 processor) laptop, a generic XT with an 8088 processor, and an early AT with a 286 processor. I would typically write on the AT, and test my code on all three machines. I did not have a color monitor at the time, but I did have a Hercules color card in the XT, and a very simple VGA card in the AT (maybe that was later I forget). In order to keep track of things on screen I would pick random color codes for particular types of information or menu items, so the brightness would be different on the CRT.
The Tandy had some quirk of its architecture so it would address a little more ram than just 640 like a regular XT.
One of my instructors started testing student programs on a 386, that had an actual honest to goodness color monitor and he was impressed with how I made order of everything on screen by color. I had completely forgotten about using the color codes by then. Fortunately I picked colors at random that didn't look to terrible.
My first programs were written on a Commodore Pet 2001 with a tape drive. Then I started writing basic on a HeathKit H89A with a Z80 processor if I recall. My dad built it from a kit. The most complex program I remember writing back then was a strictly text based version of Mastermind using numbers instead of colors. I was in the process of writing a similar style blackjack game program when we took a massive voltage surge, the surge suppressor behind the air hockey table we were using as a computer blew up and flames shot 3-4 feet up the wall. Sadly the Heathkit didn't survive. I guess when you hit a surge suppressor so hard it explodes it doesn't stop the voltage spike. It was a power company mistake in the field. They paid for a lot of refrigerator motors from what I heard, although ours didn't die from it.
In high school I wrote several simple video games starting with a simple version of pong using the paddle controllers that came with the Apple II(s) we had in the math department. I wrote some basic space invaders style games, and I was working on a D&D like texted based game with tracked random threats and rewards in each room. The contents of the room or dungeon were random, but then stored for the duration of the game stored in a massive array. I was doing some testing when it a loop condition I missed closed and it started doing continuous drive access. I was just about to pull the plug out of the wall when smoke poured out of the drive. Yeah I smoked hardware with software. I'm still not sure how I did that because drive access was supposed to be minimal.
An instructor once asked me to write a program to generate a test for his algebra class with random computer generated problems on each test so they couldn't cheat. It worked great until he walked over to me with a big stack of completed tests and asked for the answer keys. You know he kicked me out of his class 13 different times in one semester. I still got the 'A' I earned though. LOL.
I did some playing with an HP 9825A the year before, but with a tape drive and a one line LED display its was kinda slow and tedious to do anything. Mostly I just played around with it when I was bored with playing poker in study hall.
I once ran some outdoor speakers from my stereo on the place I was renting so I could listen to music when working on my truck. I also had my computer sound tied to my stereo for gaming. One night I was playing a tank combat game and forgot I had the outdoor speakers turned on. My neighbors called the landlord who sent somebody over to tell me to stop bombing the neighborhood.
HCF instruction?
Halt & Catch Fire?
Reading the "programming experiences" - haven't we developed our own expertises and acquired what we had to acquire to do our "bench" and "application" tasks? I am sorry I've pontificated on about my own very narrow things. Perspective is restored - aren't we folk who will learn anything which makes a path to a goal defined in the physical world?
We had to be very close to the computer hardware more than two decades ago, because our big ideas and dreams proved bigger than computer memory availability, etc., when we improvised our way in.
Reading the "programming experiences" - haven't we developed our own expertises and acquired what we had to acquire to do our "bench" and "application" tasks? I am sorry I've pontificated on about my own very narrow things. Perspective is restored - aren't we folk who will learn anything which makes a path to a goal defined in the physical world?
We had to be very close to the computer hardware more than two decades ago, because our big ideas and dreams proved bigger than computer memory availability, etc., when we improvised our way in.
-----------------------------------
For me understanding computer and other new electronic hardware was a way to advance after my career as a chemist was cut short, first by the draft blocking grad school and then the EPA chasing the industry off-shore. Returning to college full-time again was out and seeking an EE degree at night while supporting myself proved impractical though I did try. That ended when I fell asleep driving home late and woke up with wheels in the gravel.
The rapidly evolving computer landscape gave me an opening to be valuable and advance by keeping current with new developments. I'd always been a very hands-on builder with good near vision and fine motor skills, and noticed that technicians did hobby-like bench work generally without annoyances while degreed engineers sat and argued in meetings. There was very little competent competition for both designing and constructing small projects or parts of larger ones sized for one person, especially for handling electronic hardware plus software plus mechanical packaging. The job of technician is open-ended, Arnold Wilkins contributed as much or more to early British radar as Watson-Watt.
When I saw James Bond I knew immediately that I wanted instead to work for or become Q, and in Army Basic I actually got to make that choice.
I made a spray can that sprayed when tested and could also contain secret passwords etc, a light bulb that stored a hidden key, and folded and soldered tin can steel and copper pipe scrap into a candy bar sized box that unfolded into a crossbow which shot darts with X-Cube flashbulbs heads that flashed on impact.
I could usually solve a problem in a way too simple to patent as a commercial product so I kept quiet and was paid to built the solutions others had proposed, twice after reducing its complexity and cost by half or more. Example are the very simple solar tracker circuit I mentioned, my sealing and insulating inserts that double the efficiency of standard windows and a sink spray replacing a shower head, which began as a cold weather dog washer.
I clean my wood stove chimney weekly from ground level by pulling one cord to flip open the rain cap and another to hoist up, swing over and drop in a weighted shop-made brush of nylon string trimmer cord, curve up to slide down easily when very cold and then dig in upward. The metal chimney rests on a shelf with clearance underneath for a tub to contain the soot. My roof gutters are on shop-made hangers that leave the top clear for a cleaning scoop on a swimming pool extension pole.
AFAIK no one has copied my folding heavy hoisting tripod which is too easily made to protect with a patent. I may ask the trade school engineering teacher who taught 3D CAD to see if he can analyze the multiple angular stresses in the joint. I go by what has deformed and been upgraded. I'd like to know if the leg loading vector is close enough to centered axially to justify k=1 in a column strength formula, which gives a high capacity with common light weight material.
We had to be very close to the computer hardware more than two decades ago, because our big ideas and dreams proved bigger than computer memory availability, etc., when we improvised our way in.
----------------------------------- The company where I worked in the 80's built production line testers for the memory and other IC manufacturers. They had the problem of creating a test pattern that was to be written and read back as fast as possible in memory smaller and perhaps slower than the newest product it was testing.
I believe I recognise the core of these things you try to portray.
I gather there was some of ingenuity in the British defence industry as it was being benevolently managed by the Government through the 1960's and 1970's ish. Someone with a Trade background running a facility described maintaining a small "free-standing" workshop offline to the production, where if one of the "boffins" turned-up with an idea, that "boffin" could try to make it, mentored by technicians, getting all the wisdom, and "see where it went".
Best wishes
I believe I recognise the core of these things you try to portray.
I gather there was some of ingenuity in the British defence industry as it was being benevolently managed by the Government through the 1960's and 1970's ish. Someone with a Trade background running a facility described maintaining a small "free-standing" workshop offline to the production, where if one of the "boffins" turned-up with an idea, that "boffin" could try to make it, mentored by technicians, getting all the wisdom, and "see where it went".
Best wishes
--------------------------- In the US that would be a toolroom or model shop. In my experience the primary machine tool was a Bridgeport or clone, doubling as the drill press, a lathe was optional. For newer machinery the rotating wear parts a lathe can make usually could be bought. For making my own designs from scratch at home that's reversed.
The instructor for the ham radio course at Mitre was a retired British radar boffin / wizard who was still actively experimenting and building exotic hardware. Some of it looked like musical instruments because microwave band wavelengths are similar to those of sound, and brass is sufficiently conductive and convenient to work with.
Usually the Ph.D gave me a sketch and the data sheets of the critical parts he had ordered, then left me alone to implement it. I suspect they didn't want to embarrass themselves by revealing they didn't know the practical details or methods, I also resoldered stuff their kids had broken. By being able to do the mechanical fabrication as well, sheet metal enclosures and milled microwave or optical housings, I avoided the inevitable disagreements and delays of depending on another tech or shop.
The auto exec Ph.D from India whose antilock brake controller failed to pass specifications didn't know that available resistors have tolerances, he expected 8 digit precision of the 2nd order wheel deceleration curve and its detection.
The mechanical engineers at Segway were much more hands-on, I often had to use their manual or my own machine tools because the CNC machines were busy.
The old car I'm fixing suffers from shortcuts that let water enter and collect where it shouldn't. For instance a moderate buildup of tree debris in the cowl will let water flood over the low cabin air intake lip and pool on the passenger floor. The cowl end drains allowed water and debris to enter the areas that rusted. Cleaning the cowl channel meant breaking some of the snap-in plastic retainers the dealer charges several $ apiece for. They are now all stainless screws and U clips. The push clips are tolerable to install and remove if stainless screws replace the plastic expansion pins.
I attend classic car shows to learn how others made repairs. Too often I learn they were skilled at writing big checks.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required