Hello

It's Friday and... well...

Two things about Tcl going through my mind this week, a nice anecdote
and a
eyebrow-rising thing on Wikipedia:

Anecdote:
Until three months ago I worked in a scientific institue where I wrote
much
software in Tcl, especially a big Build and Report System, some tools
for
automatic checking of coding style and other things. Tcl had a bad
reputation
there (not because of me... they dropped Tcl before I started there in
favour of
Joy, then JavaScript and now Python) and besides me, there was only
one
co-worker who appearantly writes some small Tcl-Scripts to support
other
researchers in their work. To get completely rid of Tcl, they even
started to
reimplement all things, I wrote in Tcl in Python just to have it in a
language,
that most of them know (which is a good decision on the one hand, but
on the
other hand, I think, it would be better to simply learn Tcl ;-), which
made me a
little bit sad.

Now there is a new collegue who has to maintain some of the things I
wrote. Comming from Perl he wasn't exactly enthusiastic when he heard,
that he
must maintain my old code in such an obscure language..

Two weeks ago, I got mail from him. He's just studying a complex
system of
scripts that are used for a sandboxed build system for source code
which comes
from external untrusted source and must be compiled and tested. Of
course it's
written in Tcl (and some bash-Scripting). He told me, that although he
has never
looked at Tcl before, he was amazed how simple and well documented the
code was,
and how he understood almost immediately, what it means. Tcl seemed to
be
crystal clear to him and now he *is* very enthusiastic about it, and
learns
programming in Tcl.

What's my point here? Tcl speaks for itself, you just have to look at
it... I
was really touched by that.


Wikipedia:

The other day I was just browsing through the articles about different
programming languages, programming paradigms and related stuff on
wikipedia just
for fun. I found the "Categorical list of programming languages"
(http://en.wikipedia.org/wiki/
Categorical_list_of_programming_languages), where
languages are sorted by paradigms or categories. Tcl (and XOTcl) can
be found
eight times in the list in different categories, which is pretty much,
I
think. But reading through the list and the descriptions of what the
categories
mean, I found that Tcl is missing in many of the categories, although
it clearly
should be there:

- "Command line interface languages" for batch processing and job
control. Tcl
  is perfect for that, especially if expect is used.
- "Interactive mode languages" where you can programm interactively
seeing
  immediate results. Python is listed (for good reason), but not
  Tcl... Especially using wish for interactive GUI-development is a
killer-app
  from my point of view...
- "Interpreted languages" at least early Tcl was pure interpreted and
is also
  today if you use it interactively or if you do not use [proc]s.
- "Little languages" at least in the sense of the word, Tcl definitely
is small,
  containing only its few syntax rules.
- "Metaprogramming languages" the desription of that category seems to
me to be
  one of the most used programming styles in Tcl...

Am I missing some categories or wrong about the five above?

Besides: Perl is not listed in the category of "Esoteric languages".
Why is
that? ;-)

Regards
Stephan

On Jun 22, 12:40 pm, skuha...@web.de wrote:
> Hello
>
> It's Friday and... well...
>
> Two things about Tcl going through my mind this week, a nice anecdote
> and a
> eyebrow-rising thing on Wikipedia:
>

Right now I would say that 90% of the software development projects
run by large commercial organizations are written in either .Net or
Java. This is mainly because those languages are fully integrated with
the .Net and Java application servers that provide the infrastructure
for large scale enterprise applications clustered across multiple
servers  The other languages have been relegated to niche markets i.e
small non critical single server applications and system
administration.

In ten years time it is quite likely that development in languages
such as Tcl, Python, Perl, Ruby etc will have ceased as everyone will
be coding in Groovy or Java:).

On Jun 22, 8:39 am, Patrick Finnegan <finnegan.patr...@gmail.com>
wrote:
> On Jun 22, 12:40 pm, skuha...@web.de wrote:
>
> > Hello
>
> > It's Friday and... well...
>
> > Two things about Tcl going through my mind this week, a nice anecdote
> > and a
> > eyebrow-rising thing on Wikipedia:
>
> Right now I would say that 90% of the software development projects
> run by large commercial organizations are written in either .Net or
> Java. This is mainly because those languages are fully integrated with
> the .Net and Java application servers that provide the infrastructure
> for large scale enterprise applications clustered across multiple
> servers  The other languages have been relegated to niche markets i.e
> small non critical single server applications and system
> administration.
>
> In ten years time it is quite likely that development in languages
> such as Tcl, Python, Perl, Ruby etc will have ceased as everyone will
> be coding in Groovy or Java:).


The company I contract for still codes a lot of their stuff on a
mainframe in Cobol.   "Big business" is always the slowest and last to
adopt better technology, but they, like everyone, will be forced to
change eventually.  Why do you think they bought our software?
They're replacing their old mainframe system.

Java is big and clunky, and while they may teach it as the be all end
all of languages now, they did the same with Pascal 15 years ago.
Anyone writing some Pascal these days?  Anyone?  I'm not saying Java
doesn't have its place, but it's pretty well worthless in a lot of
arenas.

The smart people have already moved on from Java and are heading
towards Python and Ruby.  Not Tcl, of course, because it has no object
system, and it's old and a silly language.  Whatever.  It doesn't
matter.  You'll find that the edge companies are starting to ditch
Java, while the "big business" just uses what the advertisers tell
them to use.

Ultimately, if you're given a project, and one language will take you
20 hours to write said program, and the other language will take you
80 hours to write the same, exact program, which one would you rather
code in?  In the example, guess which is Java and which is <insert
dynamic language of choice here>.  Computers get faster and cheaper
every year.  Programmers don't.

D

At 2007-06-22 07:40AM, "skuhagen@web.de" wrote:
>  think. But reading through the list and the descriptions of what the
>  categories
>  mean, I found that Tcl is missing in many of the categories, although
>  it clearly
>  should be there:

The wonderful thing about wikis is that anyone can edit them (hint,
hint).


-- 
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry

On Jun 22, 3:26 pm, Damon Courtney <d...@installjammer.com> wrote:
> On Jun 22, 8:39 am, Patrick Finnegan <finnegan.patr...@gmail.com>
> wrote:
>
>
>
>
> The smart people have already moved on from Java and are heading
> towards Python and Ruby.  Not Tcl, of course, because it has no object
> system, and it's old and a silly language.  Whatever.  It doesn't
> matter.  You'll find that the edge companies are starting to ditch
> Java, while the "big business" just uses what the advertisers tell
> them to use.
>
> Ultimately, if you're given a project, and one language will take you
> 20 hours to write said program, and the other language will take you
> 80 hours to write the same, exact program, which one would you rather
> code in?  In the example, guess which is Java and which is <insert
> dynamic language of choice here>.  Computers get faster and cheaper
> every year.  Programmers don't.
>
> D

Tcl is a great language but it has no traction in the corporate
world.  Java programmers will move to Groovy rather than Python or
Ruby.      I see people starting out with Groovey and progressing to
Java for more complex performant applications.

In article <1182529396.126408.290450@u2g2000hsc.googlegroups.com>,
Patrick Finnegan  <finnegan.patrick@gmail.com> wrote:
			.
			.
			.
>Tcl is a great language but it has no traction in the corporate
>world.  Java programmers will move to Groovy rather than Python or
>Ruby.      I see people starting out with Groovey and progressing to
>Java for more complex performant applications.
>
>

Heck, I see organizations take working applications coded in
Tcl, and rewrite them in Java to gain performance.  In fact
they *lose* performance and functionality, and the rewrite
takes more time than the original development, but those
weren't the intentions, so ...

Damon Courtney schrieb:

[snip]

> 
> Ultimately, if you're given a project, and one language will take you
> 20 hours to write said program, and the other language will take you
> 80 hours to write the same, exact program, which one would you rather
> code in?  In the example, guess which is Java and which is <insert
> dynamic language of choice here>.  Computers get faster and cheaper
> every year.  Programmers don't.
> 
> D
> 

Big companies work on a different mind-set:
You got xxx people in your department, all of them need to do something
in order to make their managers look busy... from a financial point of 
view xxx people cost *nothing*.
As a manager the best way (to promotion) is to avoid software reuse -- 
inside and outside of your company ---maybe a little within the project 
itself--- -- , and use the same coding system everybody in the 
food-chain agrees with.

Ever followed the acm studies about average software-development 
efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years!

-roger

On Jun 22, 9:14 pm, cla...@lairds.us (Cameron Laird) wrote:
> In article <1182529396.126408.290...@u2g2000hsc.googlegroups.com>,
> Patrick Finnegan  <finnegan.patr...@gmail.com> wrote:
>                         .
>                         .
>                         .
>
> >Tcl is a great language but it has no traction in the corporate
> >world.  Java programmers will move to Groovy rather than Python or
> >Ruby.      I see people starting out with Groovey and progressing to
> >Java for more complex performant applications.
>
> Heck, I see organizations take working applications coded in
> Tcl, and rewrite them in Java to gain performance.  In fact
> they *lose* performance and functionality, and the rewrite
> takes more time than the original development, but those
> weren't the intentions, so ...


Totally agree.  But the Architects want all applications to run on the
same application server platform.  Very few companies mix and
match .Net and Java apps let alone Java, Perl, Tcl etc.  I know of a
large ISP that is moving all it's Apps from Perl to Java in order to
take advantage of the Java application server platform, Java tooling
and development frameworks like Spring and Hibernate.  It may be
faster to develop in Perl but Perl does not have a clear design
methodology or s standard enterprise development specification.

Personally I think Tcl is in a better position than Perl because Tcl
is recognised in the industry as a great tool for writing cross
platform GUI interfaces and there are not many choices out there for
those who want to write cross platform desktop apps.

On Jun 22, 6:40 am, skuha...@web.de wrote:
> Hello
>
> It's Friday and... well...
>
> Two things about Tcl going through my mind this week, a nice anecdote
> and a
> eyebrow-rising thing on Wikipedia:
>
> Anecdote:
> Until three months ago I worked in a scientific institue where I wrote
> much
> software in Tcl, especially a big Build and Report System, some tools
> for
> automatic checking of coding style and other things. Tcl had a bad
> reputation
> there (not because of me... they dropped Tcl before I started there in
> favour of
> Joy, then JavaScript and now Python) and besides me, there was only
> one
> co-worker who appearantly writes some small Tcl-Scripts to support
> other
> researchers in their work. To get completely rid of Tcl, they even
> started to
> reimplement all things, I wrote in Tcl in Python just to have it in a
> language,
> that most of them know (which is a good decision on the one hand, but
> on the
> other hand, I think, it would be better to simply learn Tcl ;-), which
> made me a
> little bit sad.
>
> Now there is a new collegue who has to maintain some of the things I
> wrote. Comming from Perl he wasn't exactly enthusiastic when he heard,
> that he
> must maintain my old code in such an obscure language..
>
> Two weeks ago, I got mail from him. He's just studying a complex
> system of
> scripts that are used for a sandboxed build system for source code
> which comes
> from external untrusted source and must be compiled and tested. Of
> course it's
> written in Tcl (and some bash-Scripting). He told me, that although he
> has never
> looked at Tcl before, he was amazed how simple and well documented the
> code was,
> and how he understood almost immediately, what it means. Tcl seemed to
> be
> crystal clear to him and now he *is* very enthusiastic about it, and
> learns
> programming in Tcl.
>
> What's my point here? Tcl speaks for itself, you just have to look at
> it... I
> was really touched by that.
>
> Wikipedia:
>
> The other day I was just browsing through the articles about different
> programming languages, programming paradigms and related stuff on
> wikipedia just
> for fun. I found the "Categorical list of programming languages"
> (http://en.wikipedia.org/wiki/
> Categorical_list_of_programming_languages), where
> languages are sorted by paradigms or categories. Tcl (and XOTcl) can
> be found
> eight times in the list in different categories, which is pretty much,
> I
> think. But reading through the list and the descriptions of what the
> categories
> mean, I found that Tcl is missing in many of the categories, although
> it clearly
> should be there:
>
> - "Command line interface languages" for batch processing and job
> control. Tcl
>   is perfect for that, especially if expect is used.
> - "Interactive mode languages" where you can programm interactively
> seeing
>   immediate results. Python is listed (for good reason), but not
>   Tcl... Especially using wish for interactive GUI-development is a
> killer-app
>   from my point of view...
> - "Interpreted languages" at least early Tcl was pure interpreted and
> is also
>   today if you use it interactively or if you do not use [proc]s.
> - "Little languages" at least in the sense of the word, Tcl definitely
> is small,
>   containing only its few syntax rules.
> - "Metaprogramming languages" the desription of that category seems to
> me to be
>   one of the most used programming styles in Tcl...
>
> Am I missing some categories or wrong about the five above?
>
> Besides: Perl is not listed in the category of "Esoteric languages".
> Why is
> that? ;-)
>
> Regards
> Stephan

   I had the same experience at one place I worked. The product was
moving from Solaris 8 to Solaris 10 and they had lost the source to
the antiquated perl interpreter that they were using so they had to
upgrade a bunch of scripts to use what was being provided by Solaris
10. It was my job to do this but  given perl's syntax and strange
variable usage not a whole lot was apparent as to how the scripts were
doing their job. I even went to the authors to explain to me what
certain lines mean't and they could not tell me. If the original
authors could not read their own code what chance did I have. The
purpose of each perl script was known; so I  rewrote  all the scripts
in Tcl in almost no time at all. Don't know why but this really bent a
few noses. "Why didnt you do it in Perl?" was the constant question. I
would tell them for ease of maintenance. You can see what's going on
without having to constantly reference a text book. I would tell them
other reasons but
their mind was made up the instant they found out it was Tcl. If they
don't see a language mentioned in their magazines every time they pick
one up it can't be any good.   Tcl does not have the PR machine that
Java, .Net and others have and for that reason alone it suffers.

Carl

Hello

> The smart people have already moved on from Java and are heading
> towards Python and Ruby.  Not Tcl, of course, because it has no object
> system, and it's old and a silly language.  Whatever.  It doesn't
> matter.

Reminds of a similar conversation some days ago. Someone came in,
saying something like: "Ah you guys, programming tickle-tackle, ha
ha... Did that ten years ago, very primitive language, doesn't even
have an object system. I'm programming Python now!"
But some simple questions revealed that he doesn't even really know,
what object orientation is, and where the benefits really are (if
any). So it really doesn't matter, what the language really is, as
long as you have the right buzzwords to promote it. I'm sure, people
like him would switch immediately to Tcl, if they never have heard
about it before and would come with the right buzzwords...

But theres hope. As I wrote in my OP, the former colleague of mine
switched to Tcl just because he read some real Tcl source (not the two-
line-examples from the ads of hyped languages...) and loved it. I
don't think, there are many languages out there, who have this kind of
quality...

Regards
Stephan

Glenn Jackman wrote:
> The wonderful thing about wikis is that anyone can edit them (hint,
> hint).

Yeah, right, but I'm no native english speaker/writer and I have some
problems simply to botch someone others article.

Stephan

Cameron Laird wrote:

> >Tcl is a great language but it has no traction in the corporate
> >world.  Java programmers will move to Groovy rather than Python or
> >Ruby.      I see people starting out with Groovey and progressing to
> >Java for more complex performant applications.
>
> Heck, I see organizations take working applications coded in
> Tcl, and rewrite them in Java to gain performance.  In fact
> they *lose* performance and functionality, and the rewrite
> takes more time than the original development, but those
> weren't the intentions, so ...

The problem is, who works with a language and who decides, which one
is used... Although where I'm currently working, we use Tcl for the
whole project, except for some C-Extensions for Tcl, you can see, that
many people are uncomfortable using it. Not that they know anything
better really (which one can see after 30 Seconds of asking the right
questions), but they don't hear about Tcl in the news, so it must be
useless. But the nice thing is, we get things really done here. The
Tcl parts of the software move really fast towards completion and
although they never would admit it in the public (because you get
instant bashed for not telling the same about Java/Python whatever
instead), people here are kind of impressed of Tcls power.

Regards
Stephan

Arndt Roger Schneider wrote:

> Big companies work on a different mind-set:
> You got xxx people in your department, all of them need to do something
> in order to make their managers look busy... from a financial point of
> view xxx people cost *nothing*.

I don't think so. Otherwise there would be no good argument to fire
hundreds or thousands of people ("workers") in big companies every
time they change some of their organisation.

> As a manager the best way (to promotion) is to avoid software reuse --
> inside and outside of your company ---maybe a little within the project
> itself--- -- , and use the same coding system everybody in the
> food-chain agrees with.

This I totally agree with: No software reuse! is the secret slogan,
and it's so brainless, that it sometimes make me laugh.

> Ever followed the acm studies about average software-development
> efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years!

Are these numbers available somewhere? I find that really interesting.

Stephan

Bezoar wrote:
> On Jun 22, 6:40 am, skuha...@web.de wrote:

> I had the same experience at one place I worked. The product was
> moving from Solaris 8 to Solaris 10 and they had lost the source to
> the antiquated perl interpreter

Lost their interpreter...? Cool... "I lost my interpreter, I don't
know what anything means anymore..."

> authors could not read their own code what chance did I have. The
> purpose of each perl script was known; so I  rewrote  all the scripts
> in Tcl in almost no time at all. Don't know why but this really bent a
> few noses. "Why didnt you do it in Perl?" was the constant question. I
> would tell them for ease of maintenance. You can see what's going on
> without having to constantly reference a text book. I would tell them
> other reasons but
> their mind was made up the instant they found out it was Tcl.

Exactly. It doesn't matter how efficient it is, or if it simply works
or anything else, as long it not the "right" language. That you ported
from Perl to Tcl is a funny coincidence, since in my story the
programmer came from Perl and as he started working there, he told
about the coolness and power of Perl. I'm having no problem with that
(I love to look and learn about other languages and other ideas about
programming), but now he learning Tcl. But before he really looked at
Tcl, there would have been no chance to convince him, that its a
really good language. "Tcl...? Outdated crap... Pajaverlython? Hype,
really cool, must use!"

Regards
Stephan

> Personally I think Tcl is in a better position than Perl because Tcl
> is recognised in the industry as a great tool for writing cross
> platform GUI interfaces and there are not many choices out there for
> those who want to write cross platform desktop apps.

No one cares about Tcl vs Perl these days.  The 'hot' languages are
Python and Ruby, with some interest growing in things like Erlang.
Java really isn't that hot, but because there are massive amounts of
it deployed, it will be with us for years to come.

Also, I think that while...yes, there is certainly still a (large)
market for cross platform desktop applications, a huge number of
people prefer the economics of web programming:

You still have cross platform issues, but they're the same ones
everyone else has, and are limited to more or less three browsers.

You can update your applications immediately - no deployment hassles!
That's really a big win for small shops who don't want to dedicate
lots of support time to N versions of something on N platforms.

If we conclude that Tcl doesn't have any major technical defects, (it
does have a few, but so do most of the other scripting languages),
then the only conclusion that we can really come to is that it's a
marketing issue, and that we as a community have done a terrible job
at that.  Some day I think I will attempt to write a "chapter" for
this book on Tcl (well, not really for that book, but inspired by it):

http://www.squeezedbooks.com/book/show/10/in-search-of-stupidity-over-twenty-years-of-high-tech-marketing-disasters-second-edition

In article <1182757493.863041.164710@k79g2000hse.googlegroups.com>,
davidnwelton@gmail.com <davidnwelton@gmail.com> wrote:
			.
			.
			.
>Also, I think that while...yes, there is certainly still a (large)
>market for cross platform desktop applications, a huge number of
>people prefer the economics of web programming:
>
>You still have cross platform issues, but they're the same ones
>everyone else has, and are limited to more or less three browsers.
>
>You can update your applications immediately - no deployment hassles!
>That's really a big win for small shops who don't want to dedicate
>lots of support time to N versions of something on N platforms.
			.
			.
			.
AND the licensing complexities are arguably an order of
magnitude less.  It remains *very* common for shrink-wrapped
proprietary products to demand more time/hassle/education/...
in licensing than functionality.  Web applications have
authentication and accounting that's rational, by comparison.

Stephan Kuhagen wrote:
> Yeah, right, but I'm no native english speaker/writer and I have some
> problems simply to botch someone others article.

But you can just add text and let others fix up the language bugs.
Wikis are great like that.

Donal.

Cameron Laird wrote:
> Web applications have
> authentication and accounting that's rational, by comparison.

On the other hand, web application security is a subject that ought to
scare you. The scariest part is cross-site scripting, which some
people tout as a benefit (calling it "mashups").

Donal.

On Jun 25, 3:44 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
wrote:

> No one cares about Tcl vs Perl these days.

Well, as far as I can tell, "no one" (except, of course, those
programming in them) cares about Tcl OR Perl these days, let alone
"vs"...

> The 'hot' languages are
> Python and Ruby, with some interest growing in things like Erlang.

Weird - I seldom, if ever, hear anyone mention python (well, except
here on comp.lang.tcl, where people seem obsessed with it) and have
never (again, except here) have I heard anyone mention Erlang. I do
have developers stop by to ask about Ruby. I seldom, however, see
references to any of these in newsletters or magazine front cover
stories, etc. I _do_ regularly see people writing about Java, Groovey,
PHP, and .Net...


>
> If we conclude that Tcl doesn't have any major technical defects, (it
> does have a few, but so do most of the other scripting languages),
> then the only conclusion that we can really come to is that it's a
> marketing issue, and that we as a community have done a terrible job
> at that.  Some day I think I will attempt to write a "chapter" for
> this book on Tcl (well, not really for that book, but inspired by it):

How much "marketing" do you see concerning COBOL, FORTRAN, C, and
assembly languages? And yet, thousands, if not millions, of developers
every day are working on programs in those languages. What has
happened is that the masses of writers have moved on to "the next
great thing" while the current great languages continue to be used
without complaint.

The primary complaint that I know that I see is a general issue which
cuts across ALL dynamic languages - a prejudice against "scripting
languages" as not being "real programming languages" and scripts not
being "real programs".

Larry W. Virden wrote:
> Weird - I seldom, if ever, hear anyone mention python (well, except
> here on comp.lang.tcl, where people seem obsessed with it) and have
> never (again, except here) have I heard anyone mention Erlang. I do
> have developers stop by to ask about Ruby. I seldom, however, see
> references to any of these in newsletters or magazine front cover
> stories, etc. I _do_ regularly see people writing about Java, Groovey,
> PHP, and .Net...

FWIW, for new development I see mainly Java and C# interest, with some
Ruby but not that much. (The Ruby fans are regarded as something like
heretics, but then a lot of what we do doesn't map nicely to the Rails
environment and that's the biggest thing in Ruby's favour.) There's
also lots of "legacy support", which round here means mainly Fortran,
C and C++, plus some Perl. Tcl's very much a minority pursuit (along
with many other languages too to be fair, including Python!)

Most of the really advanced development I see takes place at levels of
abstraction where conventional programming languages aren't used. I'm
not sure that this is a long-term trend though; I suspect it's really
a retrograde step that will be reversed in the future as people
rediscover the expressiveness of languages.

Donal.

On Jun 25, 2:26 pm, "Larry W. Virden" <lvir...@gmail.com> wrote:
> On Jun 25, 3:44 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
> wrote:
>
> > No one cares about Tcl vs Perl these days.
>
> Well, as far as I can tell, "no one" (except, of course, those
> programming in them) cares about Tcl OR Perl these days, let alone
> "vs"...

Precisely.  Someone commented on some supposed advantage of Tcl over
Perl, which is, at this point, not the right battle to be fighting.

> > The 'hot' languages are
> > Python and Ruby, with some interest growing in things like Erlang.
>
> Weird - I seldom, if ever, hear anyone mention python (well, except
> here on comp.lang.tcl, where people seem obsessed with it) and have
> never (again, except here) have I heard anyone mention Erlang. I do
> have developers stop by to ask about Ruby. I seldom, however, see
> references to any of these in newsletters or magazine front cover
> stories, etc. I _do_ regularly see people writing about Java, Groovey,
> PHP, and .Net...

Java, .Net and PHP are languages that are already big (for that
matter, Python isn't doing so bad either - Google uses it...).  What
I'm talking about are the languages with buzz and hype going for
them.  Ruby has this in spades.  When you compare it to Tcl, it does
ok - it's got some nice things, but it's not like it's an order of
magnitude better:

http://journal.dedasys.com/articles/2006/03/06/ruby-vs-tcl

> > If we conclude that Tcl doesn't have any major technical defects, (it
> > does have a few, but so do most of the other scripting languages),
> > then the only conclusion that we can really come to is that it's a
> > marketing issue, and that we as a community have done a terrible job
> > at that.  Some day I think I will attempt to write a "chapter" for
> > this book on Tcl (well, not really for that book, but inspired by it):
>
> How much "marketing" do you see concerning COBOL, FORTRAN, C, and
> assembly languages?

What those have going for them are the lock-in effects associated with
the switching costs of massive deployments of production systems,
which are pretty much insurmountable for many systems and companies.
That's not, however, the same thing as what people are using to write
new code with.

> The primary complaint that I know that I see is a general issue which
> cuts across ALL dynamic languages - a prejudice against "scripting
> languages" as not being "real programming languages" and scripts not
> being "real programs".

I guess... in some environments.  Perhaps they're ripe to be beaten by
a small, agile startup that doesn't care about fossilized attitudes.
Like Damon said, the economics of more productive languages do count,
in the end, once you've factored out other things.

skuhagen@web.de wrote:

> 
> What's my point here? Tcl speaks for itself, you just have to look at
> it... I
> was really touched by that.

This is one reason I am not terribly concerned with Tcl (or Tk) from a 
marketing standpoint. There will always be something more fashionable. I 
develop desktop GUI apps on Mac OS X, and I get nothing but grief from 
other Mac developers who consider Tk ugly and Tcl deficient because it 
doesn't have bindings to the flagship Apple framework, Cocoa. (Other 
scripting langauges, such as Perl, Ruby and Python, do.) The snobbery 
gets quite out of hand sometimes; the old stereotypes about the Mac 
being more about eye candy and aesthetics than utility do have a nugget 
of truth to them. :-)

I don't think Tcl is the only language one should use, of course. I've 
added Python as a second main language because it does some things that 
Tcl simply can't do (such as writing an sftp client, which is on my list 
of projects). Python's large standard library make it a bit more robust 
than Tcl, and a nice complement to Tcl's compactness. It also matches 
Tcl for easy of deployment in terms of wrapping desktop apps 
(py2app/py2exe are pretty close to starkits and starpacks). Ruby, though 
more fashionable, and Perl, though it has a larger developer community, 
are actually conspicuously weak for deployment of standalone desktop 
apps, at least on the Mac.

My point is, Tcl/Tk are here and are actively developed. As long as the 
community does a modest amount of marketing (and the recent update of 
http://www.tcl.tk is a good start), I think it will continue to attract 
developers. The resources that the community offers--such as c.l.t and 
the wiki--also help to ensure that it will remain viable.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote:
> There will always be something more fashionable. I
> develop desktop GUI apps on Mac OS X, and I get nothing but grief from
> other Mac developers who consider Tk ugly and Tcl deficient because it
> doesn't have bindings to the flagship Apple framework, Cocoa.


So is there a _technical_ reason why Tcl doesn't have a Cocoa binding?


> the old stereotypes about the Mac
> being more about eye candy and aesthetics than utility do have a nugget
> of truth to them. :-)

Yep - same for Windows, GNOME, KDE, etc....

It wouldn't surprise me if 50% or more of the "I wish Tcl would
do...." type conversations had more to do with a desire to justify
one's choice in tools than with a real need for such features.

>
> it does some things that
> Tcl simply can't do (such as writing an sftp client, which is on my list
> of projects).


Hmm - "can't" do? That seems a bit strong. There's some technical
deficiency that makes it impossible to write such a thing in tcl?




> Python's large standard library make it a bit more robust
> than Tcl, and a nice complement to Tcl's compactness.

I'd love to see a comparison of the python standard library and the
tcl standard library, comparing what each has and each is missing,
just to give some of those looking for useful areas to code something
to aim towards.

Larry W. Virden wrote:
> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote:
>> There will always be something more fashionable. I
>> develop desktop GUI apps on Mac OS X, and I get nothing but grief from
>> other Mac developers who consider Tk ugly and Tcl deficient because it
>> doesn't have bindings to the flagship Apple framework, Cocoa.
> 
> 
> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding?

Yeah. No one's written one. :-)

> 
> 
>> the old stereotypes about the Mac
>> being more about eye candy and aesthetics than utility do have a nugget
>> of truth to them. :-)
> 
> Yep - same for Windows, GNOME, KDE, etc....
> 
> It wouldn't surprise me if 50% or more of the "I wish Tcl would
> do...." type conversations had more to do with a desire to justify
> one's choice in tools than with a real need for such features.
> 
>> it does some things that
>> Tcl simply can't do (such as writing an sftp client, which is on my list
>> of projects).
> 
> 
> Hmm - "can't" do? That seems a bit strong. There's some technical
> deficiency that makes it impossible to write such a thing in tcl?
> 

I don't know if there's a technical reason or not. But there's a Python 
library called Paramikio which implements ssh in Python, including sftp; 
it builds on top of another library, pycrypto, which provides 
cryptography. No equivalent extension exists in Tcl to my knowledge.

> 
> 
>> Python's large standard library make it a bit more robust
>> than Tcl, and a nice complement to Tcl's compactness.
> 
> I'd love to see a comparison of the python standard library and the
> tcl standard library, comparing what each has and each is missing,
> just to give some of those looking for useful areas to code something
> to aim towards.

I've just named a couple, in case anyone is interested. Alas I lack the 
C-level chops to do it myself. :-(

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Kevin Walzer wrote:
> Larry W. Virden wrote:
>> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote:
>>> There will always be something more fashionable. I
>>> develop desktop GUI apps on Mac OS X, and I get nothing but grief from
>>> other Mac developers who consider Tk ugly and Tcl deficient because it
>>> doesn't have bindings to the flagship Apple framework, Cocoa.
>>
>>
>> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding?
> 
> Yeah. No one's written one. :-)
> 
>>
>>
>>> the old stereotypes about the Mac
>>> being more about eye candy and aesthetics than utility do have a nugget
>>> of truth to them. :-)
>>
>> Yep - same for Windows, GNOME, KDE, etc....
>>
>> It wouldn't surprise me if 50% or more of the "I wish Tcl would
>> do...." type conversations had more to do with a desire to justify
>> one's choice in tools than with a real need for such features.
>>
>>> it does some things that
>>> Tcl simply can't do (such as writing an sftp client, which is on my list
>>> of projects).
>>
>>
>> Hmm - "can't" do? That seems a bit strong. There's some technical
>> deficiency that makes it impossible to write such a thing in tcl?
>>
> 
> I don't know if there's a technical reason or not. But there's a Python 
> library called Paramikio which implements ssh in Python, including sftp; 
> it builds on top of another library, pycrypto, which provides 
> cryptography. No equivalent extension exists in Tcl to my knowledge.

I *think* tls and trf get you most of the way there, it is just sftp 
protocol piece is missing.

> 
>>
>>
>>> Python's large standard library make it a bit more robust
>>> than Tcl, and a nice complement to Tcl's compactness.
>>
>> I'd love to see a comparison of the python standard library and the
>> tcl standard library, comparing what each has and each is missing,
>> just to give some of those looking for useful areas to code something
>> to aim towards.
> 
> I've just named a couple, in case anyone is interested. Alas I lack the 
> C-level chops to do it myself. :-(
> 


-- 
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

skuhagen@web.de schrieb:
> Arndt Roger Schneider wrote:
> 
> 
>>Big companies work on a different mind-set:
>>You got xxx people in your department, all of them need to do something
>>in order to make their managers look busy... from a financial point of
>>view xxx people cost *nothing*.
> 
> 
> I don't think so. Otherwise there would be no good argument to fire
> hundreds or thousands of people ("workers") in big companies every
> time they change some of their organisation.

There are shareholder-reasons for this behavior.

The people on the payroll represent fix-costs -- bad shareholder-vise.
After the people got fired, new people are contracted back in,
because these costs are now "investments".

> 
> 
>>As a manager the best way (to promotion) is to avoid software reuse --
>>inside and outside of your company ---maybe a little within the project
>>itself--- -- , and use the same coding system everybody in the
>>food-chain agrees with.
> 
> 
> This I totally agree with: No software reuse! is the secret slogan,
> and it's so brainless, that it sometimes make me laugh.


Precisly the field where scripting languages excel!



> 
> 
>>Ever followed the acm studies about average software-development
>>efficiency from circa 1995-2005? An nearly 10% DROP anual over 10 years!
> 
> 
> Are these numbers available somewhere? I find that really interesting.
> 
> Stephan
> 

i did read this in the acm print-magazin -- don't press me for the
actual year, though... (don't have them myself).

Here's a similar piece:
http://spot.pcc.edu/~mtrigobo/files/uncladEmperor.pdf
"The Emperor with No Clothes" from Henry F. Ledgard

.... happy hunting.

On Jun 25, 1:35 pm, Kevin Walzer <k...@codebykevin.com> wrote:
> Larry W. Virden wrote:
> >> Tcl simply can't do (such as writing an sftp client, which is on my list
> >> of projects).
>
> > Hmm - "can't" do? That seems a bit strong. There's some technical
> > deficiency that makes it impossible to write such a thing in tcl?
>
> I don't know if there's a technical reason or not. But there's a Python
> library called Paramikio which implements ssh in Python, including sftp;
> it builds on top of another library, pycrypto, which provides
> cryptography. No equivalent extension exists in Tcl to my knowledge.


I see in the descriptions of tclcurl
http://personal1.iddeo.es/andresgarci/tclcurl/english/docs.html
a reference to getting data via SFTP (among other) . This is via the
binding to libcurl.

>From my (admittedly brief) perusal of the web, it looks to me like
there are sftp clients, and an sftp protocol. But I also seem to see
discussions that the proposed standard for sftp the protocol has
seemed to stagnent at version 6, and that sftp servers appear to be
"stabilized" supporting either version 2 or 3 of the proposed
standard.

I'm uncertain exactly what, among all that chaos, you were seeking,
but maybe tclcurl has enough support for what you want?

Larry W. Virden wrote:
> On Jun 25, 1:35 pm, Kevin Walzer <k...@codebykevin.com> wrote:
>> Larry W. Virden wrote:
>>>> Tcl simply can't do (such as writing an sftp client, which is on my list
>>>> of projects).
>>> Hmm - "can't" do? That seems a bit strong. There's some technical
>>> deficiency that makes it impossible to write such a thing in tcl?
>> I don't know if there's a technical reason or not. But there's a Python
>> library called Paramikio which implements ssh in Python, including sftp;
>> it builds on top of another library, pycrypto, which provides
>> cryptography. No equivalent extension exists in Tcl to my knowledge.
> 
> 
> I see in the descriptions of tclcurl
> http://personal1.iddeo.es/andresgarci/tclcurl/english/docs.html
> a reference to getting data via SFTP (among other) . This is via the
> binding to libcurl.
> 
>>From my (admittedly brief) perusal of the web, it looks to me like
> there are sftp clients, and an sftp protocol. But I also seem to see
> discussions that the proposed standard for sftp the protocol has
> seemed to stagnent at version 6, and that sftp servers appear to be
> "stabilized" supporting either version 2 or 3 of the proposed
> standard.
> 
> I'm uncertain exactly what, among all that chaos, you were seeking,
> but maybe tclcurl has enough support for what you want?
> 
> 

I had forgotten about tclurl. However, there's a complex chain of 
dependencies at work here; curl itself must link to a non-standard 
library (libssh2) to get sftp support, and then one has to build Tclurl 
on top of that. Plus, since I'm doing this on the Mac, everything has to 
be built as a universal binary. Because there are so many moving parts, 
I've never gotten everything to build correctly.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

On Jun 26, 1:40 am, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> Kevin Walzer wrote:
> > Larry W. Virden wrote:
> >> On Jun 25, 11:24 am, Kevin Walzer <k...@codebykevin.com> wrote:
> >>> There will always be something more fashionable. I
> >>> develop desktop GUI apps on Mac OS X, and I get nothing but grief from
> >>> other Mac developers who consider Tk ugly and Tcl deficient because it
> >>> doesn't have bindings to the flagship Apple framework, Cocoa.
>
> >> So is there a _technical_ reason why Tcl doesn't have a Cocoa binding?
>
> > Yeah. No one's written one. :-)
>
> >>> the old stereotypes about the Mac
> >>> being more about eye candy and aesthetics than utility do have a nugget
> >>> of truth to them. :-)
>
> >> Yep - same for Windows, GNOME, KDE, etc....
>
> >> It wouldn't surprise me if 50% or more of the "I wish Tcl would
> >> do...." type conversations had more to do with a desire to justify
> >> one's choice in tools than with a real need for such features.
>
> >>> it does some things that
> >>> Tcl simply can't do (such as writing an sftp client, which is on my list
> >>> of projects).
>
> >> Hmm - "can't" do? That seems a bit strong. There's some technical
> >> deficiency that makes it impossible to write such a thing in tcl?
>
> > I don't know if there's a technical reason or not. But there's a Python
> > library called Paramikio which implements ssh in Python, including sftp;
> > it builds on top of another library, pycrypto, which provides
> > cryptography. No equivalent extension exists in Tcl to my knowledge.
>
> I *think* tls and trf get you most of the way there, it is just sftp
> protocol piece is missing.
>

Except for the crypto parts, tls won't help much. Heck, tcllib already
does blowfish, AES and DES, which covers the encryption mechanism used
by SSH (SFTP is a subset of the SSH protocol). So you don't even need
tls. We only need to implement the SSH protocol. OK, the digital
certificates part can be taken from tls so tls would be helpful there.

Kevin Walzer wrote:
> Larry W. Virden wrote:
>> I'd love to see a comparison of the python standard library and the
>> tcl standard library, comparing what each has and each is missing,
>> just to give some of those looking for useful areas to code something
>> to aim towards.
> 
> I've just named a couple, in case anyone is interested. Alas I lack the 
> C-level chops to do it myself. :-(

Even just the comparisons *from a script-level perspective* are valuable
since they indicate areas where effort may be applied. And look, that
doesn't require any knowledge of C. :-)

Donal.

davidnwelton@gmail.com wrote:
> What I'm talking about are the languages with buzz and hype going for
> them.  Ruby has this in spades.

They're nicely placed in an area that's currently "hot" (server support
for small webapps) that's all.

Donal.

davidnwelton wrote:
> Larry W. Virden wrote:

> > How much "marketing" do you see concerning COBOL, FORTRAN, C, and
> > assembly languages?

> What those have going for them are the lock-in effects associated with
> the switching costs of massive deployments of production systems,
> which are pretty much insurmountable for many systems and companies.
> That's not, however, the same thing as what people are using to write
> new code with.

I disagree.  Well, I don't know about COBOL, that may be a lock-in 
effect (based on platform, as well as language).  If I recall correctly,
FORTRAN still does some very nice things with being efficient, over
and above well-written C on the average compiler.  (This may no longer
be the case.  It's been a while.)

C and assembly certainly have a a place that is not simply retained by
lock-in.  There are still markets where the overhead of anything fancier 
is too expensive.  There are still niche markets where 8-bit micros
are used for cost considerations.

As assembly goes, sometimes it's the only tool for the job.

Admittedly, anyone who is running and maintaining a DBMS coded in 
assembly has either been subject to extreme lock-in, or is severely 
deranged.

-- 
MKS

Melissa Schrumpf wrote:
> Admittedly, anyone who is running and maintaining a DBMS coded in 
> assembly has either been subject to extreme lock-in, or is severely 
> deranged.

If they're deranged like that, they'll be subject to a different sort of
"extreme lock-in" involving padded cells...

Donal.

On Jun 27, 1:13 am, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> Melissa Schrumpf wrote:
> > Admittedly, anyone who is running and maintaining a DBMS coded in
> > assembly has either been subject to extreme lock-in, or is severely
> > deranged.
>
> If they're deranged like that, they'll be subject to a different sort of
> "extreme lock-in" involving padded cells...
>
> Donal.

Well, there's always the military. A friend of mine worked for the US
Air Force in the late 1970s. They did inventory, using programs
originally written in Fortran. The machines did not do multitasking.
To compile, you first loaded the compiler and ran the source through.
Then you loaded the assembler and ran the output of the previous pass
through and got an object deck. Then you loaded the program and ran
it, resulting in an output deck. Then you loaded the output deck and
printed it. This procedure was so slow that before my friend got there
they had ceased to modify the Fortran sources and just patched
everything directly in machine language. Not assembler, machine
language.

On Jun 27, 2:01 am, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> davidnwelton wrote:
> > Larry W. Virden wrote:
> > > How much "marketing" do you see concerning COBOL, FORTRAN, C, and
> > > assembly languages?
> > What those have going for them are the lock-in effects associated with
> > the switching costs of massive deployments of production systems,
> > which are pretty much insurmountable for many systems and companies.
> > That's not, however, the same thing as what people are using to write
> > new code with.
>
> I disagree.  Well, I don't know about COBOL, that may be a lock-in
> effect (based on platform, as well as language).  If I recall correctly,
> FORTRAN still does some very nice things with being efficient, over
> and above well-written C on the average compiler.  (This may no longer
> be the case.  It's been a while.)

> C and assembly certainly have a a place that is not simply retained by
> lock-in.  There are still markets where the overhead of anything fancier
> is too expensive.  There are still niche markets where 8-bit micros
> are used for cost considerations.

Sure, FORTRAN and C have some good qualities, but they're not the only
fast languages out there - just that they've come to dominate their
niches.  Because they're so widely used, they are the natural, default
choices for an array of programming tasks.  Tcl is not in that
fortunate situation, so the original comparison "those languages don't
need marketing" is not really relevant in any case.

Melissa Schrumpf wrote:
> C and assembly certainly have a a place that is not simply retained by
> lock-in.  There are still markets where the overhead of anything fancier 
> is too expensive.  There are still niche markets where 8-bit micros
> are used for cost considerations.

Plus, many of those microcomputers are designed to be programmed in a 
C-like language. One can build microcomputer CPUs designed to run (say) 
FORTH, with just as low overhead, on which C would run poorly. But since 
C might run poorly on such an architecture, they never really make it to 
wide-spread market adoption.

-- 
   Darren New / San Diego, CA, USA (PST)
     I bet exercise equipment would be a lot more
     expensive if we had evolved from starfish.

In article <f5t684$1mg8$1@godfrey.mcc.ac.uk>,
Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
>Melissa Schrumpf wrote:
>> Admittedly, anyone who is running and maintaining a DBMS coded in 
>> assembly has either been subject to extreme lock-in, or is severely 
>> deranged.
>
>If they're deranged like that, they'll be subject to a different sort of
>"extreme lock-in" involving padded cells...
>
>Donal.

Do see, however, http://en.wikipedia.org/wiki/Charles_H._Moore.

Darren New wrote:
> Melissa Schrumpf wrote:

> > C and assembly certainly have a a place that is not simply retained by
> > lock-in.  There are still markets where the overhead of anything fancier 
> > is too expensive.  There are still niche markets where 8-bit micros
> > are used for cost considerations.

> Plus, many of those microcomputers are designed to be programmed in a 
> C-like language.

Strictly-speaking, are they, or have the embedded-target C compilers 
just been optimized for so long that they just happen to be the best 
tools available?

> One can build microcomputer CPUs designed to run (say) 
> FORTH, with just as low overhead, on which C would run poorly.

True.  The first time I encountered OpenBoot, I was astonished that it 
handled what appeared to be a "remedial shell" so quickly.  Until I 
learned that it was simply made to run forth, and about FCode.  :-)~

> But since C might run poorly on such an architecture, they never really
> make it to wide-spread market adoption.

But it's not C itself that runs on the processor, it's the machine code 
to which it is ultimately converted.  Isn't it more a matter that the 
optimal language for any system would be that which most closely 
reflects the underlying architecture, so that compiler abstractions need 
not be overly lossy?

-- 
MKS

billposerwrote:
> Donal K. Fellows wrote:
> > Melissa Schrumpf wrote:

> > > Admittedly, anyone who is running and maintaining a DBMS coded in
> > > assembly has either been subject to extreme lock-in, or is severely
> > > deranged.
> >
> > If they're deranged like that, they'll be subject to a different sort of
> > "extreme lock-in" involving padded cells...
> 
> Well, there's always the military.

QED.


> A friend of mine worked for the US
> Air Force in the late 1970s. They did inventory, using programs
> originally written in Fortran. The machines did not do multitasking.
> To compile, you first loaded the compiler and ran the source through.
> Then you loaded the assembler and ran the output of the previous pass
> through and got an object deck. Then you loaded the program and ran
> it, resulting in an output deck. Then you loaded the output deck and
> printed it.

But... that's more or less how compiling works, right?  It's not so much 
a matter of multitasking as serial-tasking without intermediate output 
steps.  Just that the machine didn't have appropriate temporary storage.


> This procedure was so slow that before my friend got there
> they had ceased to modify the Fortran sources and just patched
> everything directly in machine language. Not assembler, machine
> language.

Sounds more fun that way, actually.

-- 
MKS

Melissa Schrumpf wrote:
>> Plus, many of those microcomputers are designed to be programmed in a 
>> C-like language.
> 
> Strictly-speaking, are they, or have the embedded-target C compilers 
> just been optimized for so long that they just happen to be the best 
> tools available?

I've worked with several mainframes that were unable to support C. They 
were some of the most powerful mainframes of their time. Try to sell any 
CPU nowadays that can't support C and see what happens. I'm not talking 
about just embedded stuff - to me, "microcomputer" includes anything not 
designed for I/O over compute speed. :-)

(Of course you can support C on any machine by either writing an 
interpreter or letting undefined things really crash the machine. Not 
very efficient tho. Plus, of course, there are *some* really small 
"postage-stamp" style machines that (say) only run PIC-Basic or some 
such, but they really aren't too general purpose either.)

>> But since C might run poorly on such an architecture, they never really
>> make it to wide-spread market adoption.
> 
> But it's not C itself that runs on the processor, it's the machine code 
> to which it is ultimately converted.  Isn't it more a matter that the 
> optimal language for any system would be that which most closely 
> reflects the underlying architecture, so that compiler abstractions need 
> not be overly lossy?

Well, take for example a Burroughs B-series machine. Each memory 
location was tagged with the type of data stored there. You couldn't 
take an integer and store it into a pointer variable. You couldn't have 
a union of a double and a long. You couldn't implement something like 
printf() that took variable types of arguments in different calls. The 
CPU "add" instruction just had the addresses of the operands to add, and 
took the types of the data stored at those addresses to figure out 
whether to add floats, add integers, etc. You could run C on such a 
machine only by writing an interpreter for it. OTOH, Pascal and Algol 
ran fine.

C makes some assumptions about your architecture that, if your 
architecture doesn't support it, complex C programs won't run. That ints 
and pointers are interchangable, that there's an address type that can 
point to any address (i.e., that it's possible to have a void*), that 
it's possible to take the address of a function and branch to it, that 
all your data is in the same address space at the same time, and so on. 
I've used embedded systems where it wasn't possible to take the address 
of a function, for example, because each function was in its own address 
space due to address paging translation sorts of things. Or a machine 
that has a block of memory for integers, a block of memory for floats, 
etc. That would work fine for BASIC and APL (and maybe old FORTRANs?), 
and C just plain wouldn't run.

You don't see those sorts of architectures any more. Nor do you often 
see architectures targeted at other languages, like having the 
COBOL-specific opcodes lots of mainframes used to have. Popular 
languages influence CPU design at least to that extent.

-- 
   Darren New / San Diego, CA, USA (PST)
     I bet exercise equipment would be a lot more
     expensive if we had evolved from starfish.

On Jun 29, 2:19 am, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
>
> > > If they're deranged like that, they'll be subject to a different sort of
> > > "extreme lock-in" involving padded cells...
>
> > Well, there's always the military.
>
> QED.

Joke of the month at least !
(Just imagine this with the voices of Homer and Marge...)

-Alex

On Jun 28, 5:19 pm, Melissa Schrumpf
<m_schrumpf_at_yahoo_com_...@microsoft.com> wrote:
> But... that's more or less how compiling works, right?  It's not so much
> a matter of multitasking as serial-tasking without intermediate output
> steps.  Just that the machine didn't have appropriate temporary storage.
>
> > This procedure was so slow that before my friend got there
> > they had ceased to modify the Fortran sources and just patched
> > everything directly in machine language. Not assembler, machine
> > language.
>
> Sounds more fun that way, actually.
>
> --
> MKS

True, it isn't a matter of multitasking exactly. I was just listing
archaic features of the machine. And I forget the linking pass.

I actually learned to program this way. My high school was far from
high tech, but was close to a major IBM site, so IBM gave the school
an old computer and one of the math teachers learned to run it. We
learned Fortran (like God meant it to be, not the almost bearable new-
fangled kind) with input via punch cards. The machine had a disk, but
it was full of school records so we weren't allowed to create disk
files. In addition to our programming class (almost all guys) there
was a vocational "data entry" class, all girls. Such were the
priorities in our school that we were required to give up the card
punch machine to the girls taking data entry whenever they wanted to
use them. The card punch machine we had was the kind that didn't print
the text on the card (model 028?). I'm not impressed by people who
whine about the command line or how hard anything other than a Mac is
impossible to use: I thought that the next model up (029?), which
printed the text at the top of the card, was a huge improvement in
user-interface, and later, when I got to use a terminal with a line-
editor, that was hog-heaven!