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.