-
@allObjects, this reminds me of Objective-C and Next Computer's graphical IDE. That was a time when this sort of methodology for application development was all the rage ('90s). I seem to recall some SmallTalk IDEs that also tried to get actual code-writing completely out of the picture.
What failed, and still does, is that none of these schemes simplify away the underlying engineering complexity of any real application, in which case the "difficulty" simply shifts from coding to interface definitions and protocols. Having been down this path, one soon finds that any "real world" application of any meaningful functionality and complexity ends up being just as much work -- or more -- to architect, specify, and implement interface and protocol specs, finding that in many cases it's "just easier" to fall back to actual code (C, C++, O-C, Java, whatever) and bang out something concise and efficient.
It's why these methods faded from the scene.
IMO, the real revolution for software engineering will come with AI, not IDEs and various alternative ways to spec program algorithms, which is really what this sort of thing is. Rather, when we have AI that we can simply describe a problem to, perhaps in some formal syntax, better if we can just talk to it, and it spits out the program.
That would free the designer to focus on features, function, behavior, etc.
The other domain that I think is woefully under-invested-in from the standpoint of software development is failure/defect detection and debugging. So little brainpower, relatively speaking, has been spent on improving and enriching this aspect of code development.
You are reading a single comment by @dwallersv and its replies.
Click here to read the full conversation.
dwallersv
(...quote from node-red group post).
There was a time where this was a great hype... 90'... and it faded, but I still believe it has great value. What I refer to is VisualAge for XYZLangue - an application (programming and generator) product series from big blue IBM.
Visual linking - programming - is great when the interfaces are nicely defined and the linking can generate proper plumbing code. Not so fun is it when timing and circular references come into play. It get's pretty complex - almost like garbage collection - to avoid racing conditions. See attached graphics for a taste of how it looked (taken from IBM Redbook Using VisualAge Smalltalk ObjectExtender, p. 327 (.pdf: p.353).
First attachment has decent complexity, following ones? ...I don't know... :|
It WAS fun! Placing graphically (with the mouse / track pad) a connection triggerd a lot of plumbing in the background... I like to see some of this coming back!