From: George J. Carrette
Subject: Re: what to use instead of TCL or PERL
Date:
Message-ID: <43mipn$d53@news1.delphi.com>
····@fast.cs.utah.edu (Harold Carr) wrote:
>
>
>What do programmers who implement and use real programming languages
>like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL?
The answer is: C
Lisp programmers were always assembly language
programmers at heart.
"George J. Carrette" <···@delphi.com> writes:
>····@fast.cs.utah.edu (Harold Carr) wrote:
>>What do programmers who implement and use real programming languages
>>like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL?
Either Visual Basic or Java is a decent choice for little programs.
John Nagle
In article <···············@netcom.com> ·····@netcom.com (John Nagle) writes:
* >····@fast.cs.utah.edu (Harold Carr) wrote:
* >>What do programmers who implement and use real programming
* >>languages like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use
* >>instead of TCL or PERL?
*
* Either Visual Basic or Java is a decent choice for little programs.
Tcl is an embeddable scripting language. Perl is mainly a system
administration and shell script language. Both are primarily Unix
based. In what sense are Visual Basic or Java appropriate for the
typical uses of Tcl or Perl?
To start with, Visual Basic runs only on PC's and Java isn't even in
Beta yet!
-Mark
--
Mark Friedman
········@us.oracle.com
Oracle Corporation
500 Oracle Parkway
Box 659410
Redwood Shores, CA 94065
The statements and opinions expressed here are my own and do not
necessarily represent those of Oracle Corporation.
In article <······················@bingster.us.oracle.com>,
Mark S. Friedman <········@us.oracle.com> wrote:
>In article <···············@netcom.com> ·····@netcom.com (John Nagle) writes:
>
>* >····@fast.cs.utah.edu (Harold Carr) wrote:
>
>* >>What do programmers who implement and use real programming
>* >>languages like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use
>* >>instead of TCL or PERL?
>*
>* Either Visual Basic or Java is a decent choice for little programs.
>
>Tcl is an embeddable scripting language. Perl is mainly a system
>administration and shell script language. Both are primarily Unix
>based. In what sense are Visual Basic or Java appropriate for the
>typical uses of Tcl or Perl?
>
>To start with, Visual Basic runs only on PC's and Java isn't even in
>Beta yet!
>
A good very high level object oriented language that offers a good compromise
b/w scripting and general purpose development and is not too Unix specific is
Python. Visit http://www.python.org/ for more info. To my knowledge, Python has
stable ports on all sorts of Unix platforms as well as Windows, Windows/NT and
Macs.
-------------------------
Saad Mufti
Personal Library Software
:-> In comp.lang.tcl, ········@us.oracle.com writes:
:Tcl is an embeddable scripting language. Perl is mainly a system
:administration and shell script language. Both are primarily Unix
:based. In what sense are Visual Basic or Java appropriate for the
:typical uses of Tcl or Perl?
:
:To start with, Visual Basic runs only on PC's and Java isn't even in
:Beta yet!
Perl is used for CGI scripting and general tools work, and runs
not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and
many other systems as well. I would not say its use is restricted
to Unix sysadmins, and if you haven't looked at it in the last five years,
then you are probably working under some misunderstandings about the
language.
--tom
Tom Christiansen writes:
>
> :-> In comp.lang.tcl, ········@us.oracle.com writes:
> :Tcl is an embeddable scripting language. Perl is mainly a system
> :administration and shell script language. Both are primarily Unix
> :based. In what sense are Visual Basic or Java appropriate for the
> :typical uses of Tcl or Perl?
> :
> :To start with, Visual Basic runs only on PC's and Java isn't even in
> :Beta yet!
>
> Perl is used for CGI scripting and general tools work, and runs
> not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and
> many other systems as well. I would not say its use is restricted
> to Unix sysadmins, and if you haven't looked at it in the last five years,
> then you are probably working under some misunderstandings about the
> language.
I said that it was primarily a sysadmin and shell script language. To
me that more or less includes CGI scripting and general tools. I did
not say that its use is restricted to Unix sysadmins. And whether it's
ported or not I still believe that it is primarily in use on Unix
systems.
Regardless of agreement on the above, my point (in response to a part
of the message that you edited out) was that neither Visual Basic nor
Java could be said to be appropriate for typical uses of Perl (or
Tcl).
-Mark
--
Mark Friedman
········@us.oracle.com
Oracle Corporation
500 Oracle Parkway
Box 659410
Redwood Shores, CA 94065
The statements and opinions expressed here are my own and do not
necessarily represent those of Oracle Corporation.
From: Des Kenny
Subject: Re: what to use instead of TCL or PERL
Date:
Message-ID: <DGy8uI.EEy@actrix.gen.nz>
In article <··········@archangel.terraport.net>,
Red to Black Management <········@terraport.net> wrote:
> In article <··························@std32044.urich.edu>,
> ·········@urvax.urich.edu (Andrew Shi-hwa Chen) wrote:
> >> > Perl is used for CGI scripting and general tools work, and runs
> >> > not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and
> >> > many other systems as well. I would not say its use is restricted
> >> > to Unix sysadmins, and if you haven't looked at it in the last five years,
> >> > then you are probably working under some misunderstandings about the
> >> > language.
>
>
> I'm presently working with Appware from Novell, it works on macs and PC's.
> If you purchase the CD version both Mac & PC are included. I find it better
> then Visual Basic. You can also write custom objects called ALM's
> for constant reuse. Worth to look at.
>
> Marcel
Are these Objects or "Components"? It is all a bit confusing.
I have seen one definition that makes a strong distinction:
Objects have inheritance and consequently polymorphism.
Components do not have inheritance and so no polymorphism.
I think some people call "Component" systems Object-Based systems in
contrast to Object-Oriented Systems.
The word Component may be a better way to separate out the concepts of
"objects" that belong to an explicit type hierarchy ( object-oriented
inheritance) and "objects" that have no explicit type hierarchy (
encapsulated modules with no explicit ancestors).
Personally I prefer to have an explicit type hierarchy. Components are a
sort of orphan concept, little waif modules that have no sense of
belonging to the big picture of life.
Of course designing a type hierarchy is no overnight task and it is
understandable that some may shy away from it at first blush and lean
towards the apparently simpler component approach. Unfortunately, the
benefits of the more simplistic approach are considerably less than the
more advanced approach.
In the longer term it is a better choice to classify knowledge into a more
manageable , more meaningfull structure than a collection of orphan
components. All science eventually collects information into
classification structures - it is the only way to comprehend and retrieve
the rapidly growing body of knowledge. Type hierarchies are a sign that
software is entering a new phase of maturity as a body of knowledge.
Cheers
Des Kenny
······@swell.actrix.gen.nz
Des Kenny (······@atlantis.actrix.gen.nz) wrote:
: Are these Objects or "Components"? It is all a bit confusing.
: I have seen one definition that makes a strong distinction:
: Objects have inheritance and consequently polymorphism.
Object does not imply inheritance - see Wegner's taxonomy and his
distinction between object-based and object-oriented.
Inheritance is neither necessary nor sufficient for polymorphism. See
Cardelli and Wegner on polymorphism, and consider a subclass that
redefines everything it has inherited.
Inheritance can be used to create useful type relationships including
polymorphism but this is not an inevitable consequence of using
inheritance.
Remember that "better" and "progress" are meaningless in the absence
of a system of measurement and that "more" and "less" are just a
matter of sign convention until related to a real problem. Attempts to
compare programming languages without reference to a system of values,
or a problem to be solved, are a waste of time.
Conjecture:
for all programming languages L there exists some context and system
of values in which L is 'best'.
--
Owen Rees
<····@ansa.co.uk>, <URL:http://www.ansa.co.uk/Staff/rtor.html>
Information about ANSA is at <URL:http://www.ansa.co.uk/>.
Don't forget one very interesting use of Perl -- because of its facility in
manipulating long strings, it's being used in the human genome mapping project
(I think that's what it's called). I wouldn't try that in the other scripting
languages I know of ...
Krishna
There is an "expect"-like package for Perl (was "chat2.pl"; I've
recently posted a revised version, "Comm.pl"). So, you can stay
in Perl (with its robust binary data manipulation, speed, and real
arrays), and still do the same kind of "interaction automation" as
TCL/Expect.
-Eric
In article <··········@access5.digex.net>
········@access5.digex.net (Phil Perucci) writes:
>In article <····················@shamu.csd.sgi.com>,
>Krishna Sethuraman <·······@shamu.csd.sgi.com> wrote:
>>
>>Don't forget one very interesting use of Perl -- because of its facility in
>>manipulating long strings, it's being used in the human genome mapping project
>>(I think that's what it's called). I wouldn't try that in the other scripting
>>languages I know of ...
>
>Or... Expect!
>
>While Perl excels at text-processing, Expect (Tcl-based) is intended for
>"interaction automation". Expect lets you automate utilities such as
>telnet, ftp, passwd - ANYTHING with a character-based interface. Very
>handy for those cgi-bin scripts which call other existing applications.
>
>Search the web for "expect" and "nist" (NIST is the home-site) for more
>info...
>
:-> In comp.lang.perl.misc, ········@access5.digex.net (Phil Perucci) writes:
:Or... Expect!
:
:While Perl excels at text-processing, Expect (Tcl-based) is intended for
:"interaction automation".
Well, perl is a language, and expect is an application. These aren't the
same thing. You're comparing fields with fungus.
There is, however, a perl applications library for expect stuff. Son
of Chat2, is Eric Arnold @ Sun's new expect-like library.
--tom