4 ms·

I think Delphi got right the "Visual Programming" paradigm. I am surprised that we don't have something similar on newer environments. Perhaps is that multi-use

by huherto 13y ago

I think Delphi got right the "Visual Programming" paradigm. I am surprised that we don't have something similar on newer environments. Perhaps is that multi-user RDBMS with SQL and/or the Web broke the model. I don't know, but it is an interesting question.

pjmlp 13y ago
The web broke it. The frankenstein model of CSS/JavaScrip/HTML cannot provide the same RAD capabilites as native applications.
vram22 13y ago
I don't think the advent of mult-user RDBMS/SQL broke it. There was a time frame (some years) when client-server apps were all the rage - Visual Basic / Delphi / PowerBuilder / Gupta SQL as the front-end tools, talking over a LAN or even sometimes a WAN to back-end databases like Oracle, Sybase, SQL Server, Informix, etc. I've worked on some projects of that type earlier. The technical discussions used to be about things like thin client vs. thick client, database transaction isolation levels, whether to use record locking vs. time-stamping, etc., use of stored procedures and triggers, etc. ... :-)
- vram22 13y ago
  E.g.: http://en.wikipedia.org/wiki/Gupta_Technologies http://en.wikipedia.org/wiki/Gupta_Technologies http://en.wikipedia.org/wiki/PowerBuilder http://en.wikipedia.org/wiki/PowerBuilder
vram22 13y ago
Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all programming can be done visually/graphically, simply by drawing diagrams, dragging and dropping components onto a window, connecting them visually, etc. The visual part of programming with Delphi and similar tools like Visual Basic, was restricted mainly to designing/creating the UI, iteratively and visually, by dragging and dropping widgets like text boxes, labels, drop-down lists, gauges, graph controls, etc., onto a form (a window), setting those widgets' properties such as font, text foreground and background color, enabled/disabled, tab order, etc. etc. Also, data-aware widgets were useful; they would show the back-end database data represented by each widget, live, at UI design time (not just at run time). E.g. a grid widget could show the rows and fields of a table, live. But the rest of the code (widget event handling, business logic, etc.) still had to written in a text editor by the developer.
- gshubert17 13y ago
  Not completely "visual programming" as you say, but I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.
  - vram22 13y ago
    >I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too. Yes, you're right. I found it so too. I forgot to mention in my parent comment that Delphi also generated the stubs/skeletons for the event-handling procedures. Not only was that a convenience, it helped with learning the tool and Windows GUI programming too.

by huherto 13y ago

pjmlp 13y ago

The web broke it. The frankenstein model of CSS/JavaScrip/HTML cannot provide the same RAD capabilites as native applications.

vram22 13y ago

I don't think the advent of mult-user RDBMS/SQL broke it. There was a time frame (some years) when client-server apps were all the rage - Visual Basic / Delphi / PowerBuilder / Gupta SQL as the front-end tools, talking over a LAN or even sometimes a WAN to back-end databases like Oracle, Sybase, SQL Server, Informix, etc. I've worked on some projects of that type earlier. The technical discussions used to be about things like thin client vs. thick client, database transaction isolation levels, whether to use record locking vs. time-stamping, etc., use of stored procedures and triggers, etc. ... :-)

vram22 13y ago
E.g.: http://en.wikipedia.org/wiki/Gupta_Technologies http://en.wikipedia.org/wiki/Gupta_Technologies http://en.wikipedia.org/wiki/PowerBuilder http://en.wikipedia.org/wiki/PowerBuilder

vram22 13y ago

Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all programming can be done visually/graphically, simply by drawing diagrams, dragging and dropping components onto a window, connecting them visually, etc. The visual part of programming with Delphi and similar tools like Visual Basic, was restricted mainly to designing/creating the UI, iteratively and visually, by dragging and dropping widgets like text boxes, labels, drop-down lists, gauges, graph controls, etc., onto a form (a window), setting those widgets' properties such as font, text foreground and background color, enabled/disabled, tab order, etc. etc. Also, data-aware widgets were useful; they would show the back-end database data represented by each widget, live, at UI design time (not just at run time). E.g. a grid widget could show the rows and fields of a table, live. But the rest of the code (widget event handling, business logic, etc.) still had to written in a text editor by the developer.

gshubert17 13y ago
Not completely "visual programming" as you say, but I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.
- vram22 13y ago
  >I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too. Yes, you're right. I found it so too. I forgot to mention in my parent comment that Delphi also generated the stubs/skeletons for the event-handling procedures. Not only was that a convenience, it helped with learning the tool and Windows GUI programming too.