3 ms·

It did take off... Delphi and Visual Basic 6 were immensely popular. In either case, you had drag/drop GUI elements, property inspectors, and easy ways to call

It did take off... Delphi and Visual Basic 6 were immensely popular. In either case, you had drag/drop GUI elements, property inspectors, and easy ways to call methods on all the relevant events. You simply designed your GUI forms, then wrote code to connect up the pieces. You didn't have to figure out how to build call back handlers, or much of the grief of a main event loop in Win32.

wizofaus 4y ago
Key word being "were". I'm not aware of widely used similar tools for modern WFEs (which arguably makes up most user facing software these days). I did use something like it back in early ASP days, which were mostly server-side web apps.
- mikewarot 4y ago
  The core technology at the heart of both VB6 and Delphi were the Win32 Common Controls, a set of native code GUI elements that are still present in windows. They offered a consistent toolkit across all windows versions. At the time, this was most GUIs. It is unlikely that any one set of native GUI elements and library calls will ever be applied across all GUIs ever again. The constant churn of languages, the web stack, the vast size range of displays all combine to a situation where GUI application development receded from a high water mark, and it's all downhill from here. The tools are worse than they were, and are unlikely to recover.
  - wizofaus 4y ago
    What you can show/build with HTML/CSS/JS hasn't really changed that hugely in the last few years. There are RAD tools for React apparently (retool?) and I don't doubt they wouldn't be appropriate for all uses, but there's plenty of cases where you just need to throw together something quickly where being able to "build" the page layout visually would be extremely helpful. I sometimes get the impression many React-based sites you just get whatever layout happens to be the default (based on HTML5/CSS specs, and whatever libraries/out-of-the-box stylesheets you might use), even if the exact outcome doesn't really match what's been asked for by the UI/UX designer (who almost certainly did use a WYSIWYG tool to come up with the wireframes/static mocks etc).
quickthrower2 4y ago
That is not really nocode and there is definitely a limit before you need to concern yourself with architecture, structuring code, dealing with complexity etc. I remember those old visual tool where you could even drag on DB connections. But soon as you have a complex requirement like joining two tables or something then boom you are in yescode.
- mikewarot 4y ago
  Microsoft Access 2000 was great at doing table joins in a visual way. It automatically enforced relationships between tables without having to write any SQL. It is possible to go all the way to writing programs with no actual text source, but the "cognitive impedance match" has to be reasonable. In theory, you could just take MIT's SCRATCH and hook it to a compiler... but it's not the right tool for managing that complexity. My current feeling is that something like literate programming, with rich source, both declarative and imperative functional code is the way to go for optimal productivity. The front ends that handle GUIs and events match that part of the problem in a profoundly productive manner.

wizofaus 4y ago

Key word being "were". I'm not aware of widely used similar tools for modern WFEs (which arguably makes up most user facing software these days). I did use something like it back in early ASP days, which were mostly server-side web apps.

mikewarot 4y ago
The core technology at the heart of both VB6 and Delphi were the Win32 Common Controls, a set of native code GUI elements that are still present in windows. They offered a consistent toolkit across all windows versions. At the time, this was most GUIs. It is unlikely that any one set of native GUI elements and library calls will ever be applied across all GUIs ever again. The constant churn of languages, the web stack, the vast size range of displays all combine to a situation where GUI application development receded from a high water mark, and it's all downhill from here. The tools are worse than they were, and are unlikely to recover.
- wizofaus 4y ago
  What you can show/build with HTML/CSS/JS hasn't really changed that hugely in the last few years. There are RAD tools for React apparently (retool?) and I don't doubt they wouldn't be appropriate for all uses, but there's plenty of cases where you just need to throw together something quickly where being able to "build" the page layout visually would be extremely helpful. I sometimes get the impression many React-based sites you just get whatever layout happens to be the default (based on HTML5/CSS specs, and whatever libraries/out-of-the-box stylesheets you might use), even if the exact outcome doesn't really match what's been asked for by the UI/UX designer (who almost certainly did use a WYSIWYG tool to come up with the wireframes/static mocks etc).

quickthrower2 4y ago

That is not really nocode and there is definitely a limit before you need to concern yourself with architecture, structuring code, dealing with complexity etc. I remember those old visual tool where you could even drag on DB connections. But soon as you have a complex requirement like joining two tables or something then boom you are in yescode.

mikewarot 4y ago
Microsoft Access 2000 was great at doing table joins in a visual way. It automatically enforced relationships between tables without having to write any SQL. It is possible to go all the way to writing programs with no actual text source, but the "cognitive impedance match" has to be reasonable. In theory, you could just take MIT's SCRATCH and hook it to a compiler... but it's not the right tool for managing that complexity. My current feeling is that something like literate programming, with rich source, both declarative and imperative functional code is the way to go for optimal productivity. The front ends that handle GUIs and events match that part of the problem in a profoundly productive manner.