TL;DR:
It's about the viewpoint these functions were designed.
- Command line is all about interaction
- Programming is about deferred execution
As a result command/statement names were picked to reflect either viewpoint
The long read:
The function is unrelated to echoing, which is about reflecting input (possibly modified) to output
But that's exactly the core function. Imagine yourself standing in a rift with a great echo. Whatever you shout comes back to you. And much like the echo on a lake, it is someone else 'speaking' here: the machine, not you. Type it at the command line and it, well, commands the machine to 'echo' what you 'said'.
for example where a teletype driver operating in full-duplex mode will echo input characters to have them appear on the output.
Teleprinters usually operated in local echo mode(*1). Noone in his right mind would use remote echo and wait for each character to be returned. Keep in mind, a standard teleprinter (TTY) like the ASR-33 (*2) was at maximum capable of 10 characters per second (*3). So even with a zero delay computer (*4), that's a 0.2 second communication delay between typing a character and receiving the character to be printed, plus whatever time the mechanics need to punch the type (*5).
Remote echo only became a thing when faster attachment speeds became possible with affordable glass-TTY appeared in the early 1970s. And even then it is really only acceptable for small machines with a single or a few users. There is a reason mainframes with high throughput and a large number of concurrent users went along the way of local editing and block orientated communication: Responsiveness. What's fine with just a few users is unbearable with hundreds or thousands.
A command line typed on an early setups was thus not produced by a computer mirroring what you typed, but local echo. ECHO as a command made the machine echo the input - in contrast to local echo - so you could see exactly what has been received. Showing possible command line modification was a plus as well.
I suspect we've all got used to this and no longer consider it to be an abnormal use of the word.
I fail to see the 'abnormal' part. Well, unless you got a very specific view what a computer is and how it works in relation to yourself and commands given. These are not 'god-given' points of view, but have evolved over time - and still do.
In most major programming languages, the function to output some text has a name like 'print' or 'display'.
Unlike print, echo clearly refers to returning it to the device that has issued the command (*6), while print implies a dedication to some printer, local or remote. DISPLAY in contrast is a very generalized view.
PRINT and DISPLAY can in fact be traced back to two influential languages: FORTRAN used PRINT, while COBOL went for DISPLAY. But even these two mighty forefathers didn't keep others from using different statements - like Pascal's WRITE(LN). The use of different statements in programming languages for the same working does quite well reflect that there is no one size fits all solution, but different views at work.
The most important point here might be the question referring to programming languages. Programming has an inherently different view about how to interact than a command line. When programming it's about setting an explicit sequence of actions for the machine to do at a way later point.
- Programming languages were made with this deferred execution in mind
Print, display, write, etc. were chosen within the context of programming
Command line in contrast is about direct interaction. Everything typed gets done right away.
- Command line was developed with this viewpoint in mind.
ECHO was picked with teleprinter-/terminal-operation as template
Having direct commands stacked in a batch file doesn't change that part. In fact, classic BATCH languages (like JCL) do not contain statement to print like ECHO does. Batch doesn't have a need for it. Modern batch, as command line entries from a file, wasn't always there, but is a later development.
As so often, things that are believed to be fundamental aren't as much basic when going back.
It might be noteworthy to compare with another common command: TYPE like for example used by MS-DOS. It is used to 'type out' some input (file). Noone really expects the computer to type it - he got no fingers to hit the typewriter keys - but output on a teleprinter looked much like some ghost, like the ghost in the machine, would be sitting there and type the file.
For TYPE the same argument could be made, that PRINT would be way more appropriate, isn't it?
It comes all down to what analogy the creators could find - and what idea of the machine they fostered. Like so many commands it has its origin at a time when people where still struggling to find a canonical about how to view interaction.
*1 - The issue here is local vs. remote echo, not full or half duplex, as that only describes how the line is shared, not how echo is handled.
*2 - Unix development started on a PDP-7 with an ASR-33 at 10 cps as 'fast' terminal.
*3 - While capable of 10 characters per second, standard setting was in most cases 6 char/s.
*4 - On a computer using fancy stuff like 'drivers' this add quite more delay. Multics, the paragon for Unix was quite remarkable in being sluggish due the modular design. Something great today, but over the edge back then, slowing down even a fast machine like the GE mainframe.
*5 - Try telling that to any of today's gamers already writing negative critics about screens and mice with a few milliseconds delay :) - and while we may think of funny here, I experience on a regular base that such delays are really inconceivable to them. It's like telling someone that starting an early car took anything between 10 minutes and an hour - but so it was.
*6 - Scripting hides this relationship a bit, doesn't it?
