Long before I learnt to write any code more knowledgeable people than me talked about the need to create a flowchart before typing any code. I remember someone I knew with a degree in software writing telling me that if you create a good flowchart the code pretty much writes itself. My first efforts at writing Z80 assembly language started with a flow chart to help organise my thoughts. I never use a flow chart now because the code is the flowchart, at least in my head. I note that flowcharts don't get mentioned often here, a comment to beginners I don't see is "before writing any code create a flowchart".
Doing a flowchart is like painting the front door.
You really want to get the top coat on, when at heart, you know you have to do the boring bits like sanding it down and filling the holes first.
Programming, like painting, is a series of steps with branches. "while primer is drying, make cup of tea".
A flow chart, the plan of action, is the important part, but I hardly ever do it. It's straight into the code, then wonder afterwards, when it doesn't work, why didn't I spend 30-minutes thinking about it, instead of two days of frustrating failures?
Or, now that the top coat is on and the blemishes really show up, perhaps I should have spent time preparing it.
Hi,
I was taught the flow chart method.
But when C appeared started writing pseudo code.
Now days with neuropathy making my pseudo code look like hieroglyphics, a bit of flow chart then C++ in stages, building up the code.
Tom....
PS. I haven't programmed in ladder logic for 10years, just recently got called to an old PLC job I did.
It put a smile on my face as I could monitor all the variables and functions live on lovely program rungs.
Think they got eaten by fast compilers.
When compilation meant a coffee break and you could only do so many runs per day, it was good to have your design right and complete to optimize your time.
They convey flow for the audience (review panel, task-specific colleagues, inter-module communication). I have worked on a few projects where "?what to do when?" was not recognized, causing bad results... something like...
At IBM we outlawed them at some point in the mid to late 70’s. They had several problems. The first is that nobody maintained them (same as comments), so they became useless after the development cycle. Newer tools like Structured Analysis and Design quickly replaced flow charts. One mitigating factor is that flow charts were MUCH better suited to assembly language, but that had pretty much disappeared in favour of many high-level languages by then.
Today, with terminals and network software, it is no longer two-dimensional, and flow charts can’t represent 3D (asynchronous)
Concepts like multi-threads, virtual memory, asymmetric multiprocessing, and modern-day apps with touch screen events, etc, simply don't ‘flow’ from step A to B anymore.
However, they may still be useful in certain special cases, just like an assembler is still used very rarely for special cases as well.
We cheered when we got TWO turnarounds a day instead of one. The day of writing code on a formatted pad and sending it to the keypunch department to be replaced by an online (some of the time) terminal also gave us the sloppy programmer. I still remember a new out of college programmer bragging to me how he got 2 hundred compiles one day.
Today at least for the Arduino eco-system, it’s actually pretty hard to make an error what with code completion and all the other IDE tools, even the manual is a mouse click away.
I hear VsCode and PlatformIO are even further advanced, but I have tried 3 or 4 times and can’t get them properly installed so I can’t comment further.
Oh yes, the punched cards, IBM.
This was in the days of Fortran, mainframe, teletype the nearest to an HDI.
As users, we punched the cards, delivered them to IT, returned next day, often job failed on the header page of the pile of tractor feed paper.
Missing full stop.
Wrote a program to fit a curve to data points. One minute job now in Excel.
We don't know how lucky we are now.
Sorry to hear about the neuro problem.
I used to program small PLCs (Intelligent Relays) for works automation jobs.
No-one in management bothered to see if I kept copies of the code.
When I left the firm, I took the code with me.
I promised my workmates that I would support them for 6 months.
It was a UK water company. I despair when I see the mess they are in.
Nobody on the forum predates punched cards. They were invented by Herman Hollerith (hence the Hollerith code) in the 1880s. He formed the fore-runner to IBM called the Tabulating Machine Company in 1896.
In my early years at IBM late 60’s I used paper tape, and even physical wires to ‘program’ various machines. Output was often punched tape or Type42 teletype.
Flowcharts are still around. A lot of their functionality is now expressed in Sequence Diagrams and dataflow diagrams and also Activity diagrams.
I find that they're best when you need to draw an algorithm that's specific to a particular function, rather than going across multiple functions.
They are also very good when you have to discuss a procedure with people who are not software developers. I work daily with EE's, mechanical engineers and biochemists, so talking software procedures with them doesn't usually work very well. But they almost always understand a flowchart.
