f



How Tcl speaks for itself and how Tcl is not spoken for...

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

0
skuhagen (111)
6/22/2007 11:40:03 AM
comp.lang.tcl 23429 articles. 2 followers. Post Follow

41 Replies
1342 Views

Similar Articles

[PageSpeed] 24

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:).


0
6/22/2007 1:39:07 PM
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

0
damon6845 (74)
6/22/2007 2:26:13 PM
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
0
glennj (645)
6/22/2007 3:36:46 PM
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.


0
6/22/2007 4:23:16 PM
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 ...
0
claird (2363)
6/22/2007 8:14:19 PM
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

0
6/23/2007 2:37:26 PM
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.

0
6/24/2007 10:26:27 AM
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

0
cwjolly (228)
6/24/2007 7:05:56 PM
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

0
skuhagen (111)
6/25/2007 5:45:18 AM
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

0
skuhagen (111)
6/25/2007 5:47:31 AM
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

0
skuhagen (111)
6/25/2007 5:58:13 AM
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

0
skuhagen (111)
6/25/2007 6:04:35 AM
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

0
skuhagen (111)
6/25/2007 6:12:11 AM
> 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

0
davidnwelton (136)
6/25/2007 7:44:53 AM
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.
0
claird (2363)
6/25/2007 8:16:36 AM
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.

0
6/25/2007 10:24:51 AM
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.

0
6/25/2007 10:31:06 AM
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".


0
lvirden (1938)
6/25/2007 12:26:09 PM
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.

0
6/25/2007 12:40:51 PM
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.

0
davidnwelton (136)
6/25/2007 12:53:45 PM
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
0
kw564 (720)
6/25/2007 3:24:19 PM
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.


0
lvirden (1938)
6/25/2007 4:22:40 PM
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
0
kw564 (720)
6/25/2007 5:35:26 PM
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|
+------------------------------------------------------------------------+
0
Gerald.Lester (2014)
6/25/2007 5:40:43 PM
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.
0
6/25/2007 6:11:13 PM
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?





0
lvirden (1938)
6/25/2007 6:15:10 PM
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
0
kw564 (720)
6/25/2007 6:22:08 PM
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.

0
slebetman (894)
6/26/2007 5:01:24 AM
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.
0
6/26/2007 9:56:53 AM
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.
0
6/26/2007 9:59:21 AM
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
0
6/27/2007 12:01:21 AM
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.
0
6/27/2007 8:13:45 AM
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.

0
billposer (379)
6/27/2007 9:26:04 AM
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.

0
davidnwelton (136)
6/27/2007 10:28:51 AM
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.
0
dnew (1159)
6/27/2007 4:51:25 PM
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.
0
claird (2363)
6/28/2007 5:15:28 PM
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
0
6/29/2007 12:12:26 AM
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
0
6/29/2007 12:19:04 AM
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.
0
dnew (1159)
6/29/2007 12:39:39 AM
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

0
6/29/2007 6:41:28 AM
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!

0
billposer (379)
6/30/2007 4:17:32 AM
Reply:

Similar Artilces:

tcl-gaul: Genetic Algorithms for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-gaul Tcl-gaul is a Tcl extension for genetic/evolutionary algorithm processing.It relies on the GAUL library: http://gaul.sourceforge.net/ * A genetic algorithm (GA) is a search technique used in computing to find exact or approximate solutions to optimization and search problems. Genetic algorithms are categorized as global search heuristics. They are a particular class of evolutionary algorithms that use techniques inspired by evolutionary biology such as inheritance, mutation, selection, and crossover. For an introduction to genetic algorithms visit: http://gaul.sourceforge.net/intro.html Platform: Linux (GAUL library dependency) Home page: http://sourceforge.net/projects/tcl-gaul/ Man page: http://tcl-gaul.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-pam: PAM authentication for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-pam Tcl-pam is a Tcl interface to the PAM* service of Linux. It provides a Tcl package that allows Tcl scripts to use PAM to authenticate users and programs. It relies on linux-pam library: http://www.kernel.org/pub/linux/libs/pam/ * PAM (Pluggable Authentication Modules): A mechanism to integrate multiple low−level authentication schemes into a high−level application programming interface (API). This enables programs that rely on authentication to be written independently of the underlying authentication scheme. Platform: Linux Home page: http://sourceforge.net/projects/tcl-pam/ Man page: http://tcl-pam.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-syslog: Unix system logging for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-syslog Tcl-syslog is a Tcl interface to the *nix syslog service. It provides a Tcl package that allows Tcl scripts to log messages to syslog. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-syslog/ Man page: http://tcl-syslog.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-mmap: A POSIX mmap interface for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mmap Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides a Tcl package that allows Tcl scripts to: 1) Memory map files for improved access efficiency; 2) Share memory between related processes; 3) Easily implement cyclic persistent log files. * See the mmap(2) man page. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-mmap/ Man page: http://tcl-mmap.sourceforge.net/ Author: Alexandros Stergiakis On Sep 3, 11:48=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl project: tcl-mmap > > Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides > a Tcl package that allows Tcl scripts to: 1) Memory map files for > improved access efficiency; 2) Share memory between related processes; > 3) Easily implement cyclic persistent log files. > > * See the mmap(2) man page. > Great to see this and the other packages you made. Looking at the manpage it looks a bit misformatted before the usage example. Any specific reason to use GPL for this instead the usual Tcl/MIT/BSD style license used? Michael schlenk wrote: > On Sep 3, 11:48 am, Alexandros Stergiakis <alst...@gmail.com> wrote: >> This is an announcement for a relatively new Tcl project: tcl-mmap >> >> Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides >> a Tcl package that...

tcl-mq: POSIX Message Queues for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mp Tcl-mp is a Tcl interface to POSIX Message Queues*. It provides a Tcl package that allows scripts to create/open/close/unlink multiple parallel message queues, and to send/receive messages synchronously and asynchronously to/from them. * A POSIX message queue is an Inter-Process Communication mechanism available on Linux and some other POSIX-compliant operating systems. It allows to or more processes (or threads) to communicate under the same OS. The messages are buffered by the kernel, which gives them kernel persistency. A message queue can be thought of as a linked list of messages. Threads with adequate permission can put messages onto the queue, and threads with adequuate permission can remove messages from the queue. Each message is assigned a priority by the sender, and the oldest message of highest priority is always retrieved first. Unlike PIPES and FIFOS, no requirement exists that someone be waiting for a message to arrive on a queue, before some process writes a message to that queue. It's not even a requirement for both processes to exist at the same time. Read mq_overview(7) for more details Platform: Linux Home page: http://sourceforge.net/projects/tcl-mp/ Man page: http://tcl-mp.sourceforge.net/ Author: Alexandros Stergiakis alsterg On Sep 3, 11:37=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl pro...

Opening a TCL program from within another TCL program in ANSYS Tcl-Tk
Hi everyone, I have been pulling my hair with this one for a couple of days and still have not found a fix. I'm working within ANSYS Tcl-Tk implementation. I created a Tcl-Tk script that generates a simple window with three buttons. Each button opens another window which is created in a separate Tcl file. The second window have a lot of text entries, variables, procedures, etc. I can open the second Tcl file by itself and everything works as supposed, but when I open it using the button in the first window, it opens but any procedure called by the widgets on the second window are not found... Here's the deal... Since I'm working within the ANSYS implementation of Tcl-Tk, I'm actually using an ANSYS command to open the second window. The command I use is: ### ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' ### It actually sends a command back to ANSYS telling it to execute a Tcl command... I know this is not pretty but its the only way i was able to make it at least show the window. ############################## #Main Tcl (excerpt): ############################## namespace eval Tools { proc IBRCambpell {} { #source O:/mad_projects_2/ANSYS/Macros/IBR_CAS.tcl ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' } proc viewManager {} { ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ ViewManager.tcl' } proc powerAnnotation {} { ans_sendcommand ~eui,'source ...

tcl-snmptools: SNMP v1/v2/v3 operations for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-snmptools Tcl-snmptools is a Tcl interface to the Net-SNMP library which provides operations for the management of remote SNMP agents. It supports all the standard SNMP v1/v2/v3 operations: connect, close, get, set, getnext, walk, bulkget, bulkwalk, trap, translate and others. It is currently in a functional state, but more work and testing needs to be done. Home page: http://sourceforge.net/projects/tcl-snmptols/ Man page: http://tcl-snmptols.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl application with tcl application
Here is another question, I have one tcl-based application A, my co- worker has a tcl-based application B. Now I want to integrate my application A into the application B. After integration, I want to be able to run A's tcl command in B. Assume I can only change A's code, is there any way to do this? On 17 Dez., 07:03, teacupfull business <teacupfull.busin...@gmail.com> wrote: > Here is another question, I have one tcl-based application A, my co- > worker has a tcl-based application B. Now I want to integrate my > application A into the application B. >...

How to compile tcl or encrypt tcl
I use TclPro1.5 to compile my tcl script with tixwish in the Solaris before. But I cannot use the same method in Linux. Why? Is there any utility for me to compile or encrypt the code by using tixwish? The following is the simple code if I use the tixwish: #!/home/albertl/local/bin/tixwish puts "haha" And after using procomp by the TclPro1.5 Error in startup script: The TclPro ByteCode Loader is not available or does not support the correct version while executing "error "The TclPro ByteCode Loader is not available or does not support the correct version"" invoked from within "if {[catch {package require tbcload 1.3} err] == 1} { error "The TclPro ByteCode Loader is not available or does not support the correct version" ...." (file "a.tbc" line 4) The problem seems that tbcload1.3 cannot be found? But tbcload is already there "/home/albertl/local/lib/tbcload1.3" Why? Can anyone tell me? stratus schrieb: > I use TclPro1.5 to compile my tcl script with tixwish in the Solaris before. > But I cannot use the same method in Linux. Why? > > Is there any utility for me to compile or encrypt the code by using tixwish? > Tixwish is just a wish shell with the Tix package baked in. If TclPro does not have a specific bigwish with Tix included your out of luck on that road (but could build your own if you liked). You might have success with freewrap or TDK, don't know for su...

Extending TCL in C with tcl.h - Disabliing [<tcl-cmd>] feature
Hi, TCL has a command execution syntax like this: [<tcl cmd>] Anything inside the 3rd bracket will be executed as a Tcl command by the Tcl interprater. Is there any way I can disable/delete this Tcl construct [ <tcl-cmd>]? In other words, my Tcl interprator should print "[32]" for tcl command puts "[32]" It should not try to treat [] as a special character. Is this any way possible while extending Tcl in C with tcl.h? Thank you, Arijit * arijit79@gmail.com | puts "[32]" | | It should not try to treat [] as a special character. Check out the TCL quoting rules. http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10 http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M15 Any of puts {[32]} puts "\[32\]" will do the trick. R' On May 8, 3:14 am, ariji...@gmail.com wrote: > Is there any way I can disable/delete this Tcl construct [ <tcl-cmd>]? By doing this, you would disable the primary functionality of Tcl. I'm certain you could go into the tcl source and stop it - but why not talk about what you are really trying to do. Perhaps someone can give you a better way of doing what you are wanting to do. ...

Tcl
Hello, where can I see for tcl syntacs and how-to run a tcl test? Thank You Vittore ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu ...

TCL
Hello, i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me how this can be done with VC 6.0? Best regards, Reinhold "Reinhold.kwauka" <bernd-reinhold.kwauka@t-online.de> wrote: >Hello, > >i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me >how this can be done >with VC 6.0? > >Best regards, >Reinhold > 1) get the source from http://tcl.sourceforge.net/ 2) open a command prompt 3) cd to the win/ subdirectory 4) call vcvars32.bat located in ??\vc98\bin\ of vc6 for wherever you installed it. 5) type @ the prompt: nmake -f makefile.vc -- David Gravereaux <davygrvy@pobox.com> [species: human; planet: earth,milkyway(western spiral arm),alpha sector] Reinhold.kwauka wrote: > Hello, > > i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me > how this can be done > with VC 6.0? > > Best regards, > Reinhold > > Its already done. Just download a binary release for windows and check \Program Files\Tcl\lib for the DLLs and static libraries. ...

Tcl
Hello all. I found on hobbes the afaik latest Tcl for Os/2 v8.35 Is there any newer port, cause i try to update the eggdrop and that says: Your Tcl version is much too old for Eggdrop to use. You should download and compile a more recent version. The most reliable current version is 8.5.X and can be downloaded from ftp://tcl.activestate.com/pub/tcl/tcl8_5/. -- With the best regards from the Netherlands, Tu, "Tellerbop" <Tellerbop@wint.nl>, hai scritto questo in data Wed, 14 Jan 2009 19:11:18 UTC: > Hello all. > > I found on hobbes the afaik latest Tcl for Os/2...

MS Dictation and TCL
I'm trying to use the MS dictation tool while in TCL 8.5 program. The text starts to appear, but then the program crashes. It would be great to find a way to make this work. Thanks! Barney Tcl 8.5 (wish 8.5) makeindex (12/14/2007) MSWinXP sp3 plenty of ram and storage ...

Tcl command to evaluate a tcl script?
Hi all, I need to evaluate a separate tcl file within a tcl file. Is there any tcl command to evaluate a tcl file ? Regards, Prabu.K prabu wrote: > Hi all, > > I need to evaluate a separate tcl file within a tcl file. Is there any > tcl command to evaluate a tcl file ? > > Regards, > Prabu.K > hi, try: source your_other_tcl_file.tcl cheers, Tobi ...

How Tcl source finds init.tcl???
Hi, I have one question about how Tcl finds init.tcl. What environment variable does Tcl source use to get the search path for init.tcl? Is there any way to specifically use init.tcl from a certain path? Thanks a lot in advance! Lihong lihong pei wrote: > I have one question about how Tcl finds init.tcl. > What environment variable does Tcl source use to get the search path for > init.tcl? If the environment variable TCL_LIBRARY exists, it's value is assumed to be a single directory which is added to the search path for init.tcl. Note that this is offered mostly as a way for...

[TCL] diff type operations in TCL
I didn't see anything in tcllib and thus far haven't turned up anything that looks like it will work. I would like to know if there is a TCL package, or already written procedure, that will do a simple diff of two files and tell me if they're the same or if they have differences. Is there anything like this? --------------------------------------------- Andrew R. Falanga (a non-HP employee) Hewlett-Packard Company 11311 Chinden Blvd. Boise, Idaho --------------------------------------------- Please note: The e-mail address is purposely mangled. I do not wish my account at HP to become a spam haven. Andrew Falanga wrote: > I didn't see anything in tcllib and thus far haven't turned up anything > that looks like it will work. I would like to know if there is a TCL > package, or already written procedure, that will do a simple diff of two > files and tell me if they're the same or if they have differences. > > Is there anything like this? If all you want to know is if they are different, then: set fd [open $file1 r] set f1 [read $fd] close $fd set fd [open $file2 r] set f2 [read $fd] close $fd if {[string equal $f1 $f2]} then { puts "'$file1' and '$file2' are the same." } else { puts "'$file1' and '$file2' are different." } -- +--------------------------------+---------------------------------------+ | Gerald W. Lester ...

dynamic call of tcl proc from tcl
Hello, I would like to invoce a tcl proc from a line of tcl where I have a proc name and a list variable of arguments. eg. % callproc $procName $argList where: ..callproc - TCL Procedure for dynamically calling procedures ..procName - Name of procedure to be called in a string ..argList - List of Arguments My goal is to avoid creating a procedure call as a string and evaluating it as there are many potential pitfalls with using evals in such a way. Thanks, JsD Java script Dude wrote: > I would like to invoce a tcl proc from a line of tcl where I have a > proc name and a list variable of arguments. > > eg. % callproc $procName $argList > > where: > .callproc - TCL Procedure for dynamically calling procedures > .procName - Name of procedure to be called in a string > .argList - List of Arguments Except for error/exception handling, the answer is: proc callproc {cmd argList} { uplevel 1 [linsert $argList 0 $cmd] } -- | Don Porter Mathematical and Computational Sciences Division | | donald.porter@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| [; Thanks Don ;] ...

Inline::Tcl vs. Inline::Tcl
The readme for CPAN's Inline::Tcl says this: > This module is not related to the Inline::Tcl module, but it might be > valuable to have some compatibility between the two. > This sentence seems to suggest that there is another module named Inline::Tcl somewhere. Is this true, and if so, where can I find it? Mumia W. wrote: > The readme for CPAN's Inline::Tcl says this: > > > This module is not related to the Inline::Tcl module, but it might be > > valuable to have some compatibility between the two. > > > > This sentence seems to suggest ...

[TCL] multi-threaded tcl apps
Hi, Where can one find complete documentation on the ttrace package to the Thread package? I'd like to know what commands are available in ttrace and how to use them. --------------------------------------------- Andrew R. Falanga (a non-HP employee) Hewlett-Packard Company 11311 Chinden Blvd. Boise, Idaho --------------------------------------------- Please note: The e-mail address is purposely mangled. I do not wish my account at HP to become a spam haven. If you wish to e-mail me, the address consists of a dot between my first and last names (excluding my middle initial). The rest is accurate. Also, note, responses must be within the given context of messages I've posted to usenet. If it's not, I WILL NOT RESPOND! ...

Tcl extension: check Tcl version?
Is there a recommended way to check if a (binary) Tcl extension is loaded to the same Tcl version that was used for linking the extension? Currently I'm encountering a problem with an extension that I have built (and linked) with libtk8.3.so and that can be loaded under wish8.5 as well (without re-bulding, using package require). A number of newly provided commands work well in spite of the version mixture, but others don't, and wish8.5 crashes when these commands are used. Is this behavior normal, i.e. should I check that compile-time version and run-time version are identical? Or does this indicate some subtle coding problem? Thanks for any suggestions Olaf Olaf Dietrich wrote: > Is there a recommended way to check if a (binary) Tcl extension > is loaded to the same Tcl version that was used for linking > the extension? > > Currently I'm encountering a problem with an extension that > I have built (and linked) with libtk8.3.so and that can be > loaded under wish8.5 as well (without re-bulding, using > package require). A number of newly provided commands work > well in spite of the version mixture, but others don't, and > wish8.5 crashes when these commands are used. > > Is this behavior normal, i.e. should I check that compile-time > version and run-time version are identical? Or does this > indicate some subtle coding problem? Not subtle. Major problem. DO NOT DO THAT. If you want to be loadable across mult...

Debugger for Tcl/Tk and [incr Tcl]
hi, where can i get Coverage for debugging tcl/tk, [incr Tcl] source? this tool is advised to use in 'Practical Programming in Tcl and Tk' or any other good debugger, which i could use? best, s. On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > hi, > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > or any other good debugger, which i could use? I see, at http://wiki.tcl.tk/8638 , a brief reference to the topic of coverage for tcl. I don't know whether or not any of the tools mentioned include coverage of itcl. On 23 jan, 12:52, "Larry W. Virden" <lvir...@gmail.com> wrote: > On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > > > hi, > > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > > or any other good debugger, which i could use? > > I see, athttp://wiki.tcl.tk/8638, a brief reference to the topic of > coverage for tcl. I don't know whether or not any of the tools > mentioned include coverage of itcl. I have a more complete version of the coverage tool mentioned on that page. I just never got around to publishing it more widely. As for debuggers: the Wiki has a lot of pointers on that subject as well. Regards, Arjen Larry W. Virden wrote:...

Possible bug in Tcl or Windows or Tcl on Windows
Hi, There seems to be a bug in the way numbers are compared in Tcl. Consider the below script for calculating Pythagorean triplets. For hypotenuse upto a value of 100, there should have been 63 unique triplets. On Windows XP the script detects only 62. The script doesn't detect the case where c=99, b=20 ==> a=101. However running the same script under Tcl 8.4.1 in Cygwin detects 63 triplets. I don't have a Linux machine at hand to test it there. Following is the script and relevant output. Could anyone shed some light on the cause of this. Maybe it has something to do with how the numbers are represented internally? Running the script for N>100 shows up many more such missed values. An equivalent program in C runs correctly on the same machine. C code was compiled using both gcc and VC++6.0. ######################################################################### # a^2 = b^2 + c^2 proc pythag {MAX} { set i 0 for {set c 2} {$c <= $MAX} {incr c} { for {set b 1} {$b < $c} {incr b} { set a [expr hypot($c, $b)] ;# Calc. Hypot if { ($c == 99) && ($b == 20)} { ;# <<<<<<<< puts ">> [expr round($a)] == $a" } if {[expr round($a)] == $a} { puts "$a : $b : $c" incr i } } } return $i } if {$argc == 1} { set MAX [lindex $argv 0] } else { puts stderr "Usage: tclsh $argv0 N" exit } puts [pythag $MAX] ############# OUTPUT ################ Tcl 8.4.1 (Cygwi...

Tcl only
I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. On Thursday, July 12, 2012 6:22:45 AM UTC-7, Robert wrote: > I am curious about how many people just use Tcl for a systems language (i= nstead of say, BASH) but don&#39;t use Tk. For me, if the script is mainly concerned with invoking other programs and = little else, then I'll grit my teeth and do it in bash because it handles s= uch things well even if the syntax is vintage Algol. Otherwise, it is hard = to get me to program in anything other than Tcl when the target is a conven= tional computing environment. Andrew Mangogna On Thursday, July 12, 2012 9:22:45 AM UTC-4, Robert wrote: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don&#39;t use Tk. I use tcl, bash, perl, awk. I hardly ever have GUI frontends. Στις 12/7/2012 16:22, ο/η Robert έγραψε: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. > I use tcl in almost all my scripts. I rarely use bash, and only for basic stuff (i.e. run a few tcl scripts in order). George On 7/12/12 8:22 AM, Robert wrote: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. While not exactly what you asked, I use Tcl to create Web Services -- that does not involve any GUIs (a...

Web resources about - How Tcl speaks for itself and how Tcl is not spoken for... - comp.lang.tcl

Ronald Reagan Speaks Out Against Socialized Medicine - Wikipedia, the free encyclopedia
Ronald Reagan Speaks Out Against Socialized Medicine is a 1961 LP featuring Ronald Reagan . In this more than ten-minute recording, Reagan "criticized ...

Facebook Tops 1B Monthly Active Users; Mark Zuckerberg Speaks With NBC’s Matt Lauer, ‘Bloomberg Businessweek’ ...
Facebook officially reached 1 billion monthly active users Sept. 14 at 12:45 p.m. PT, Co-Founder and CEO Mark Zuckerberg revealed in a post on ...

Former Karma Marketing Director Speaks Out - Refutes Karma's Public Timeline
Jessica Gary, Karma's Volunteer Marketing Director, tried in vain to get Karma to do the right thing for Raffiki-before Karma adopted her out ...

RockYou CTO Jia Shen Speaks on Facebook’s Punitive Viral Channel Cut-off
Early yesterday Inside Facebook's Adam Lovallo broke the news on Super Wall's huge traffic drop from 2.1 million to 600,000 daily active users ...

Publicity Speaks (@lncbrand) on Twitter
Sign in Sign up To bring you Twitter, we and our partners use cookies on our and other websites. Cookies help personalize Twitter content, tailor ...

President Jimmy Carter Speaks at Google’s Atlanta Office - Flickr - Photo Sharing!
From Stacy Williams of Prominent Placement on President Jimmy Carter Speaks at Google’s Atlanta Office.

Can We All Just Get Along? For The Kids & Old People? RODNEY KING SPEAKS! - YouTube
Rodney King appeals for calm after his people use the verdict in the police brutality trial to go on a rampage that cost the city of L.A. over ...

Julie Bishop to return asylum seekers to Iran, early budget and DD election likely, market speaks on ...
Every Monday to Friday I'll be delivering you with your personally-curated newsletter. Call it the double espresso of news - the morning news ...

Archbishop of Toronto speaks out against assisted dying
A cardinal's statement on assisted dying is to be read or shown by video today in more than 200 Catholic churches across the Archdiocese of Toronto. ...


Resources last updated: 3/13/2016 2:11:59 PM