Steve does a nice job of defending the status quo, but I’m eager to move beyond that.
I think it’s important to realize that the term “programming” actually has two distinct meanings, and one is always implied — that’s the one I’m more focused on when I criticizing the use of imperative programming languages, and even programming languages in general.
First, let me say that I’ve made the majority of my income since 1997 as a Delphi developer. It did get quite a bit of traction between 1999 and 2007. I happen to think it’s the most productive coding platform on the market today, for a number of reasons that I won’t get into. And to borrow a famous mis-quote of Mark Twain, the rumors of Delphi’s demise are greatly exaggerated.
One thing that a lot of people don’t realize is that the US Veteran’s Admiistration has what is perhaps the largest installed base of Delphi code anywhere in the world, and they have not shown much interest in replacing it — because it's still working — and a lot of organizations have a really hard time overcoming the notion of “if it ain’t broke, don’t fix (or replace) it”. BTW, the VA is also single-handedly keeping another ancient technology alive that they use for their back-end databases, called MUMPS. They use Delphi for all of their customer-facing software, and MUMPS for the back-end DB stuff.
Embarcadero, the present owner of Delphi and most of the technology that Borland split off into CodeGear, keeps updating it regularly, and is making considerable inroads in foreign markets like Brazil, Columbia, and several EU countries including Belgium. Yes, it may be pretty quiet here in America, but it’s gaining traction elsewhere in the world.
And FWIW, I’m now semi-retired in part because I got tired of finding one job after another simply babysitting huge Delphi apps written in the D4-D7 time-frame that are still helping companies bring in millions and millions of dollars with very little need for maintenance. These have been very boring jobs.
The problem is that hardly anybody is using Dephi for NEW product development.
Yes, Delphi uses an extension of Pascal, which is another imperative language. That’s irrelevant. It has evolved to the point where there are some really amazing component libraries available for it that in some cases transform it completely.
For example, TMS Software is one of the largest Delphi component vendors in the world, and they have been working on this thing called WebCore which is a technology that lets you write an app in Delphi just as if you’re building a Windows app. But when you hit the Run key, the app opens inside of your web browser. In fact, the “executable” is actually a js file generated by compiling the Delphi ObjectPascal code into javascript and embedding it into a web page that you can upload to any web server. When you load it up, it runs in your web browser.
Here’s an example of something I whipped together (from scratch) in less than an hour just to see what it’s capable of doing. (It was my first WebCore app.)
https://bestkeywordmixer.com/ <
https://bestkeywordmixer.com/>
I wonder how long it would take to build that in any “full-stack” web programming platform. Less than an hour?
I used Delphi + WebCore and I didn’t write a single line of javascript — just ObjectPacal. And it’s not much code. (BTW, WebCore also runs within the free VS Code IDE, so you don’t even need Delphi. But it still uses ObjectPascal.)
One of the things VB and Delphi introduced (or at least popularized) was the notion of dropping “components” on a form or canvas and then setting various “properties” to affect their behavior. This paradign was adopted by others to the point where it’s now pretty much how most GUI-based apps work to some extent or another.
This is, indeed, some kind of “programming”, but it’s neither imperative nor declarative. Which gets me back to the other definition of programming I mentioned at the beginning. It’s a squishy, hard-to-wrap-your-hands-around thing that embodies a notion of “what one does to get computing devices to do one’s bidding”.
We saw it first employed in Unix systems with the command shell that lets you create “pipes” by connecting various commands together. The command shell implements a fairly simple language that’s hard to say is either imperative or declarative. Some would argue it’s more of a functional language.
But you can see more contemporary evolutions of this approach in Zapier and IFTTT.
The problem with this linear “pipeline” approach is that you have to have some way to divert feeds off of the main data stream to drive displays, and that’s not something we see implemented much. Usually the end of a Zapier “zap” goes into some kind of rendering widget, or a spreadsheet or DB.
Anybody who’s tried to use a single Unix pipe command to display multiple views of the data going through it knows this is one of it’s major weaknesses.
However, a guy named Boian Mitov implemented a Delphi IDE plugin called the OpenWire project where he published an open source definition of a GUI add-in that lets you drop high-level logic blocks onto a canvas, connect them with virtual wires, set some parameters, then hit the Run button and you can have something quite substantial running in a matter of seconds that did not take a single line of programming. Unfortunately, that didn’t gain much traction, probably because it was specifically designed to work inside of Delphi, although he extended it to C++Builder as well as Visual Studio.
Boian is a hardware guy at heart, and he took that basic technology and created a standalone IDE that is language agnostic and used it to create something that lets you “design” a “control program” of sorts that employs any number of dozens if not hundreds of “components” that reflect both chips and modules built around the Arduino architecture, which is very popular in the IoT world.
It’s called Visuino and you can learn more about it here:
https://visuino.com <
https://visuino.com/>
I’d refer to this as “visual programming”, but you’re not writing code the way most “visual programming” paradigms approach it. I guess this is more of a declarative interface, similar to Zapier.
This is “programming” in the more general sense — getting computers to do what you want — but not by writing code.
If you look at the CAD tools that building architects, semiconductor engineers, and aircraft engineers use, you can see other examples of visual programming that allow these people to build incredibly complex models of their designs without having to write a single line of code. They can hit a button and perform stress tests using a number of different factors and simulate failure modes.
I don’t know why we have not done that for our own use within the software development world, but sooner or later I believe it’s inevitable.
In fact, Delphi and similar visual form-builder app tools have one really huge downfall — they make unit testing of forms extremely difficult.
I’m tired of writing lines of code to describe what I want my software to do. I want somthing more visual and less prone to error, that requires less tacit knowledge of dozens of libraries and the latest functions and calling parameters, and is easier to test. I just want to be able to draw a diagram and say, “do this…” and it knows how.
-David Schwartz
> On Dec 24, 2022, at 4:25 PM, Steve Litt via PLUG-discuss <plug-discuss@lists.phxlinux.org <mailto:plug-discuss@lists.phxlinux.org>> wrote:
>
> David Schwartz via PLUG-discuss said on Sat, 24 Dec 2022 17:51:44 +0000
> (UTC)
>
>
>> But what have we done for ourselves? We
>> still use imperative languages to write code line-by-line, they are
>> subject to the same types of errors, debugging works the same way
>> (well, we didn’t have debuggers until the late 80’s), automated
>> testing is almost non-existent.
>>
>> It’s just insane to me how LITTLE we’ve done to improve the ability to
>> do this thing we call “programming”. Maybe it’s just … job security? :o
>>
>> -David Schwartz
>
> There's a different way to look at the phenomenon you mention. Maybe we
> still use imperative languages because they've stood the test of time.
> Declarative language Prolog was available since the 1980's, but it
> gained no traction, perhaps because it just didn't easily do what
> needed to be done. The functional languages are just now re-emerging
> after decades of being ignored, perhaps because the imperative
> languages did a better job in more use cases. And now Object Oriented
> Programming has mostly replaced structural programming, although I'm
> not sure that's a good thing in the majority of cases.
>
> Most modern Linux distros package Lazarus, a semi-clone of the ancient
> Borland Delphi, a primarily drag-and-drop GUI/Database programming
> method. For whatever reason, neither Delphi nor Lazarus ever gained
> critical mass. Others in this same genre were Powerbuilder and Clarion,
> both significant in the 1990's but faded into obscurity for some
> reason. Meanwhile, C keeps rolling on, as does Python. They stood the
> test of time. What Python can't do, C can, and what's too much work in
> C, Python with its standard libraries can easily accomplish.
---------------------------------------------------
PLUG-discuss mailing list:
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)