[Tutor] command line

[alan.gauld@bt.com]

> >hardly ever use the "toys". There's nothing so productive
> >as just typing the code in and it works first time! Many
> >experienced pros reach that level of quality after 10 years
> >or so...
> 
> Depends what you include in the "toy" category.

Granted, I really mean things like parameter displays, 
class browsers (for the core libraries, they are useful 
for user defined classes), graphical debuggers - "a sop 
to those who don't understand their own code" - to quote 
one seasoned hack...

> changes (ala make).  

make is most definitely not one of the "toys" but GUI 
project builders could be... depeding on their power. 
Some of these are now getting to the stage of being useful.

> Templates and dialog box driven
> builders of various types also save time.

Depends, If the GUI desitgners are non programmers and 
design the GUI in Visio (quite common) then the coders 
will often just hack together a resource file. The 
biggest Unix project I ever worked on the GUI team 
all used VT200 terminals and shared a single X display 
for testing! I definitely wouldn't recommend that!

> Helpful and useful:  a visual class browser, 

Hmm, sometimes yes. Mostly I find them overrated if 
you know the library well.

> code rollups,

??? whats one of them? Do you mean folding?
If so yes I agree that's useful, but with ctags still 
very much a luxury.

> and, of course, a way to develop GUI forms by simply
> dragging and dropping widgets from a palette ala VB

But that implies you are designing 'on the fly'. Fine 
for small projects with maybe a dozen forms but once 
you get into big projects(Photoshop say) then the design 
will tend to be on paper or in visio etc. Or maybe 
in VB as a demonstrator but be recoded by hand 
elsewhere...

> want to go back to the text-only tools of my past.  But I
> can understand sticking with what you know best.

On mainframes text only is all you get very often but 
I agree GUI tools have their place. However on Unix most
of the traditionally GUI tools are available as text 
and thats what gets used. I stress I'm talking about 
hard core coders here. I certainly am not in that 
category and I've been programming on and off for 25 
years. I mean the contractors who specialise in maybe 
3 or 4 languages on 2 or 3 OS's. They are paid to 
produce large volumes of code to a predetermined design. 
They have no need for design as you go type tools - they 
just sit down and churn out a thousand lines of 
working C/Java/COBOL per day.

> The idea that a *nix environment is itself an IDE makes
> plenty of sense 

Yes, Its the biggest thing about Unix, its a software 
engineering foundry that just happens to double as 
a decent OS :-)

> I also appreciate that *nix gives you more high powered
> tools at an affordable price 

Its not just the freeness of Linux etc. I was using 
Solaris(SunOS) long before Linux etc existed - I even 
tried Minix for a while! But its the integration and breadth 
of the tools. PC IDEs have only recently started shipping 
with profilers, they still don't do test coverage. You 
can buy the addons but often they don't integrate with 
each other - you can debug this build but not profile it...

> But it's also true that the *nix OS is a platform for
> expensive, proprietary, closed source software development
> IDEs and applications.  

Sure is. The IDEs I mentioned earlier all cost >$1000 per seat.
The test tool we use costs over $5000 per seat and the CASE 
tool is higher still. But these are production strength 
tools for serious use. When a projects development budget 
exceeds 10 million dollars (say) the tool costs become a 
minor issue! An hours downtime of the server will likely 
cost more!

> is, of course, not true.  Yet it seems some evangelists
> want us to believe that only Windows users ever run closed
> source, expensive stuff.

And that is certainly a myth. Unix has lots of closed source 
software, mostly good quality but there are some stinkers 
in there too.

> What I really like about Python, on all the platforms it
> supports, is that batteries are included.  

Absolutely. It is a great prototyping language, great 
for experimenting and great for scripting. For occasional 
users like me (I only program for a few hours each week) 
its perfect. If you want to take an idea to production 
level you can do that too. It only runs out of steam on 
the very biggest of projects or on the highest performance 
cases - Once you know you need that performance thens a 
good time to wheel in the hard core C++ gyys to rewrite 
the critical bits - and python is the pseudo code :-)

>  > This is true and is where Python development differs from
>  > traditional style coding.
> 
> Some languages have a builtin shell mode, and take advantage
> of it, whereas others don't.  APL, Logo, Scheme, many Lisps,
> Xbase, MATLAB, Mathematica, ISETL and Python are very shell-

Yeah but only LISP and Python out of that list are things 
I'd consider writing a big application in. And even Lisp 
has some problems in that area.

Smalltalk is the other one. The Smalltalk transcript window 
and class browser IDE are very similar in feel to a python 
prompt/editor environment IMHO.

Alan G