When I first started programming, the days of batch programming, I used punched cards as an input to the computer. The turn around time for a compile was 24 hours. Soon I moved to time sharing on a PDP 11 having 512 K memory, and a 40 MB disk the turn around time for a compile and link for a 3000 line COBOL program was around an hour. In those days I would draw a flow chart or HIPO diagram, or pseudo code then hand write the code, hand run them, enter them through the editor, print it out go through the printout to correct any entry errors and then compile, link and test it.
Computing speeds have grown be leaps and bound, my desktop is now much more powerful than what I had used in the past. A compile of a similar program would now take a few seconds.
Now I find that given program specifications programmers open the IDE and start coding the program.
Was I doing something wrong earlier by spend so much effort rather than wrting the program directly in the editor?
Subscribe to:
Post Comments (Atom)
7 comments:
Dear Raju,
Nice question. Issues of programmability, maintainability, cheaper and faster processors, availability of cheap memory are all constantly redefining what the right approach to a software development should be.
When I learned computers, we too actually learned about computers - like JK flipflops, AND and OR gates and shift registers.
Most of the programmers today including me don't seem to have a clue what's happening inside the box. They think a register is a cash register, or a thing in the floor of your house that emits hot air.
If I know one thing, it is that the rate of change in Computer Science/ Technology is much faster than in other engineering fields like say Automotive or Civil Engineering. If you are out of school for five years, go check out the classes, languages, approaches, tools that your own school uses and teaches. You will be astounded at how much you don't know unless you diligently keep up with industry!
I feel indeed programming shift from batch to event is a part of that changing times.
Dear Dharmesh,
Would you like to say that it is perfectly fine not to draw flow charts, write pseudo code, but program directly.
The COBOL manuals I had were approximately 500 pages with examples in them, I never thought that I was a master in that I could think the logic and translate the logic into a programming language simultaneously. Todays software platforms have manuals running to over 3000 pages, however I find that given specs programmers directly write programs into the language, or that todays generation is smarter than the earlier generation, hence they can do it.
Dear Raju,
No I do not think that building flow charts or writing pseudo code is not necessary. There has been automation in these. Nor do I think younger generation is smarter. On another note, I think that older programmers bring certain skills with them - Knowledge of business which we lack.
I think over the years, the industry thought of reducing the cost of software development and the IDE's had the target of Improving Productivity, Developing at light speed,Freeing the inner designer, Working Collaboratively, etc.
From what i can make out, we are trying to figure out the paradigm shift in terms of the need to write preliminary pseudo code or algorithms before we actually write code. I do think that we have totally moved away from the algorithm way of writing code, though there is no escaping it when you are trying to understand complex business flows.So we are not completely out of synch but usage has surely reduced.
we're just writing simpler programs now.
programmers today can never write billing engines like they did 20 years ago, ....
...and if they could, they would have to read all 3000 pages of the manual.
Abstractions are what today's programmers are taking advantage of. There is a nice article by Joel on this
Like when I wrote my first program to multiply 2 integers and assign it to third (c=a*b) on a 8085 MPU it was program spanning 15-20 lines (i guess) with initializing registers, running through the loop of adding a to itself b times etc..etc.. With Java we do it in less than one line. Abstraction again.
While programming for data structures in C I had to write a program to traverse doubly linked list and stack and all that.. I don't need to do that anymore in Java. Collections API has abstracted that for me.
Similarly when I first started programming Java the JDK API was the best reference available (and still is) and its a habit for me to go there every now and then. But with advent of IDE's hardly any programmers do it because they get that help in the dropdowns of their tools. Abstraction again.
I guess probably in 5 yrs. from now programmers wont be even writing for and while loops with new languages like Ruby.
Yes there are pros and cons of abstraction. Like it gives faster development cycles but I dont know how many today would know how to write a quicksort or mergesort programatically !!
..and it could be an eternal debate.
Post a Comment