Should I just dive in to GUI programs?

[357mag 3]

I'm considering working in Delphi for awhile, and I was looking through my books (I have four of them), and every book starts off right away with Windows programming. None of the books teaches you console programming. Personally, I like console programming. I was wondering if there is a reason all of my books starts you off that way. Perhaps because Delphi is a clean, fairly easy to grasp language?

[Remy Lebeau 1442]

2 hours ago, 357mag said:

I was wondering if there is a reason all of my books starts you off that way.

Maybe because the majority of end users are not console users, and the books want you to reach a larger userbase more quickly?  Just speculating...

[FPiette 386]

Yes, you should! Console programming (Like Unix utilities) are mostly included in GUI programs... without GUI.

[PeterBelow 239]

13 hours ago, 357mag said:

I'm considering working in Delphi for awhile, and I was looking through my books (I have four of them), and every book starts off right away with Windows programming. None of the books teaches you console programming. Personally, I like console programming. I was wondering if there is a reason all of my books starts you off that way. Perhaps because Delphi is a clean, fairly easy to grasp language?

GUIs are just the majority of the applications build with Delphi. But you can easily build console programs with it, too. The File -> New  dialog also offers a template for that.

[Die Holländer 49]

Console programming is easy with Delphi.

The books will learn you the Delphi (Pascal) syntax and that is one of the most easy to learn of all the programming languages.

 

14 hours ago, 357mag said:

None of the books teaches you console programming.

That was dummzeuch's conclusion already 10 years ago: twm's blog

Important : Console with parameters (With a Gui example..)

 

 

[David Schwartz 431]

If you prefer working from the command line, why not just use something that's oriented that way? I mean, you don't need a language as complex as Pascal to write simple scripts. Try playing with bash or sh or ksh or some other shell scripting language. 

 

The thing you're missing in just focusing on the command-line is not the GUI, but the entire Event-Driven ecology. That's what really sets Delphi apart from even simple Pascal. 

 

if you don't want to mess with a UI, then consider playing around with back-end services using one of the many REST frameworks that are available for that. Nobody gives two craps about Pascal today. Delphi is still alive and kicking because of the VCL, which is mainly an EVENT-DRIVEN FRAMEWORK. That's how it SUPPORTS such a rich and complex GUI environment.

 

The basic Pascal language and RTL is available to command-line apps, but nothing from the VCL or FMX frameworks are, even though that's where 99% of the VALUE lies.

[Rollo62 539]

Scripts are perhaps not powerful enough or too clumsy to use them easily.
Maybe DosCommand is a bridge between both worlds, that works for you and can bring the best of both worlds close together.

https://github.com/TurboPack/DOSCommand/blob/master/Demo/Unit4.pas

 

[Die Holländer 49]

I view console applications not just as user (prompt) programs, but also as tools for performing tasks that just don’t require a GUI.

We have numerous console applications that are often started by a task scheduler or installed as services.

These programs are hard to write with scripts alone, which is why we use Delphi and its tools and libraries. (such as FireDac, sFTP and the mORMot HTTPs web server).

These applications handle all the automated processes and tasks essential for our company. All the code can of course used in other projects for GUI or console applications.

 

 

 

[David Marcus 1]

Delphi is perfectly happy to create a console app (I have lots that I've written). In fact, if you have a Delphi GUI app, you can just change the dpr to say {$AppType console} and now your "GUI" app can use writeln; handy for debugging (if you have bugs).

[Remy Lebeau 1442]

3 hours ago, David Marcus said:

In fact, if you have a Delphi GUI app, you can just change the dpr to say {$AppType console} and now your "GUI" app can use writeln; handy for debugging (if you have bugs).

You don't need to change the AppType to use WriteLn().  A GUI app can simply call AllocConsole() or AttachConsole() and then WriteLn() will automatically work.  That being said, another way to debug would be to use OutputDebugString() instead, and then you can see the messages in the IDE's debugger, or in SysInternals DebugView when running outside of the debugger.

Edited December 22, 2024 by Remy Lebeau

[aehimself 399]

On 12/19/2024 at 12:24 AM, David Schwartz said:

The thing you're missing in just focusing on the command-line is not the GUI, but the entire Event-Driven ecology.

You can add a message pump to any thread, VCL or not. If you need window messages, you can call AllocHwnd.

Just because we are talking about console it doesn't mean these things do not work.

[David Schwartz 431]

This is quite an interesting discussion.  I worked at Intel for the first 5-1/2 years out of college (early 80's), and the software I wrote was all using their proprietary tools and dev systems. In fact, we used stuff written under contract (in the 70's) by the guy who wrote CP/M: ISIS, which was a command shell similar to CP/M and DOS; and PL/M, a language inspired by PL/1. I spent 2+ years writing tools that today would fall into the realm of DevOps.

 

ISIS had a way to run scripts called "BATCH" files; they were just text files that contained stuff you'd type into the command line in a file ending with a .BAT extensions. PL/M was a compiler that produced .COM files initially, and then we got a linker that allowed us to make .EXE files from .OBJ files the compiler produced. Given that the same guy who wrote ISIS also wrote CP/M, it was no surprise that the DOS command shell looked just like both of them. Unfortunately, over the years, it has barely evolved.

 

I started trying to write PL/M apps that did tons of stuff, but we didn't have sufficient memory to load them. So I ended up building small specialized tools that did one thing really well. I then wrote BATCH files that strung them together using some logic to do branching and stuff. I was responsible for building the code for 4 projects that combined took some 25 hours to complete. I wanted a way to have the batch files figure out if there was an error along the way and stop everything. By the time I left, I had managed to reduce a totally manual process to a fully automated process that ran on a small network of five workstations that took right around 9 hours -- while the size of the code base had nearly tripled.

 

I got caught up in their first layoff, and ended up being hired at Motorola a month later to work on their port of Unix System V Rel. 3 to the 68020. That was my introduction to Unix, C, and the magical world of command shell scripts. The most fascinating part of the various Unix shells was that they had this "pipe" thing, a vertical bar '|', that let you send the output of one command directly into another command rather than temp files. WHOA! You could build long strings of commands in just a few lines that did an AMAZING amount of work.

 

The stuff I was working on there allowed me to wrote most of my prototyping code as shell scripts. For stuff that needed to run fast, I wrote little programs in 'c' and incorporated them into my shell scripts. All told, the scripts ran amazingly fast because most of the heavy lifting was being done by executables written in 'c'.

 

It turns out that in doing my DevOps work at Intel, I had invented some 2 dozen common Unix command tools, a distributed 'make' tool, and had spec'd out several more that I hadn't gotten to yet. I was thoroughly amazed at how much stuff I had created simply out of necessity that had already been around in the Unix world for well over 5 years. 

 

The whole scripting ecosystem originally developed in Unix, as well as the parallel approach I took with my work at Intel, evolved simply because you could not build really large executable programs back then. Unix shell scripts were very lightweight, while the 'commands' (executables) were very small and efficient and could be loaded into memory quickly when needed. The two formed a symbiotic relationship that allowed you to write complex apps that ran from the command line very quickly. And they ran very fast as well. To this day, *nix shell scripts look and act just like any other commands you might want to run. You don't even know that they're shell scripts unless you try looking at them.

 

If somebody's point of reference for not wanting to work with shell scripts is only based on DOS and Windows, then I can understand their reluctance to take that approach. When I left Motorola, I bought a PC that ran DOS 3.2 then 5.0 (or 6.0?), and found the DOS command shell was about the same as the ISIS shell written in 1977 that was still being used in Intel's products at the time. It SUCKED!

 

I happened to find something called the "MKS Toolkit" around 1988 that was the first DOS port of most of Unix shell commands, plus the ksh shell. WOW! It had the same power as what I had grown accustomed to while at Moto. That's about when I was introduced to Borland's Turbo C for the first time.

 

Anyway, I think the use of shell scripts to navigate around small specialized executables has become a lost art, mostly because you can build humongous apps now that barely make a dent in the multi-gigabytes of RAM modern computing platforms have. 

Bill Gates was once famously quoted as telling an audience at a keynote at COMDEX or some other big industry conference that, "Nobody would ever need more than 640k of RAM!". When I think back on all of the different techniques software vendors employed to overcome that arbitrary limitation, it makes me shudder. 

 

I don't think it's an accident that most web servers today still run code that's nearly all interpreted. Microsoft tried to change that, and it's one reason why building server-side stuff for WIndows has always been very different than it is for Linux servers.

 

I don't have a problem with "console apps" per se -- they're just what Unix and Linux call "commands". What I have a problem with is that they're mostly designed to run in an environment as desolate as the Sahara Desert when it comes to highly-specialized tools that reduce your need to constantly re-invent the wheel, as well as the absence of a rich and versitile command shell that ties them all together. You'd be amazed at how much you can do in virtually ANY Linux environment just using sh, bash, ksh, csh, or some other shell, when combined with the rich set of 'command' tools that started life in Unix back in the 70's. Not to mention how fast and efficiently they can run.

 

Shell scripting is just as powerful today as it was back in the 80's. It's just a lost art because the hardware limitations that existed back then are no longer relevant. If you think they're slow and inefficient on a multi-core 3GHz CPU, you should have seen how fast they ran really complex applications on 20MHz 386 chips with only 512k of RAM.

 

[David Marcus 1]

1 hour ago, David Schwartz said:

the absence of a rich and versitile command shell

There is JP Software's Take Command: https://jpsoft.com/

[pmcgee 23]

On 12/12/2024 at 7:00 AM, 357mag said:

Personally, I like console programming. I was wondering if there is a reason all of my books starts you off that way. Perhaps because Delphi is a clean, fairly easy to grasp language?

There might be a marketing imperative, for new Delphi people (assuming there are some), to be able to immediately show zero-effort Windows programming, say bouncing a ball around a square ... with drag and drop components, and nice event-driven functionality.

I think that addresses one market.

However, I think as a programming enthusiast, coming to a new language like eg Swift, Haskell, Zig, or Odin .. or even C, C++, or Rust, then I want to understand the language itself and the expressions and idioms.

Every time I am trying out new ideas (to me) in Delphi, or eg recently with the Advent of Code, I am writing a console program.

I think it's the cleanest and simplest way.

Sure there are certainly things, like events and messaging, that you will probably do with a gui program ... but yeah, I like the console.  

[FPiette 386]

23 hours ago, David Schwartz said:

the DOS command shell looked just like both of them. Unfortunately, over the years, it has barely evolved

There is PowerShell. Version 1.0 was released in November 2006.

[David Schwartz 431]

On 1/1/2025 at 5:36 AM, FPiette said:

There is PowerShell. Version 1.0 was released in November 2006.

I first learned Unix shell programming in 1985, 20 years before PowerShell came out.

 

In January 2006, Apple switched all of their MacBooks and iMacs over to Intel CPUs. I bought one before PowerShell came out and never looked back. 

 

To this day, I still export some code files out of my Win VM into the Mac environment so I can run vi or some editor that lets me apply more powerful regex expressions to make complex edits that I have so internalized that it sometimes take a dozen or more tries to get them to work in Windows or even the Dephi IDE's editor. 

 

I always found writing shell scripts in *nix to be a lot of fun, while writing DOS BATCH scripts was ALWAYS painful. And because *nix command shells offer 100+ very rich 'commands' available to pipe things into, it's far more productive. 

 

I had 20 years to master that stuff before MS finally took it upon themselves to bring Windows into the 20th Century that Unix has had since the 70's -- only they waited until the 21st Century to do it. 😕

 

For example, just compare file, find, and grep in DOS / Windows with those in any *nix platform. 

 

I did a lot of DevOps stuff for several years, and even today it still relies heavily on the use of lots of scripting languages, only it's usually newer stuff, not command-shells as much.

 

I've written a number of *nix-like commands in Dephi over the years. I don't think of them as "console apps". They're just little utilities that are structured pretty much the same as most other *nix 'commands' that were typically written in c or some other scripting language. The command shell environment that was first defined in Unix still lives on today in all of the various Unix derivatives, including all Linux platforms and even the MacOS Terminal, which is simply a window that opens a command shell, like typing Run or Cmd or Command or whatever it is, into the Windows search bar. (Sorry, I have very little need to run things in the Windows Command prompt. I usually just click the little black box representing a terminal window.)

 

Back when there were no fancy GUI environments to use, all you had was a command shell. So programming books all taught that approach. It does not surprize me to see console apps being taught in Delphi programming books, other than they're devoid of any larger context, like when you're learning to create commands that run in the *nix shell environments. 

 

Shell programming in *nix is an entire ecosystem, and most of the programming tasks you learned at first involved how to extend it. Historically speaking, DOS had a horribly limited set of built-in and external commands, not to mention pipes that wrote to temp files and weren't threaded so they went from one command to the next to the next in a fully synchronous fashion. At some point, the Win Command shell was made threaded and files were saved in memory streams rather than written to disk in their entirety before being passed to the next command. 

 

Today, a lot of programming books teach how to write "console apps" because, while there might be a rich ecosystem of stuff available at the command shell level today, nobody knows about it. It's silly to learn to write 'commands' that extend the command shell's ecosystem when you don't know how to write shell scripts that leverage all of those commands.

 

So people ask, "Why do I want to write a word count (wc) console app?" Because it teaches you the basic structure of how to extend the command shell's ecosystem. Only most folks are probably unaware there even IS an entire ecosystem there. At least, there is in every Linux and *nix environment (like every Mac computer that has ever been built). 

 

 

[FPiette 386]

1 hour ago, David Schwartz said:

I first learned Unix shell programming

You write way to long posts!

If you like so much Unix shell, use Cygwin under Windows: it has it all.

[David Schwartz 431]

20 hours ago, FPiette said:

You write way to long posts!

If you like so much Unix shell, use Cygwin under Windows: it has it all.

Yes I am very wordy. Sorry.

 

I think the point you're not getting is that I do not like Windows. I only dabbled with DOS while earning a nice living developing embedded systems that used more reliable real-time kernels. I dabbled with Windows when it came out as well. I only started using it more after Delphi was introduced because it was easier to find work writing desktop apps in Delphi than embedded apps. I still like workig with Delphi, and I run it inside of a VM that runs on a Mac.

 

I only wish Embt cared enough to make a Linux target in Delphi specifically for non-GUI apps and included it in the Delphi Pro package so it could be used to build services that can be easily published on common Linux servers used today, since they outnumber Windows servers by a large margin.

 

But my point was that Unix supported very sophisticated shell scripting 20 years before MS bothered to improve the command shell beyond what it was when DOS 2.0 was released.

 

Bill Gates publicly stated many times that he thought the internet was just a passing fad, until it becamse painfully obvious that it wasn't (in terms of lost unit sales and revenues). Perhaps that was because the internet was pretty much born and raised on Unix systems and Gates didn't want to acknowledge that. He has always had a severe case of NIH Syndrome. 

 

Anyway, that's all I'll say about it.