"A picture paints a thousand words"

[Gareth Evans]

For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

With millions of frustrated programmers around the
World I am sure that I am not the only person to
be thinking in that direction, "There's nothing
new under the Sun".

I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

With a relative of mine being a schoolteacher, I've just
had my eyes opened to the Scratch language.

Wow!

[Ahem A Rivet's Shot]

On Mon, 27 Apr 2020 13:18:39 +0100

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

It's been tried a few times - the usual result is dialogue box
laden, frustrating and limited in scope.

Post by Gareth Evans
I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

Nobody uses flowcharts these days.

[Gareth Evans]

Post by Ahem A Rivet's Shot
On Mon, 27 Apr 2020 13:18:39 +0100

Post by Gareth Evans
I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

Nobody uses flowcharts these days.

Then I'm nobody. An algorithm designed gaphically is
expressable in any language.

[Scott Lurndal]

Post by Ahem A Rivet's Shot
On Mon, 27 Apr 2020 13:18:39 +0100

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

It's been tried a few times - the usual result is dialogue box
laden, frustrating and limited in scope.

Post by Gareth Evans
I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

Nobody uses flowcharts these days.

Please don't feed the troll.

[Gareth Evans]

Post by Scott Lurndal
Please don't feed the troll.

We have crossed swords before because of your
immature outbursts such as is quoted above.

Grow up, Sonny.

[Peter Flass]

Post by Ahem A Rivet's Shot
On Mon, 27 Apr 2020 13:18:39 +0100

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

It's been tried a few times - the usual result is dialogue box
laden, frustrating and limited in scope.

Post by Gareth Evans
I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

Nobody uses flowcharts these days.

I still do, very occasionally, when the the task lends itself to them. I
also have used hierarchy charts, decision tables, and other “obsolete”
techniques. It’s good to know how to use them.

[Bob Eager]

Post by Peter Flass

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

I still do, very occasionally, when the the task lends itself to them. I
also have used hierarchy charts, decision tables, and other “obsolete”
techniques. It’s good to know how to use them.

I mainly use pencil and paper for state diagrams!

[J. Clarke]

On Mon, 27 Apr 2020 10:51:56 -0700, Peter Flass

Post by Peter Flass

Post by Ahem A Rivet's Shot
On Mon, 27 Apr 2020 13:18:39 +0100

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

It's been tried a few times - the usual result is dialogue box
laden, frustrating and limited in scope.

Post by Gareth Evans
I'd intended to base my stuff around the structured
flowcharts in the (now discontinued) British standard
of BS6224.

Nobody uses flowcharts these days.

I still do, very occasionally, when the the task lends itself to them. I
also have used hierarchy charts, decision tables, and other “obsolete”
techniques. It’s good to know how to use them.

When I'm trying to understand 40 year old spaghetti APL, I find that
flowcharting it is very beneficial. If nothing else, a look at the
flowchart gives my manager an idea of what I'm dealing with.

[Ahem A Rivet's Shot]

On Mon, 27 Apr 2020 10:51:56 -0700

Post by Peter Flass

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

I still do, very occasionally, when the the task lends itself to them. I

It has been a long time since I've had a task that lent itself to a
flowchart.

Post by Peter Flass
also have used hierarchy charts, decision tables, and other “obsolete”
techniques. It’s good to know how to use them.

Yes it is, although any design I'm involved in is more likely to
require documenting language choice(s) (and reason(s) for it), a set of
class hierarchies, some service APIs, key algorithms, a test plan (what's
covered by unit testing and automated functional testing and what can only
be tested manually), a review of alternative solutions and an effort
estimate.

[Dennis Boone]

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

Or, apparently, any other form of design documentation. That's
not a good thing.

De

[Ahem A Rivet's Shot]

On Mon, 27 Apr 2020 15:39:20 -0500

Post by Dennis Boone

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

Or, apparently, any other form of design documentation. That's
not a good thing.

Design documentation has been required to be written and reviewed
everywhere I've worked, it just doesn't include flowcharts largely because
they're insufficiently expressive. Anything simple enough to flowchart is
usually off the shelf in a well tested library.

[Peter Flass]

Post by Dennis Boone

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

Or, apparently, any other form of design documentation. That's
not a good thing.
De

+1

[Dan Espen]

Post by Dennis Boone

Post by Ahem A Rivet's Shot
Nobody uses flowcharts these days.

Or, apparently, any other form of design documentation. That's
not a good thing.

Hmm, up until I retired, I wrote tons of documentation.
Back when this was on paper,
one person I know referred to them as "rare books".
We did a design that filled 8-10 loose leafs.

My last job I founds dozens of text and script files.
There was a main document and dozens of enhancement
descriptions. I rewrote everything I could find as HTML.
I ended up with maybe 5000 lines of prose.
I used tables whenever I had a list,
that might have been 5% of the written material.

Out of all that, I only had 2 hierarchy charts which
I changed from ASCII art to SVG. 5 or 6 boxes in each.
I only left them because they were there when I started.

I'm not a big chart fan, you can say "A" calls "B" or
you can put "A" and "B" in boxes and connect them with an arrow.
Pretty much that same thing.

Flowcharts were the thing in the 60s and 70s.
When it turned out you could run your COBOL through a
program and produce a flow chart, flow charts fell out
of favor. Pseudo code was quite popular in the 70s or
maybe 80s but I was never a fan. Now I look at all of that
as a way of coding, so I just write the code liberally
sprinkled with comments about what I haven't written yet.

[Johann 'Myrkraverk' Oskarsson]

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.

I never came across it again, nor do I remember what it was called. It
could have been from someone other than Novell. Apparently, a quick web
search doesn't turn anything up.

So, it's been tried before, and hasn't caught on.

[Gareth Evans]

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s.  I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called.  It
could have been from someone other than Novell.  Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Well, what I was thinking of was something that would produce
executable code but without first vomiting up some C, FORTRAN,
ALGOL, assembler, or what ever floats your boat.

This afternoon I have been browsing Scratch and Blocky and
discovered by googling other VPLs. That' the trouble of being
retired without day-to-day contact with other softies; you
don't get knowledge of developments.

[David LaRue]

Post by Gareth Evans

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s.  I either had a limited (free?) edition that
didn't create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. 
It could have been from someone other than Novell.  Apparently, a
quick web search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Well, what I was thinking of was something that would produce
executable code but without first vomiting up some C, FORTRAN,
ALGOL, assembler, or what ever floats your boat.
This afternoon I have been browsing Scratch and Blocky and
discovered by googling other VPLs. That' the trouble of being
retired without day-to-day contact with other softies; you
don't get knowledge of developments.

I looked at Scratch several years ago. I program in many languages but
C/C++ the most. I had to restructure some code this morning to fit a
new data model. While it could be flowcharted or displayed visually the
challenge is also to allow the developer to work with a creation and
create something new. Scratch allows some restructuring but needs more
to help the developer. Building big or real world applications or
systems in Scratch would likely take too long and be unmaintainable.

It is worthy to consider such problems though. It makes us think and
strive to create better ways. There was a long thread in one of the
system modeling groups many years ago by a retired professional that was
teaching how to create everything from the requirements. He was a
wonderful teacher.

David

[Radey Shouman]

Post by David LaRue

Post by Gareth Evans

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s.  I either had a limited (free?) edition that
didn't create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. 
It could have been from someone other than Novell.  Apparently, a
quick web search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Well, what I was thinking of was something that would produce
executable code but without first vomiting up some C, FORTRAN,
ALGOL, assembler, or what ever floats your boat.
This afternoon I have been browsing Scratch and Blocky and
discovered by googling other VPLs. That' the trouble of being
retired without day-to-day contact with other softies; you
don't get knowledge of developments.

I looked at Scratch several years ago. I program in many languages but
C/C++ the most. I had to restructure some code this morning to fit a
new data model. While it could be flowcharted or displayed visually the
challenge is also to allow the developer to work with a creation and
create something new. Scratch allows some restructuring but needs more
to help the developer. Building big or real world applications or
systems in Scratch would likely take too long and be unmaintainable.
It is worthy to consider such problems though. It makes us think and
strive to create better ways. There was a long thread in one of the
system modeling groups many years ago by a retired professional that was
teaching how to create everything from the requirements. He was a
wonderful teacher.

Ladder logic is still quite popular for programming PLCs, it is even
standardized as IEC 61131-3. Can't get much more graphical than that.

[Radey Shouman]

Post by Gareth Evans

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s.  I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called.  It
could have been from someone other than Novell.  Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Well, what I was thinking of was something that would produce
executable code but without first vomiting up some C, FORTRAN,
ALGOL, assembler, or what ever floats your boat.
This afternoon I have been browsing Scratch and Blocky and
discovered by googling other VPLs. That' the trouble of being
retired without day-to-day contact with other softies; you
don't get knowledge of developments.

Matlab simulink seems to be fairly popular these days. It's essentially
a pictorial (schematic) simulation language. Depends heavily on buying
expensive simulation blocks from the Mathworks, naturally.

[J. Clarke]

On Mon, 27 Apr 2020 22:56:09 +0800, Johann 'Myrkraverk' Oskarsson

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. It
could have been from someone other than Novell. Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Google "DRAKON programming language".

Another one, that doesn't use a flowchart paradigm but does involve
programming by dragging blocks around is "Scratch".

[J. Clarke]

On Mon, 27 Apr 2020 16:43:41 -0400, J. Clarke

Post by J. Clarke
On Mon, 27 Apr 2020 22:56:09 +0800, Johann 'Myrkraverk' Oskarsson

Post by Johann 'Myrkraverk' Oskarsson

Post by Gareth Evans
For some years I'd been toying with the idea of
a pictorial method of entering and maintaining
programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. It
could have been from someone other than Novell. Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Google "DRAKON programming language".
Another one, that doesn't use a flowchart paradigm but does involve
programming by dragging blocks around is "Scratch".

Also, see today's (April 27, 2020) Google Doodle.

[Bob Eager]

Post by J. Clarke
On Mon, 27 Apr 2020 22:56:09 +0800, Johann 'Myrkraverk' Oskarsson

Post by Johann 'Myrkraverk' Oskarsson

For some years I'd been toying with the idea of a pictorial method of
entering and maintaining programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. It
could have been from someone other than Novell. Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Google "DRAKON programming language".
Another one, that doesn't use a flowchart paradigm but does involve
programming by dragging blocks around is "Scratch".

Scratch is used a lot in primary schools. I've been training primary
school teachers in computational thinking (for them to pass on to
pupils), and a lot of them use it.

[J. Clarke]

Post by Bob Eager

Post by J. Clarke
On Mon, 27 Apr 2020 22:56:09 +0800, Johann 'Myrkraverk' Oskarsson

Post by Johann 'Myrkraverk' Oskarsson

For some years I'd been toying with the idea of a pictorial method of
entering and maintaining programs, bearing in mind the thread title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called. It
could have been from someone other than Novell. Apparently, a quick web
search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Google "DRAKON programming language".
Another one, that doesn't use a flowchart paradigm but does involve
programming by dragging blocks around is "Scratch".

Scratch is used a lot in primary schools. I've been training primary
school teachers in computational thinking (for them to pass on to
pupils), and a lot of them use it.

Harvard has a computer science course for non-CS majors, "CS 50". They
start out with Scratch.

[Bob Eager]

Post by J. Clarke

Post by Bob Eager

Post by J. Clarke
On Mon, 27 Apr 2020 22:56:09 +0800, Johann 'Myrkraverk' Oskarsson

Post by Johann 'Myrkraverk' Oskarsson

For some years I'd been toying with the idea of a pictorial method
of entering and maintaining programs, bearing in mind the thread
title.

I seem to recall something like a picture programming language from
Novell in the 90s. I either had a limited (free?) edition that didn't
create executables, or it didn't do what I thought it did.
I never came across it again, nor do I remember what it was called.
It could have been from someone other than Novell. Apparently, a
quick web search doesn't turn anything up.
So, it's been tried before, and hasn't caught on.

Google "DRAKON programming language".
Another one, that doesn't use a flowchart paradigm but does involve
programming by dragging blocks around is "Scratch".

Scratch is used a lot in primary schools. I've been training primary
school teachers in computational thinking (for them to pass on to
pupils), and a lot of them use it.

Harvard has a computer science course for non-CS majors, "CS 50". They
start out with Scratch.

Interesting. And in the UK we teach it to 6 year olds!

[Ahem A Rivet's Shot]

On 28 Apr 2020 08:51:21 GMT

Post by Bob Eager
Interesting. And in the UK we teach it to 6 year olds!

OTOH the BBC had to censor material (9pm watershed) the Dutch teach
to 6 year olds in school!