12 Feb
2011
12 Feb
'11
8:42 p.m.
On 2011 Feb 12, at 5:58 PM, Charlie Carothers wrote:
On 2/10/2011 7:48 PM, Fred Cisin wrote:
Decades ago I wanted to think about designing a graphical GP
programming language, we (or many of us) conceptualise things in terms
of flowchart-like diagrams and state diagrams and such and they tend to
be considered useful descriptions, so why not program in them, and skip
the intermediate procedural text-based-stream language. I suspect there
have been many attempts or half-efforts over the years, I also suspect
they end up being incomplete as GP languages or end up looking like
hacks.
Some time ago while talking with a friend about this he suggested that
UML (Unified Modelling Language) is a serious effort in this direction.
A cursory inspection looks interesting, but I'm not close enough to it
to comment on it more than that.
It's interesting that hardware logic description in the form of
FPGA/CPLD configuration has taken what might be considered a backward
step, from the graphical schematic diagram to procedural-like
text-based-stream languages, not to say there aren't reasons for that
direction, but nonetheless the text-based language gets more ingrained
as the description paradigm.
Way back when, there was the stumbling block of lack of graphical user
interfaces, not as much of an issue these days, although an agreed-upon
underlying graphical description language may be still contentious.
Somebody just left an IBM FLOWCHARTING TEMPLATE
X20-8020 on the floor
in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code
generator
as our next paradigm :-?
Something along those lines has actually occurred to me too. I keep
thinking there should be *something* that could be done to
revolutionize the way software is created. I'm pretty convinced the
way it's currently done is not the answer. Though I still really
enjoy writing C code, and though I'm careful to try to create easily
understandable and maintainable code, I always seem to finish projects
with the uneasy feeling that it could have been done better, maybe a
lot better. BTW, I reject the idea that OO is the answer. I think
when I was younger I didn't feel that way; I was just happy that the
blooming thing worked! Maybe there's a penalty for spending too many
years doing too many projects - you start to get all philosophical
about the process...