What an interesting thread. Many years ago I taught a few computer related classes at tech school. Conclusion, every student has a different way of learning, different motivators, different abilities. There were tricks to motivate groups, but there was still a need to zero in on different students and have a minute or two of one-to-one. So describing any coding environment as 'best' just doesn't wash.
My introduction to computers was Algol on an Elliot 803. I started an Elec. Eng. Diploma and one of the classes was 'Computer Programming for Engineers'. Hooked from day one and decided I wanted to be a programmer. My motivation was the opposite of most people, I wanted to know how it worked. Didn't care if I was writing a program to work out orbital mechanics, blowout pressure of rubber rings in concrete pipes, ball bearings suitable for applications, or payroll. How to achieve the end efficiently was more important. Working with a 64kbyte system with a 2 microsecond cycle time encourages that.
Most people want a tool to achieve an end. Learn enough about the tool to move the sprite on the screen, blink the LED, spreadsheet the stock market. Learning to do it 'properly' is not on the radar. And as long as the tool does the job, a switch to another tool is not often considered even if it is better/easier. The outcome is more important than the method.
So the process is determine what the person wants to do - this is often the hardest part. What is motivation enough to get them learning the tool? Then, with a destination in mind, decide on the tool. You don't see a plumber running around with an oscilloscope, or an electrician with gas fitting tools. After those are in place it is time to introduce logical thinking. Up to a point, any 'application' can be written in any code environment. The old saying was if it could be done, it can be done in FORTRAN. If it can't be done, do it in assembler.
Back a ways there was a mention the PL/1 compiler was written in FORTRAN. I had the task of figuring out why a FORTRAN program on a VAX was not running as well as it should. A back of the envelope calculation said it should take much less, so I was tasked to hand code the critical parts in assembler (the FORTRAN compiler would take in line assembler). To my surprise, the critical parts took only 10% longer than what I considered optimal. The compiler was very good at optimization. The problem turned out to be the programmer's I/O - they were reading/writing individual array elements to disk. I modified the program with a couple of lines of FORTRAN to read/write 1000 elements at a time, reduced run time from 40 hours to 8. So the idea of a compiler written in FORTRAN is not too far fetched.
And there is the difference between motivations - the program did what the writer wanted, and if it took 30 minutes instead of 5 there wouldn't be an issue. A similar issue occurred in another job, a program analyzed figures and took half an hour. The accounts department ran the program with four different sets of figures every week, which wasn't too much of an issue. But 7 sets at end of month was; end of month was a busy time. I offered to look at the program, restructured and reduced run time to under a minute with all 7 sets of data. My reward was the boss shouting me a beer.
So now I'm a dinosaur. I love the fact that two variables can be swapped by A xor B, B xor A, A xor B - with no other data space required. How many other people would care? A project I am working on needed more code. I had not worried how long it was taking, it hadn't crashed (yet). But would it handle the extra work? A quick benchmark showed the processor was used less than 1%. The extra code might push that to 1.5%. And I was only using half the available code space. The penalty of a frugal upbringing.
I hope you don't mind a bit of reminiscing.
When it comes to coding v programming, I look to the examples I gave. In my mind a coder has a task and achieves it. A programmer is more interested not only in the what, but also in the how. A programmer looks to other considerations such as readability, maintenance, resources, etc.
Home
Help
Search
Login
Register
