life after Windows....

In article , nospam
writes
In article , aracari
wrote:

There are many programs in Windows which are GUI and cannot be run
from a commandline but I don't see where that takes your argument.

the point is that the original mac os did not have a command line.

I call it a "Request Line", because I usually don't know what I'm doing,
and optimistically hope the OS will pick up the pieces.
--
Roger Hunt

There are many programs in Windows which are GUI and cannot be run
from a commandline but I don't see where that takes your argument.


Any Windows program can be run from a command line. If it is
a GUI program, it just pops up the necessary window.

Doug McDonald

nospam wrote:
aracari

There are many programs in Windows which are GUI and cannot be run
from a commandline but I don't see where that takes your argument.

the point is that the original mac os did not have a command line.

Not quite true. The Mac development environment (the name of which
eludes me at the moment) did indeed have a command line and it ran on
the original Mac OS.

Command line execution is not part of the OS. As with Unix and
Windows, command line processing is done by shells/programs.

--
Ray Fischer

There are many programs in Windows which are GUI and cannot be run
from a commandline but I don't see where that takes your argument.
the point is that the original mac os did not have a command line.
Not quite true. The Mac development environment (the name of which
eludes me at the moment) did indeed have a command line and it ran
on the original Mac OS.

Macintosh Programmer's Workshop, or MPW for short.

Command line execution is not part of the OS. As with Unix and
Windows, command line processing is done by shells/programs.

There was also a short-lived desk accessory for MacOS 3.2 or
thereabouts which gave you a few Unix shell commands for file
manipulation, if you really wanted that. It was never developed
into a full-featured shell but could have been if anybody had
really wanted it.

AppleScript also gave you the same sort of capability. I've had
it installed on every Mac I've ever used since it first came out
and never used it for any real work.

==== j a c k at c a m p i n . m e . u k === http://www.campin.me.uk ====
Jack Campin, 11 Third St, Newtongrange EH22 4PU, Scotland == mob 07800 739 557
CD-ROMs and free stuff: Scottish music, food intolerance, and Mac logic fonts

aracari to e-mail me wrote:
'Ray Fischer' wrote this:
nospam wrote:
aracari

There are many programs in Windows which are GUI and cannot be run
from a commandline but I don't see where that takes your argument.

the point is that the original mac os did not have a command line.

Not quite true. The Mac development environment (the name of which
eludes me at the moment) did indeed have a command line and it ran on
the original Mac OS.

And I presume the primary purpose of that was to provide a vehicle
for testing programs during development?

Not particularly. It was very much like a Unix shell (Bourne) except
that for some bizarre reason the developers changed all of the wildcard
characters. You could use it for all manner of shell-related scripts.

Command line execution is not part of the OS. As with Unix and
Windows, command line processing is done by shells/programs.

--
Ray Fischer

In article , Ray Fischer
wrote:

It was very much like a Unix shell (Bourne) except
that for some bizarre reason the developers changed all of the wildcard
characters. You could use it for all manner of shell-related scripts.

yea, that's true. it was almost the same, but with totally different
syntax.

some of the cooler features were that you could highlight some text and
hit enter and it would execute. you didn't need to retype anything.

another was that a window was a live view of a file and if you wrote to
the file, you saw the contents change as it happened.

In article , aracari
wrote:

the point is that the original mac os did not have a command line.

Fine, I have no problem with that.
Nevertheless, the GUI will have been created after writing the
program function code itself (or normally would be).

there's no reason for one to be before the other. it all depends on
what the app does and how the developers wish to implement it.

In article , Ray Fischer
wrote:

the point is that the original mac os did not have a command line.

Not quite true.

it's exactly true.

The Mac development environment (the name of which
eludes me at the moment) did indeed have a command line and it ran on
the original Mac OS.

that's macintosh programmer's workshop, or mpw, and it offered a very
slick command line, but only when it was running. it implemented it on
top of the gui, not by exposing hidden functionality as with os x and
terminal. quit mpw and no more command line. it also came out a few
years after the mac did.

Command line execution is not part of the OS. As with Unix and
Windows, command line processing is done by shells/programs.

not internal to the original mac os.

In article , aracari
wrote:

Not quite true. The Mac development environment (the name of which
eludes me at the moment) did indeed have a command line and it ran on
the original Mac OS.

And I presume the primary purpose of that was to provide a vehicle
for testing programs during development?

nope. mpw was a full fledged development environment that included c,
c++, pascal and assembly (other languages could be added by third
parties, such as fortran) as well as a multi-window text editor and a
source level debugger. it could also be scripted and was suitable for
larger software projects.

and as i mentioned elsewhere, it came later, about 3 years after the
mac first shipped (there were other ways to write software before
that).

In article , aracari
wrote:

there's no reason for one to be before the other. it all depends on
what the app does and how the developers wish to implement it.

The normal cycle is to design the program you want to create
and then set about writing/testing it. That is often an iterative
process which might take some time.
When you've finished and you've got the program doing exactly
what you want, you might then create a GUI for it.

that's the difference. well designed gui software takes into account
the ui *and* the underlying functionality at the same time. it's not
added on later.

This will include deciding what program functions you want the
user to have access to. Those which are not made available through
the GUI can often be accessed on the commandline used to start
the program.

ugh. hidden features are obnoxious. if it's important enough to
implement, why hide it from the user?

A programmer who creates the GUI first is likely to find himself
going back and forth changing it to reflect what he finally writes
the program to do. It will usually take more time and cost more
money. Bear in mind that we are sometimes talking about large
complex programs.

not necessarily. and the opposite is true, a programmer who designs
the app and later layers on a gui might find that a better gui is now
impossible, because to do so would require redesigning the command line
underpinnings.