Home > Archive > Tcl > March 2006 > TCL vs. Perl
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Lisa Pearlson 2006-03-16, 3:58 am |
| Hi,
A month or two ago, I started this discussion about TCL versus other
popular scripting languages. I was very new to TCL, but within a short
time, I fell in love with it. It came as a blessing from the sky, in
helping me quickly develop a binary based internet server. I found out
about TCL via Expect, which was excellent at automating "questions &
answers". I was wondering why I had never heard of TCL before, neither
did my colleagues. Then the discussion I started lead to a myriad of
ideas from others on how to promote TCL.
I'm an experienced C/C++ programmer. Perl claims to be structured in
similar ways, but it's self proclaimed similarity with C is only more
misleading, since basic things like passing pointers (references) and
other things, are like C but different, thus confusing. Odd choice of
weird characters. Why pass references as \$var instead of &var or
&$var, and more of such things.
Anyway, since Perl not only requires, but even seems to encourage
sloppy, unstructured programming, and the use of lots of odd characters
and context based meaning (you declare an array as @var but reference
its members as $var[] and other confusing things that are prone to
error), readibility of Perl code is nearly as challenging as reading
assembler code, thus also the challenge of having it maintained by
another or by oneself a year later.
But, working with Perl minded colleagues, and having been asked to
maintain and improve their sloppy Perl code, I was forced to pick up a
Perl book, a popular one I think..
I couldn't find in it what year it was published, but it's by the
publisher "Osborne", called "The Complete Reference" by Martin C.
Brown.
On the first few pages, it makes a comparison between Perl and other
languages. Comparing it with Python, it says something to the extent
that "Pyton is object oriented, very structured, for structured minded
people.. but I couldn't think of one thing that would make Python
better than Perl" (obviously he doesn't find structure to be
important.. I thought it was one of the most important things for
serious coding).
But more interesting is what it said about TCL. I quote pieces:
"Tcl was never developed as a general-purpose scripting language,
although many people use it as such"
"Strings are null terminated (as they are in C). This means that Tcl
cannot be used for handling binary data."
(first they compare string handling with C, then claim it can not
handle binary data.. Logically this implies that C can not handle
binary data either. Bad comparison, but I'm just saying his statement
is not logical ... must be an old book too, as Tcl handles binary data
just fine).
"Tcl is also generally slower on iterative operations over strings"
"You cannot pass arrays by value or by reference; they can only be
passed by name"
(upvar and uplevel allow for this and is actually even more powerfull,
plus Perl references aren't real references like in C, so I'm not sure
how this makes Perl more powerful or useful in this regard. In perl you
can't define your expected parameters in your subroutines, but have to
parse them in the subroutine body from a generic ARGV style array. You
can do this in TCL too, but also specify them in the function header).
"Perl supports the entire POSIX function set, but Tcl supports a much
smaller subset of the POSIX function set, even using external
packages."
"It should be clear from this description that Perl is a better
alternative to Tcl in situations where you want easy access to the rest
of the OS. Most significantly, Tcl will never be a general-purpose
scripting language."
That TCL is lacking many readily available packages compared to Perl,
due to its large contributing community, is one thing.. but to doom a
language for "never being general-purpose" is a bit of a blunt
statement I think. Perl too started out as 'just a text processing and
listing" tool.
But there are some valid statements made too:
"Tcl is generally slower than Perl", because "strings are converted to
numbers only when calculation is required", "arrays are stored whithin
what Perl would treat as a hash. Accessing true Tcl array is therefor
slightly slower, as it has to look up associative entries in order to
decipher the true values".
"Unlike Perl, which parses the script before optimizing and then
executing, Tcl is a true interpreter. This reduces optimization options
for Tcl."
"same Tcl interpretation technique also means that only way to debug
Tcl code and search for syntactic errors is to actually execute the
code."
I remember the days that simple "basic" could be compiled into
extremely fast binary code.
Perl has binary compiler, but is actually not machien code, but some
code (virtual machine) that is included in the binary together with the
perl opcodes.
I thought any interpreted language could be compiled into machine code.
There are plenty of Tcl packages available, scattered all over the
place. I still believe one of the major advantages and success of Perl
over Tcl is CPAN, an large central collection of packages that are easy
to 'download and install'. The problem with Perl is that uninstalling
packages is not as easy. How is this with Tcl? Isn't it possible to
create such a CPAN like repository for Tcl packages, and bundle Tcl
with a simple 'install <package>" feature, with dependency checking?
Forget about promoting Tcl via magazines or whatever.. first create a
CPAN like network, then tell people about it, otherwise you'll lose
their interest as quickly as you gained it when you don't lower the
barrier for installing and extending and contributing code.
I believe such network should have highest priority for promoting Tcl
to a larger audience. Tcl is actually so easy to learn that it could,
for this reason alone, have an edge over Perl.
Tcl has some weaknesses (that in many cases are its strengths, like
EverytingIsAString). But I don't see why Tcl couldn't be extended to
include some non string data types for speed. From what I understand,
the array is also an exception to the EIAS rule.
Sorry to bring this back up again, but in the last discussion, people
got motivated, and ideas flew all over the place as how to make Tcl a
bigger success (after discussion with some bitterness why Perl and
other languages gained more popularity: being included with default
distributions), we seem to be back where we started. Then someone said
"stop talking, start doing, or nothing gets done". Wise comment, but
one thing was missing.. what should we start doing first?
I strongly believe in a CPAN like network where it's as easy to install
packages as it is to contribute. It could be as simple as "tclupload
<package> <description>" with a "tclsearch <package|description>" and
"tclinstall".
For the actual storage space, if we can not find someone to sponsor the
server space, we could maybe use public mirroring sites, or bittorrent
like networks first.
Are there people who agree with me and my priority list, or have better
ideas? If so, the next thing to do is make a "TO-DO" list, broken up in
concrete steps, and then look for volunteers to take responsibility for
some of these partial steps. The further we break down these steps, the
less time and effort it would cost for people to use as little or as
much as their time to contribute.
I'm sure this thread will include discussions and people willing to
contribute but 'get lost' among other posts, so I'd like to have a
place where people can 'sign up' to contribute. I have no such place
now, no mailing list, or anything. If someone does, please let me
know.. otherwise you can get your name listed by sending an e-mail to
reageer (at) yahoo dot you know, and we can start organizing something
more seriously.
Lisa (alter-ego).
| |
| simon@whiteowl.co.uk 2006-03-16, 3:58 am |
| Can't really reply in detail because I have a day job to do. Just to
note that although in Tcl everything-is-a-string that doesn't mean that
everything-is-only-a-string. In fact Tcl operates a two-object model -
a string and a 'native' type. So the assertion that strings are
converted to numbers when a calculation is required are not true any
more; I think the change to the 2-object model took place with version
8.0 (others will correct me if I'm wrong). It's not just numbers
either.
Simon Geard
| |
|
|
> "Strings are null terminated (as they are in C). This means that Tcl
> cannot be used for handling binary data."
It is not true (I think since 8.0).
http://www.tcl.tk/man/tcl8.4/TclLib/StringObj.htm
command 'binary' is very powerfull for binary operations.
| |
| Robert Hicks 2006-03-16, 7:57 am |
| "External" to Tcl, I think a CPAN like repository would be the one
thing I would definately like. If I was better at Tcl I would start
hacking this. The  things would be that you could really easily do
a Tk interface to it.
Robert
| |
| Gerald W. Lester 2006-03-16, 7:00 pm |
| Lisa Pearlson wrote:
> ...
> But more interesting is what it said about TCL. I quote pieces:
> "Tcl was never developed as a general-purpose scripting language,
> although many people use it as such"
A better statement of fact would have been, "Tcl was not initially conceived
as a general-purpose scripting language, although many people use it as such"
> "Strings are null terminated (as they are in C). This means that Tcl
> cannot be used for handling binary data."
> (first they compare string handling with C, then claim it can not
> handle binary data.. Logically this implies that C can not handle
> binary data either. Bad comparison, but I'm just saying his statement
> is not logical ... must be an old book too, as Tcl handles binary data
> just fine).
Statement is well out of date, this has been false since 8.0.
> ...
> "Perl supports the entire POSIX function set, but Tcl supports a much
> smaller subset of the POSIX function set, even using external
> packages."
> "It should be clear from this description that Perl is a better
> alternative to Tcl in situations where you want easy access to the rest
> of the OS. Most significantly, Tcl will never be a general-purpose
> scripting language."
True and very false. Tcl has extensions that can access most if not all OS
features and is easily extended to access others. Tcl proper does not
provide low level access directly to all OS features, instead it provides OS
independent (and has for at least 10 years) ways to access most common features.
> ...
> But there are some valid statements made too:
>
> "Tcl is generally slower than Perl", because "strings are converted to
> numbers only when calculation is required",
Statement is well out of date, this has been "false" since 8.0. Tcl keeps a
dual representation of data. If you use the value of a variable over and
over again in calculations the contents will not be converted back and forth
to a string. The string representation will be created only when needed --
but the numeric representation will still exists.
> "arrays are stored whithin
> what Perl would treat as a hash. Accessing true Tcl array is therefor
> slightly slower, as it has to look up associative entries in order to
> decipher the true values".
This is comparing apples and oranges here because they have the same "name"
-- he should (I think) be comparing Perl arrays to Tcl lists.
> "Unlike Perl, which parses the script before optimizing and then
> executing, Tcl is a true interpreter. This reduces optimization options
> for Tcl."
Statement is well out of date, this has been "false" since 8.0. Tcl
compiles and optimizes procedures on the fly the first time the are called.
Tcl actually interps the compiled and optimised byte code and not the strings.
> "same Tcl interpretation technique also means that only way to debug
> Tcl code and search for syntactic errors is to actually execute the
> code."
This is true. It is also, I think, true for Perl -- If you create on the
fly a string in Perl and tell it to evaluate it.
> I remember the days that simple "basic" could be compiled into
> extremely fast binary code.
> Perl has binary compiler, but is actually not machien code, but some
> code (virtual machine) that is included in the binary together with the
> perl opcodes.
> I thought any interpreted language could be compiled into machine code.
See statement above.
> There are plenty of Tcl packages available, scattered all over the
> place. I still believe one of the major advantages and success of Perl
> over Tcl is CPAN, an large central collection of packages that are easy
> to 'download and install'. The problem with Perl is that uninstalling
> packages is not as easy. How is this with Tcl? Isn't it possible to
> create such a CPAN like repository for Tcl packages, and bundle Tcl
> with a simple 'install <package>" feature, with dependency checking?
Yes and no. This has been talked about for years. Part of the problem is
that a lot of Tclers, myself included, do not want a CPAN with its tons of
bad and buggy code -- we would rather a higher quality if smaller set of
modules, e.g. TclLib (http://tcllib.sf.net).
> ...
> Tcl has some weaknesses (that in many cases are its strengths, like
> EverytingIsAString). But I don't see why Tcl couldn't be extended to
> include some non string data types for speed. From what I understand,
> the array is also an exception to the EIAS rule.
The correct statement since 8.0 is "Everything can be converted to a string"
-- this is even true of arrays in a way (i.e. [array get myArrayName]) .
> I strongly believe in a CPAN like network where it's as easy to install
> packages as it is to contribute. It could be as simple as "tclupload
> <package> <description>" with a "tclsearch <package|description>" and
> "tclinstall".
>...
Then do it and let us see it.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Donal K. Fellows 2006-03-16, 7:00 pm |
| Lisa Pearlson wrote:
> But more interesting is what it said about TCL. I quote pieces:
> "Tcl was never developed as a general-purpose scripting language,
> although many people use it as such"
What on earth does that mean!? Answers on a postcard please...
> "Strings are null terminated (as they are in C). This means that Tcl
> cannot be used for handling binary data."
That's not been true since, oh, 1997.
> "Tcl is also generally slower on iterative operations over strings"
Depends on the operation.
> "You cannot pass arrays by value or by reference; they can only be
> passed by name"
Actually, Tcl these days passes virtually everything by reference (the
main exceptions are probably selected callback scripts and messages sent
between threads), but values are copy-on-write (i.e. values are cloned
whenever a change to them would make it appear like the value is mutable).
The downside of mutable references (such as Perl and many other
languages have) is that they are amazing sources of mysterious bugs when
a piece of code in one place changes a value that has accidentally been
shared unexpectedly, resulting in a strange change somewhere entirely
differently (often in another module). This is an amazingly confusing
thing to run across as a bug, and Tcl is just about completely clear of
these things.
> "Perl supports the entire POSIX function set, but Tcl supports a much
> smaller subset of the POSIX function set, even using external
> packages."
Perl doesn't support all POSIX stuff actually. I've run across holes in
its coverage in the past. :-) Also, it doesn't do much to make the POSIX
APIs "Perl-like"; using select() for example is really *much* harder in
Perl than in Tcl. And Tcl provides cross-platform versions of virtually
all those APIs that it does support, so your code has a much greater
chance of being ported transparently from Unix to, say, Windows without
changes. Doing so with Perl is... unusual.
> "It should be clear from this description that Perl is a better
> alternative to Tcl in situations where you want easy access to the rest
> of the OS. Most significantly, Tcl will never be a general-purpose
> scripting language."
I think this comes down to the author saying "you guys aren't allowed to
compete and I'll make up rules to say just that, coz yuo iz teh l@m3r
5uxxx0r5!!!!!!!" or something like that. I tend to ignore such foolish
opinions, as they're not usually grounded in fact.
Happily you've spotted these statements for the FUD they are too. :-)
> "Tcl is generally slower than Perl", because "strings are converted to
> numbers only when calculation is required", "arrays are stored whithin
> what Perl would treat as a hash. Accessing true Tcl array is therefor
> slightly slower, as it has to look up associative entries in order to
> decipher the true values".
Well, Tcl arrays are only really comparable with Perl hashes anyway. But
that's not exact, and 8.4 includes support for operations that make
using a variable holding a Tcl list about as fast as Perl arrays. (Yeah,
I know they're not precisely comparable. So sue me.)
> "Unlike Perl, which parses the script before optimizing and then
> executing, Tcl is a true interpreter. This reduces optimization options
> for Tcl."
Untrue. Tcl uses an on-the-fly bytecode compiler. But the level at which
we factored the bytecodes is such that optimizers are less important
than in a language like Perl (where each individual bytecode does quite
a bit less). It's just a different design.
> "same Tcl interpretation technique also means that only way to debug
> Tcl code and search for syntactic errors is to actually execute the
> code."
Tcl has a long history of supporting "foreign" languages. Classic
examples of this are available as the expect and sqlite3 packages. If we
were going to force everything to be simply statically checkable, we'd
throw this well-loved baby out with the bathwater. (You might as well
take Perl to task for requiring the putting of foreign language elements
into strings. It's just a silly argument.) Instead, we leave the
provision of static checking tools to the community to develop; several
are available as third-party products.
Donal.
| |
| Uwe Klein 2006-03-16, 7:00 pm |
| Gerald W. Lester wrote:
> Lisa Pearlson wrote:
>
>
>
> This is true. It is also, I think, true for Perl -- If you create on
> the fly a string in Perl and tell it to evaluate it.
How popular is creating and using code like that in perl or python?
the barrier between code and data is perceived as high
with any typed language, isn't it?
either it is data or it is code never both.
uwe
| |
| Eckhard Lehmann 2006-03-16, 7:00 pm |
|
This thread should be followed up to the perl newsgroup, so that the
guys there see what they should *not* believe from the literature...
Lisa Pearlson wrote:
> There are plenty of Tcl packages available, scattered all over the
> place. I still believe one of the major advantages and success of Perl
> over Tcl is CPAN, an large central collection of packages that are easy
> to 'download and install'. The problem with Perl is that uninstalling
> packages is not as easy. How is this with Tcl? Isn't it possible to
> create such a CPAN like repository for Tcl packages, and bundle Tcl
> with a simple 'install <package>" feature, with dependency checking?
Hmm, many Tcl extensions have very few, if any dependencies.
It is very simple to install and uninstall extensions to Tcl - since
they are loaded from directories living on the ::auto_path variable, it
is just a matter of putting the extension directory with a valid
pkgIndex.tcl file in one of these locations or removing it from there
when it's not longer needed. You can even modify ::auto_path at runtime
to include another directory where extensions are. And Tclkit driven
programming makes depending on the right versions and also the
deployment of them sooo easy...
But  ly we live in a world where people are used to complicated and
confusing installation routines that lead to scattered files and
versions anywhere on your system. Then, there are mechanisms invented
to simplify this process again, called installers. It's all... well -
business as usual. Human beings seem to tend to complicated things.
But I agree with you that the extensions are too scattered on the net -
I am often in the situation of not finding the right thing at the right
time. A solution would be to have the latest releases and descriptions
for them aggregated at http://www.tcl.tk/. That is the first entry
point to Tcl/Tk related information on the net and I think a extension
repository is well placed there. Maybe under the "software" section (I
remember that it was something like this before...)
Extensions should take place there, together with a short description,
a link out to the extension homepage and a direct download link. I
think I have seen such a site somewhen, but it was out of date.
Maintenance could be made easy with a modified wikit, that integrates
in www.tcl.tk. I think the best way is, that extension developers
update/maintain their section in this wiki by themselves.
It would also be a good starting point for installer like scripts - but
I consider this as second requirement. The most important thing would
be aggregation/integration of the scattered extensions.
> Forget about promoting Tcl via magazines or whatever.. first create a
> CPAN like network, then tell people about it, otherwise you'll lose
> their interest as quickly as you gained it when you don't lower the
> barrier for installing and extending and contributing code.
That's what my suggestion above is about.
> Tcl has some weaknesses (that in many cases are its strengths, like
> EverytingIsAString). But I don't see why Tcl couldn't be extended to
> include some non string data types for speed. From what I understand,
> the array is also an exception to the EIAS rule.
Actually, the EIAS rule is visible to the Tcl develper only. Internally
the values are hold in a smart way that makes efficient and fast
conversion at any time possible.
Eckhard
| |
| Cameron Laird 2006-03-16, 7:00 pm |
| In article <dvbtm3$1dor$1@godfrey.mcc.ac.uk>,
Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
>Lisa Pearlson wrote:
>
>What on earth does that mean!? Answers on a postcard please...
| |
|
| "Lisa Pearlson" <reageer@yahoo.com> writes:
>Anyway, since Perl not only requires, but even seems to encourage
>sloppy, unstructured programming, ...
I don't equate allowing "sloppy unstructured programming" with
encouraging same.
I have seen plenty of sloppy unstructured programming in
pedantic-structure languages & it is very hard to fix & improve. I'm
having to do that right now with some badly done Java code & it's a
nightmare compared to a lot of mediocre C & Perl code I've had to work
with.
Because a language forces structure doesn't mean it will result in
good, supportable, reusable code.
A structure-less language can be used to create good, supportable,
reusable code.
It's up to the coder.
>... "Pyton is object oriented, very structured, for structured minded
>people.. but I couldn't think of one thing that would make Python
>better than Perl" (obviously he doesn't find structure to be
>important.. I thought it was one of the most important things for
>serious coding).
The point is a design based on good structure, not that which the
language forces.
As for TCL, I am using it because a RedHat distro comes with Tcl/Tk,
but not with Perl's Tk nor Python's Tk, & I'm working in an
environment where adding the Tk packages is a huge bureaucratic
nightmare. So I use the tool that works, I write good, structured,
supportable, reusable code, & just get on with it.
Oh, yeah, & I tend to view all the object-class-method-template
blither as obfuscation...:-)
--
<> Robert Geer & Donna Tomky | |||| We sure |||| <>
<> bgeer@xmission.com | == == find it == == <>
<> dtomky@xmission.com | == == enchanting == == <>
<> Albuquerque, NM USA | |||| here! |||| <>
| |
| slebetman@yahoo.com 2006-03-17, 3:57 am |
| Lisa Pearlson wrote:
> Hi,
>
> A month or two ago, I started this discussion about TCL versus other
> popular scripting languages. I was very new to TCL, but within a short
> time, I fell in love with it. It came as a blessing from the sky, in
> helping me quickly develop a binary based internet server. I found out
> about TCL via Expect, which was excellent at automating "questions &
> answers". I was wondering why I had never heard of TCL before...
> <snipped lots of stuff>
In addition to other people's replies I'd like to add a few comments:
> "You cannot pass arrays by value or by reference; they can only be
> passed by name"
Arrays aside (why can't Tcl handle it like Jim?) I find Tcl's concept
of variables very similar to C and is very comfortable to think about.
Forget fancy stuff like by-reference or by name. In C, from the
programmer's perspective, there are only two kinds of access to values:
using a variable or using a pointer. Tcl emulates this perfectly
(though some will consider it bad form) by allowing us access to the
variable 'name' as well as the variable itslef (EIAS, by the way, this
is actually a commonly requested 'feature' in C/C++ as witnessed by the
various requests on Usenet of methods to access the symbol table)
Hence getting the value of a variable:
set foo
gettig the value "pointed" to by the variable:
set [set foo]
> I remember the days that simple "basic" could be compiled into
> extremely fast binary code.
> Perl has binary compiler, but is actually not machien code, but some
> code (virtual machine) that is included in the binary together with the
> perl opcodes.
> I thought any interpreted language could be compiled into machine code.
I used to think that too. But Tcl is so much more than just a simple
programming language. The problem is that Tcl code can basically
"intpret" itself. Consider the problem of compiling the eval or source
command. The compiler would need to get the data to be sourced or
evaled so that they can be compiled. In itself this is not so much a
problem but consider the following (very dangerous) code:
set channel [socket www.somehost.com 1337]
fconfigure $channel -blocking 1
set code ""
while 1 {
append code [gets $channel]
if {[info complete $code]} {
puts $channel [eval $code]
flush $channel
set code ""
}
}
Now, how is the compiler supposed to compile code coming in from a
socket? Would the compiled program need to include an embedded compiler
so that the code can be compiled and then executed at runtime?
<snipped the rest>
| |
| Lisa Pearlson 2006-03-17, 3:57 am |
| > Would the compiled program need to include an embedded compiler
so that the code can be compiled and then executed at runtime?
I guess so. Perl also has an eval function, which probably why Perl
compilers do embed a compiler in the exe.
If you include this embedded compiler only for situations where the
eval isn't static piece of tcl code, as part of the compiler
optimization, I think it would be a very useful compiler.
I hardly ever use eval, but not sure what packages do that I use.
Lisa
| |
| Lisa Pearlson 2006-03-17, 3:57 am |
| >Part of the problem is
that a lot of Tclers, myself included, do not want a CPAN with its tons
of
bad and buggy code
Buggy code can hurt the image of Tcl, however, if Tcl is the best thing
out there, but userbase remains very limited because the window display
with lots of useful things is missing and people have to google for
'something that lets me do this', then this will stagnate the
development of Tcl, hurting all of us.
Having a large user base will create more buggy code, but also more
quality code and new tcl applications and additions and tools, we never
dreamed of ourselves before.
You should compare it to debian packages. There are 'experimental' and
'stable' releases. Aside from making it easy for users to contribute
code, one could also make it easy for the community to give feedback on
such contribution that is either "positive" or "nevative" (used for
simple score for star reading) with optional details about 'bug
reports'.
Besides, who decides now that some available tcl packages you can find
(with some difficulty now) is quality and another is buggy? Maybe I
made some quality code, but don't know where to publish it? Yes, you
can figure everything out with some effort.. but that's the whole
issue. It should be minimal effort to participate, and there should be
a central place.
like: pear.php.net
| |
| Lisa Pearlson 2006-03-17, 3:57 am |
| You are right Echhard,
It would be better to start out with a web/wiki based repository,
before tools are built to automate some of these things.
I think packages.tcl.tk would be a good url, with similar repository as
pear.php.net.
It would have a web interface, to view the packages, as well as
HTTP/FTP to the files so they can be easily downloaded/installed and
later easily automated with download/install scripts.
Is something similar to http://pear.php.net also what you had in mind?
Lisa
| |
| Lisa Pearlson 2006-03-17, 3:57 am |
| >I don't equate allowing "sloppy unstructured programming" with
encouraging same.
I didn't make that assumption by false logical deduction, but said "not
only does Perl allow, but even encourage (I mean those behind Perl
philosophy) sloppy programming".
Obviously they don't call it sloppy themselves, but 'powerfull'.
The more cryptic and 'short' you write code, the more it tickles their
nerd-strings.
Rather than writing things out over multiple lines for clarity, they
aim to write it all in a single line.. so their perl code looks like
one big regular expression.
A colleague of mine had a piece of code like this:
if ( $myhash->{body}->{route}->{service}->{protocol} eq 'smtp' ) {
...
} elsif ( $myhash->{body}->{route}->{service}->{protocol} eq 'ftp' ) {
...
} elsif ($myhash->{body}->{route}->{service}->{protocol} eq 'http') {
...
}
My suggestion to write:
my $protocol = $myhash->{body}->{route}->{service}->{protocol};
and test on $protocol rather than write out the hash selection a dozen
times, was answered with "you don't want to use an extra variable when
you don't have to.. it goes against Perl philosophy).
Whateverrrrr.. I don't understand why Perl doesn't have a 'switch'
statement.
Anyway, this is not a good illustration.. look at any perl code and try
to understand it by looking at it.. reading C code is quite a bit
easier than Perl code.. and nobody denies it, but they seem to be proud
of it.
Lisa
| |
| Donal K. Fellows 2006-03-17, 7:57 am |
| bgeer wrote:
> Oh, yeah, & I tend to view all the object-class-method-template
> blither as obfuscation...:-)
It's good for some stuff, and deeply obfuscating for other stuff.
Indeed, going by the evidence of some non-Tcl software I work with, it
takes an object system to attain the true nirvana of obfuscation where
you can stare at a piece of code for days and still not understand it at
all! :-( But a well-designed object system in a suitable domain is a
great help. I suppose it's the usual rule: use the right tool for the
job. (It's just a shame that so many programmers see OO as their only
hammer.)
Donal.
| |
| Torsten Edler 2006-03-17, 7:57 am |
| One challenge would be that the compiled code could be replaced at
execution time:
(bin) 61 % proc y {b} {return [expr {$b -1}]}
(bin) 62 % y 7
6
(bin) 63 % set x {proc y {a} {return [expr {$a + 1}]}}
proc y {a} {return [expr {$a + 1}]}
(bin) 64 % eval $x
(bin) 65 % y 7
8
(bin) 66 %
assume procedure y is in a compiled script, when the eval statement is
executed, the compiled code would have to be discarded, any references
(calls) to the compiled code would be obsolete; not impossible, but
isn't that an interpreter, we would get?
| |
| Cameron Laird 2006-03-17, 6:59 pm |
| In article <1142589255.228198.307900@i39g2000cwa.googlegroups.com>,
Lisa Pearlson <reageer@yahoo.com> wrote:
| |
| Eckhard Lehmann 2006-03-18, 7:56 am |
|
Lisa Pearlson wrote:
> I think packages.tcl.tk would be a good url, with similar repository as
> pear.php.net.
Yes, that is great. packages.tcl.tk sounds very well. We also have to
be aware of the fact that it *must* be an eye catcher - like
pear.php.net is. People get much more easily convinced of something
when it looks good... and Software as well as the Web evolves into
product design more and more.
BTW, I think that wiki.tcl.tk could have a polish too. Some neat, good
looking interface comes always handy.
> Is something similar to http://pear.php.net also what you had in mind?
Not initially - I used PHP sparingly until now and when I used it, I
was always comfortable with the default packages... on Debian/Ubuntu
you can apt-get them and on Windows there is this Xamp thing which
installs everything.
So I have to admit that I have seen pear.php.net the first time yet -
but it makes a very good impression ;-).
The only question is, who should do it? Who is good at
programming/designing web sites and has access to the tcl.tk URL to
place the site there? Once it is there and announced, I am sure that
extension developers will put their packages and descriptions there.
The packages should be organized by category and the site should have a
"latest updates" section as well. Also, it would be good to have a
programs/scripts section where ready to use Tcl/Tk programs can be
browsed an downloaded.
Another point is - as seen on pear.php.net - a feedback/proposals
section where users can request extensions or new features in
extensions and where this can be discussed...
Eckhard
| |
|
|
| Lisa Pearlson 2006-03-18, 6:58 pm |
| First of all, you seem to understand that 'marketing' is an important tool,
and that good things don't usually sell themselves at all. It's a bit
similar to Linux community opposing 'windows based interface', because they:
- believe that linux is for smart people. If you're stupid, you don't
deserve to use it.
- once you memorize and learn all the commands, it's must faster to use
command lines than browse through a GUI.
While these things are true, they:
- put off people, leaving linux for Nerds only.. making it harder for the
technology to escape dusty attics and change the world.
- throw up a steep learning curve, and refuse to add the option for people
to find something even if they don't know what they are looking for, by
walking through GUI's.
In similar fashion, yes, a lot is already available for TCL, but takes some
effort to find it.. and even more isn't available or has never left
someone's dusty attic.
This type of 'nerdish' fundamentalism, that is only focused on technology,
not on the 'glitter' that is needed to leverage and support that technology,
is doomed. It's not one or the other..
The purpose of making TCL popular, is not that popularity itself, but that
it will help grow the available tools, packages and other activity that will
benefit all of us, will allow us to do more, quicker and easier.
And if some don't want to 'bother', because they believe in a lean-and-mean
Tcl only (which should always be possible), and not wish to support, some
even oppose, easy access and contribution, will see yet again, that great
tools and technology, will lose over crappy ones, like Windows vs. Linux,
like Perl vs. Tcl, Like VHS versus Video2000.
Yes, Tcl is just another tool, and Perl is a better choice for some
purposes. But Tcl is not used by the world for what it is much better at,
than Perl. Simply because they don't know about Tcl, or they get frustrated
for not being able to find the right packages because they're either hidden
or don't exist. That's a pity.. and I don't understand why the founders and
contributors for Tcl, don't hurt for this more than I do, who hasn't
invested as much energy in Tcl yet.
I'm quite convinced that making such repository is much less effort than
creating Tcl. So, it's like a great engine, without a shiny wrapper. And the
shiny wrapper is indeed the first thing that will be judged and create the
image.. And when nobody bothers to use Tcl because of it, they will never
see its true beauty and ease.
From personal experience, I am currently using mysqltcl in tcllib, that I
installed as a debian package. I find mysqlctl too limited, and I saw online
that there is a new version that uses namespaces, but I can not install it.
First, I don't know how to install it manually. I can figure it out and
spend half a day on it to do it, but .. I didn't want to bother, like most
people.
I know that there are other mysql interface packages, but I didn't want to
struggle trying to install them, while breaking debian package manager and
versioning..
So, why did I use debian packages at all, rather than manually installing
the most recent version of tcllib package? Well, because it was easy.. and I
wanted to get my job done quickly and not be forced to learn about the
internals right away to get started.. that goes against 'easy to learn Tcl'.
And I'm much more technical minded and knowledgable than the average Perl
user. People are getting their jobs done in Perl, even if it would take them
half the time and effort in Tcl.. but.. they didn't, because Perl was just
so much easier to install, find and install one of the huge collection of
readily available packages.
I love Tcl syntax, ease of use, without losing power and flexibility, or
even much performance.. but I hate everything else about it.. I just can't
find the things I need.. Are there packages available to handle SSL/TLS? Are
there packages to easily create MIME messages and e-mail them? Are there
packages to easily parse XML data?
I'm sure that some or all of these can be answered with YES, but.. I know
for sure Perl has that, and more.. and this difference between Perl and Tcl
is not because of technological differences, but because the community is
big.
So, I'm a bit dissapointed in how few people support this idea of a
repository. It looks like people have run out of time and energy, ... which
makes sense, because the smaller the community, the more each individual is
expected to do, to keep things going.. Things are getting to be harder and
harder to do, compared to other languages like php and perl, because of the
lack of readily available and easily accessible packages.
> The only question is, who should do it? Who is good at
> programming/designing web sites and has access to the tcl.tk URL to
> place the site there? Once it is there and announced, I am sure that
> extension developers will put their packages and descriptions there.
> The packages should be organized by category and the site should have a
> "latest updates" section as well. Also, it would be good to have a
> programs/scripts section where ready to use Tcl/Tk programs can be
> browsed an downloaded.
> Another point is - as seen on pear.php.net - a feedback/proposals
> section where users can request extensions or new features in
> extensions and where this can be discussed...
>
>
> Eckhard
>
I am not as good of a web programmer/designer as those who do it
professionally on a regular basis, but I could get it working.. My time is
limited too, like everybody elses, have 2 jobs, a full time one during the
w and I run my own business with my own clients on wends (go with 4
hours of sleep a night only, and if there were more Tcl packages available,
perhaps I could get more hours of sleep :)). Even so, I'd be willing to
contribute significantly to such a repository.
Perhaps there are readily available repository like web code available (like
discussion board and blogging webpackages).
My problem is that I do not yet know enough about Tcl packages, to know how
to design the website and backend database in the best way.. I have ideas as
to how the site should look and can be browsed, but not enough about the
technical design behind it..
I imagine we start out with some kind of central FTP site, with a directory
structure based on categories, similar to pear.php.net, then a simple
website (php) that lets one browse this directory structure and download
(wget) the package.
But, .. I don't know yet how to manually install packages.. and not break
versioning info.. so I guess I need to study this more deeply, so I can come
up with (tcl based?) script that can automatically wget the package and
install it.
Lisa
| |
| Googie 2006-03-19, 7:56 am |
| Lisa Pearlson wrote:
> I imagine we start out with some kind of central FTP site, with a
> directory structure based on categories, similar to pear.php.net,
> then a simple website (php) that lets one browse this directory
> structure
Tcl! Tcl! :) We have the Rivet! And Tclhttpd!
> and download (wget) the package.
Binary configured [socket] is just fine. It would make the engine
independed from external tools (i.e. Windows hasn't got wget).
> But, .. I don't know yet how to manually install packages.. and not
> break versioning info.. so I guess I need to study this more deeply,
> so I can come up with (tcl based?) script that can automatically wget
> the package and install it.
That's complicated subject indeed. I think that Tcl should go to
unification its packages. Yes, I'm thinking about startpacks.
--
Pozdrawiam (Greetings)!
Googie
| |
| Gerald W. Lester 2006-03-19, 7:56 am |
| Googie wrote:
> Lisa Pearlson wrote:
>
>
> Tcl! Tcl! :) We have the Rivet! And Tclhttpd!
>
>
> Binary configured [socket] is just fine. It would make the engine
> independed from external tools (i.e. Windows hasn't got wget).
>
>
> That's complicated subject indeed. I think that Tcl should go to
> unification its packages. Yes, I'm thinking about startpacks.
>
If you have a web site that contains Tcl packages, then today you can mount
that web site via the HTTP VFS, add the path where you mounted it to
::auto_list, and package require any packages there.
As to installing those same packages on your local system, that may require
privileges that you as the running user does not have.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Uwe Klein 2006-03-19, 6:58 pm |
| Gerald W. Lester wrote:
> If you have a web site that contains Tcl packages, then today you can
> mount that web site via the HTTP VFS, add the path where you mounted it
> to ::auto_list, and package require any packages there.
>
> As to installing those same packages on your local system, that may
> require privileges that you as the running user does not have.
>
is there a cache VFS module one could stack on top?
uwe
| |
| Darren New 2006-03-19, 6:58 pm |
| Googie wrote:
> independed from external tools (i.e. Windows hasn't got wget).
FWIW, Windows has pretty much everything Linux has. The keyword to
search for is "win32". So you'd google {wget win32}.
--
Darren New / San Diego, CA, USA (PST)
"I think these anchovies are spoiled.
They're not flat."
| |
| Uwe Klein 2006-03-19, 6:58 pm |
| Darren New wrote:
> Googie wrote:
>
>
>
> FWIW, Windows has pretty much everything Linux has. The keyword to
> search for is "win32". So you'd google {wget win32}.
there is a good chance to find wget on any linux and bsd out of the box
i dont know about OSX, AIX, SUN*.
But WindowsXP in a standard installation?
uwe
| |
| Darren New 2006-03-19, 6:58 pm |
| Uwe Klein wrote:
> there is a good chance to find wget on any linux and bsd out of the box
> i dont know about OSX, AIX, SUN*.
>
> But WindowsXP in a standard installation?
The same can be said of Tcl. So? ;-)
--
Darren New / San Diego, CA, USA (PST)
"I think these anchovies are spoiled.
They're not flat."
| |
| Earl Greida 2006-03-19, 6:58 pm |
|
"Gerald W. Lester" <Gerald.Lester@cox.net> wrote in message
news:DmdTf.531187$0l5.276892@dukeread06...
>
> If you have a web site that contains Tcl packages, then today
> you can mount that web site via the HTTP VFS, add the path
> where you mounted it to ::auto_list, and package require any
> packages there.
On the surface, this looks like a disaster waiting to happen. Today this
would never work for a commercial product, and does not seem reliable enough
for even a private program. When the Internet, last-mile Internet
connections, and web-sites start having 99.99999% uptime then it might be
useful, but that is years away.
| |
| Eckhard Lehmann 2006-03-19, 6:58 pm |
|
Gerald W. Lester wrote:
Yes, ideally it should be done with Rivet or Tclhttpd - or Websh.
[color=darkred]
> If you have a web site that contains Tcl packages, then today you can mount
> that web site via the HTTP VFS, add the path where you mounted it to
> ::auto_list, and package require any packages there.
The point is to have an unique aggregation of all available packages
where Tcl developers can search/browse/download the extension they
actually need - compiled for their platform and ready to use by just
placing it on ::auto_path or in [myprogram].vfs/lib or elsewhere. It's
about announcing and making the extensions popular, making it *easy*
for users/developers to find them.
I don't know why or how earlier trials to do such a thing failed. But
it is really time now to do it.
> As to installing those same packages on your local system, that may require
> privileges that you as the running user does not have.
It is not necessary to install the package in a place where you don't
have write privileges, once you have *found* it ;-).
Eckhard
| |
| Robert Hicks 2006-03-19, 6:58 pm |
| I have been looking into Tclhttpd recently. That is a very piece
of software.
Robert
| |
| robic0 2006-03-20, 3:57 am |
| On Fri, 17 Mar 2006 15:08:02 GMT, claird@lairds.us (Cameron Laird) wrote:
>In article <1142589255.228198.307900@i39g2000cwa.googlegroups.com>,
>Lisa Pearlson <reageer@yahoo.com> wrote:
> .
> .
> .
> .
> .
> .
>As notorious as the Perl community is for the attitude
>you describe, I assure you that its highest practitioners
>are more sophisticated than to abjure "an extra variable"
>in this way. So, yes, while I agree that confusion and
>fussing about "Perl philosophy" are too common, I hope
>that doesn't inhibit *your* wise use of the language.
>
>I haven't looked into the history of Perl's switchlessness.
>I can tell you a couple of things:
>A. good stylists use hashes and/or block-level
> assignment to $_ or the ternary operator
> to compose source that's arguably more
> powerful than any C-like switching. Here's
> an example for the case at hand:
>
> for ($myhash->{body}->{route}->{service}->{protocol}) {
> /smtp/ and do {...; last;};
> /ftp/ and do {...; last;};
> /http/ and do {...; last;};
> }
Unfortunately for you this:
/smtp/ and do {...; last;};
/ftp/ and do {...; last;};
/http/ and do {...; last;};
is still:
for (@array)
{
if ($_ =~ /smtp/)
{
...
}
else {
if ($_ =~ /ftp/)
{
...
}
else {
if ($_ =~ /http/)
{
...
}
}
You can use elsif to clean it up while still being readable.
For all your fancy jargon, Perl still follows the if/then/else model,
which seems to follow the assembly "jump" conditional model (jne, jr, je, jlt...).
Unless Perl somehow uses different cpu instructions, then its a good bet
nothing more is taking place in your switch statement.
The 'C' switch statement works the same way in assembly. There are *NO*
performance improvement's, unless you want to delineate some cpu instructions
that changes the code path in a more efficient manner than if/then/else...
robic0
| |
| robic0 2006-03-20, 3:57 am |
| On Fri, 17 Mar 2006 15:08:02 GMT, claird@lairds.us (Cameron Laird) wrote:
>In article <1142589255.228198.307900@i39g2000cwa.googlegroups.com>,
>Lisa Pearlson <reageer@yahoo.com> wrote:
> .
> .
> .
> .
> .
> .
>As notorious as the Perl community is for the attitude
>you describe, I assure you that its highest practitioners
>are more sophisticated than to abjure "an extra variable"
>in this way. So, yes, while I agree that confusion and
>fussing about "Perl philosophy" are too common, I hope
>that doesn't inhibit *your* wise use of the language.
>
>I haven't looked into the history of Perl's switchlessness.
>I can tell you a couple of things:
>A. good stylists use hashes and/or block-level
> assignment to $_ or the ternary operator
> to compose source that's arguably more
> powerful than any C-like switching. Here's
> an example for the case at hand:
>
> for ($myhash->{body}->{route}->{service}->{protocol}) {
> /smtp/ and do {...; last;};
> /ftp/ and do {...; last;};
> /http/ and do {...; last;};
> }
>
> This *is* Perl, and there are MANY variations
> on this approach.
>B. There's an existing switch extension <URL:
> http://kobesearch.cpan.org/htdocs/perl/Switch.html >
> which Perl 6 will largely replicate with the "given"
> keyword.
This msg can't be responded to..
| |
| Gerald W. Lester 2006-03-20, 3:57 am |
| robic0 wrote:
> On Fri, 17 Mar 2006 15:08:02 GMT, claird@lairds.us (Cameron Laird) wrote:
> ...
> You can use elsif to clean it up while still being readable.
> For all your fancy jargon, Perl still follows the if/then/else model,
> which seems to follow the assembly "jump" conditional model (jne, jr, je, jlt...).
>
> Unless Perl somehow uses different cpu instructions, then its a good bet
> nothing more is taking place in your switch statement.
> The 'C' switch statement works the same way in assembly. There are *NO*
> performance improvement's, unless you want to delineate some cpu instructions
> that changes the code path in a more efficient manner than if/then/elsane...
Really depends on what machine you are running on and what compiler you are
using now does it not?
I know of one machine that was popular in the 80's and 90's who's assembly
language had as instruction Compute CRC (among many other "high level"
instructions) -- and at least one "high" level language compiler that
generated it (VAX and Bliss respectively).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Lisa Pearlson 2006-03-20, 3:57 am |
| Yes, but Googie's comment is valid.. requiring the user to install wget
for windows, is a hassle, when the whole idea was to reduce hassle.
Indeed, we might as well use tcl's easy to implement interface to
download stuff over http or ftp.
I see great potential for very convenient user experience. It would fit
so well with the rest of TCL experience.. Let's keep this idea hot. I
will try to look into a repository like website, study tcl packages in
more detail.. (like, do we provide packages as source code.. or do some
of them require compiling? I'm sure some do.. perl packages are
downloaded as source, then unpacked, make, make test, make install'ed).
Once the repository is there and people upload their packages, making
an install script should be little effort.. the main thing is just to
get all packages published in one place.
Darren New schreef:
> Googie wrote:
>
> FWIW, Windows has pretty much everything Linux has. The keyword to
> search for is "win32". So you'd google {wget win32}.
>
> --
> Darren New / San Diego, CA, USA (PST)
> "I think these anchovies are spoiled.
> They're not flat."
| |
| Robert Suetterlin 2006-03-20, 7:57 am |
| From Your comments I guess You really never tried to contribute code to
the debian package system. And You most likely never used the stable
Debian distribution. The debian system is neither easy nor up to date.
(Still Debian is very impressive.)
Lisa Pearlson wrote:dd
> You should compare it to debian packages. There are 'experimental' and
> 'stable' releases. Aside from making it easy for users to contribute
> code, one could also make it easy for the community to give feedback on
> such contribution that is either "positive" or "nevative" (used for
> simple score for star reading) with optional details about 'bug
> reports'.
From Your comments I guess You really never tried to contribute code to
the debian package system. And You most likely never used the stable
Debian distribution. The debian system is neither easy nor up to date.
(Still Debian is very impressive.)
> Besides, who decides now that some available tcl packages you can find
> (with some difficulty now) is quality and another is buggy? Maybe I
> made some quality code, but don't know where to publish it? Yes, you
> can figure everything out with some effort.. but that's the whole
> issue. It should be minimal effort to participate, and there should be
> a central place.
sourceforge, c.l.t and wiki.tcl.tk are very central places to
participate. Also IMHO the TIP process is unique in its simplicity and
efficiency to integrate new core features.
| |
| Cameron Laird 2006-03-20, 7:57 am |
| In article <pq7s12drjnp52mfdr54n84v1f6p7c5q7p1@4ax.com>, <robic0> wrote:
>On Fri, 17 Mar 2006 15:08:02 GMT, claird@lairds.us (Cameron Laird) wrote:
| |
| Uwe Klein 2006-03-20, 7:00 pm |
| Cameron Laird wrote:
> B. There's an existing switch extension <URL:
> http://kobesearch.cpan.org/htdocs/perl/Switch.html >
> which Perl 6 will largely replicate with the "given"
> keyword.
Impressive. 32? different types for the switch "object"
to handle that are described with differentiated behaviour.
How do you ascertain that one of these possible types is not your foot?
uwe
| |
| Donal K. Fellows 2006-03-20, 7:00 pm |
| robic0 wrote:
> For all your fancy jargon, Perl still follows the if/then/else model,
> which seems to follow the assembly "jump" conditional model (jne, jr, je, jlt...).
High-performance Perl does something different (forgive me if I get the
syntax wrong here, but I don't write Perl very often):
BEGIN {
%switch = {
smtp => sub { ...; last; }
ftp => sub { ...; last; }
http => sub { ...; last; }
};
}
for ($myhash->body->route->service->protocol) {
eval $switch{$_} if defined $switch{$_};
}
Funnily enough, Tcl 8.5 does something very similar behind the scenes
with some kinds of [switch] too...
Donal.
| |
| Robert Hicks 2006-03-20, 7:00 pm |
| That is incorrect. Perl does have a "switch" statement:
use Switch;
switch ($val) {
case 1 { print "number 1" }
case "a" { print "string a" }
case [1..10,42] { print "number in list" }
case (@array) { print "number in list" }
case /\w+/ { print "pattern" }
case qr/\w+/ { print "pattern" }
case (%hash) { print "entry in hash" }
case (\%hash) { print "entry in hash" }
case (\&sub) { print "arg to subroutine" }
else { print "previous case not true" }
}
I believe it has had this since before 2003 as the perldoc says:
"This document describes version 2.10 of Switch, released Dec 29,
2003."
HTH,
Robert
| |
| Donal K. Fellows 2006-03-20, 7:00 pm |
| slebetman@yahoo.com wrote:
> Compiling, unlike interpreting, is a very slow process. I don't mean
> compiling to bytecodes - which can be done lazily or partially like
> Tcl does. I mean compiling to machine instructions.
That's not necessarily true. Those of you with long memories will
probably remember TurboPascal, and that compiled to machine code pretty
quickly indeed, even on machines that weren't fast 20 years ago (i.e. my
first PC). By contrast, C and C++ have been relatively slow languages to
compile for quite a long time, largely because of the large number of
optimizations that compilers try to apply, and the idiotic system of
header file including as a way of coupling to libraries...
Donal.
| |
| Cameron Laird 2006-03-20, 7:00 pm |
| In article <3jiTf.6580$Bj7.5478@newsread2.news.pas.earthlink.net>,
Earl Greida <eGREGIOUSgrieda@FREEyahoo.commie> wrote:
>
>"Gerald W. Lester" <Gerald.Lester@cox.net> wrote in message
>news:DmdTf.531187$0l5.276892@dukeread06...
>
>On the surface, this looks like a disaster waiting to happen. Today this
>would never work for a commercial product, and does not seem reliable enough
>for even a private program. When the Internet, last-mile Internet
>connections, and web-sites start having 99.99999% uptime then it might be
>useful, but that is years away.
>
>
Ouch! Earl, that sounds so harsh, it makes me think I misunderstand you.
I entirely agree that any reliability assessment needs to examine network
connections critically; sometime we can talk about my feelings regarding
RPC and SOA as a whole. At the same time, there's no question in my mind
that plenty of "commercial products" (hosted backup, CRM, Sun's
Grid-from-the-wire, the Microsoft Live line, eBay and Amazon SOA fixtures,
....) already exist, and work to the extent that salaries are getting paid.
Maybe Gerald has described something with more problems than benefits. I
don't see it that way, though; what makes VFS so nearly-indescribably
is that it makes it easy to switch between "package require ..." resolving
to a remote access (perhaps on a temporary basis, and perhaps with
intelligent caching), and some kind of more conventional local read.
My conclusion: Gerald's suggestion deserves more careful attention.
| |
| Gerald W. Lester 2006-03-20, 7:00 pm |
| Earl Greida wrote:
> "Gerald W. Lester" <Gerald.Lester@cox.net> wrote in message
> news:DmdTf.531187$0l5.276892@dukeread06...
>
> On the surface, this looks like a disaster waiting to happen. Today this
> would never work for a commercial product, and does not seem reliable enough
> for even a private program. When the Internet, last-mile Internet
> connections, and web-sites start having 99.99999% uptime then it might be
> useful, but that is years away.
Cameron point to several Internet applications that work today.
But then, who said it had to be all internet -- you can have local
webservers on your intranet.
Also not all applications need 99.99999% uptime -- I know several successful
commercial sites/application that get no where near that.
Maybe you should start thinking outside of the "it needs to look exactly
like CPAN" box.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Gerald W. Lester 2006-03-20, 7:00 pm |
| Donal K. Fellows wrote:
> slebetman@yahoo.com wrote:
>
> That's not necessarily true. Those of you with long memories will
> probably remember TurboPascal, and that compiled to machine code pretty
> quickly indeed, even on machines that weren't fast 20 years ago (i.e. my
> first PC). By contrast, C and C++ have been relatively slow languages to
> compile for quite a long time, largely because of the large number of
> optimizations that compilers try to apply, and the idiotic system of
> header file including as a way of coupling to libraries...
Donal,
The problem may well be that a large part of the people joining discussions
now have only experienced recent implementations of C/C++/C#/Java and do not
have the historic perspective to understand that the small view of the world
that they have had does not always apply to the entire world.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Uwe Klein 2006-03-20, 7:00 pm |
| Gerald W. Lester wrote:
> Earl Greida wrote:
>
[color=darkred]
[color=darkred]
[color=darkred]
> Also not all applications need 99.99999% uptime -- I know several
> successful commercial sites/application that get no where near that.
repeating my last post on this:
stack a (smart)cache module into vfs ( and there is cvs-vfs),
if its been loaded once the cache will provide it after disconnect.
the smartness will fetch an updated version if and when available.
uwe
| |
| Darren New 2006-03-20, 7:00 pm |
| Lisa Pearlson wrote:
> Yes, but Googie's comment is valid.. requiring the user to install wget
> for windows, is a hassle, when the whole idea was to reduce hassle.
Certainly. My point was not that Googie's comment isn't valid. I just
know many people who think (for example) that Linux is better because it
has Gimp and apache and ... and a whole bunch of other stuff that's been
ported to Windows already. I just thought I'd point out how one finds
such things, if one is using Windows but needs such a tool. My comment
was informational, rather than disputive.
--
Darren New / San Diego, CA, USA (PST)
"I think these anchovies are spoiled.
They're not flat."
| |
| Cameron Laird 2006-03-20, 7:00 pm |
| In article <jbu2f3-8kk.ln1@robert.houseofmax.de>,
Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
| |
| Gerald W. Lester 2006-03-20, 9:57 pm |
| Uwe Klein wrote:
> Gerald W. Lester wrote:
>
> do you put your transferbooth in the living room?
No, I don't put the transferbooth in the living room -- not safe from dialin
thieves if you do!
Of course, right now there is not much of anything in my livingroom (I live
in the New Orleans area -- Katerina you know).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
| |
| Cameron Laird 2006-03-20, 9:57 pm |
| In article <kvFTf.5300$x94.765@newsread1.news.pas.earthlink.net>,
Earl Greida <eGREGIOUSgrieda@FREEyahoo.commie> wrote:
| |
| Donal K. Fellows 2006-03-21, 7:57 am |
| Earl Greida wrote:
> I agree with this. This is the model I have adopted for an application I am
> developing. However, the apps I have written get their packages from
> Tcllib, which is installed on each computer that has Tcl installed. I'm not
> sure how much benefit I will gain by just having Tcllib installed on one
> computer and the other computers attach to it to get the needed packages.
Tcllib's titchy. There's not much need for using live remote versions of
it. But that's definitely not universally true; some libraries are
*much* bigger than the whole of Tcllib, and can gain substantially from
being delivered "just in time".
Donal.
| |
| Donal K. Fellows 2006-03-21, 7:57 am |
| Gerald W. Lester wrote:
> The problem may well be that a large part of the people joining
> discussions now have only experienced recent implementations of
> C/C++/C#/Java and do not have the historic perspective to understand
> that the small view of the world that they have had does not always
> apply to the entire world.
That's why we've got to keep on telling them. Help them understand that
the world is richer than they perceive it to be. I refuse to give up on
this point...
Donal.
| |
| Sektor van Skijlen 2006-03-21, 7:57 am |
| Dnia 17 Mar 2006 01:32:46 -0800, Lisa Pearlson skrobie:
> You should compare it to debian packages. There are 'experimental' and
> 'stable' releases. Aside from making it easy for users to contribute
> code, one could also make it easy for the community to give feedback on
> such contribution that is either "positive" or "nevative" (used for
> simple score for star reading) with optional details about 'bug
> reports'.
I would rather suggest that this be something more like Gentoo's Portage.
Apart of usual storage and dependencies it has also "use flags", which, for
example, state that some package is available only on some platforms, or on
some platforms that package is still unstable.
I don't think that "making buggy packages" is a valuable argument anyway.
Presently we have a situation that both quality and buggy packages can be
found by googling. Some of them don't compile without knowing some strictly
detailed things, like Incr Tcl.
> Besides, who decides now that some available tcl packages you can find
> (with some difficulty now) is quality and another is buggy? Maybe I
> made some quality code, but don't know where to publish it? Yes, you
> can figure everything out with some effort.. but that's the whole
> issue. It should be minimal effort to participate, and there should be
> a central place.
I also think that the problem is not with appropriate storing packages, but
managing them. Just one central place with a list of all available packages
for Tcl (with possibility to fetch and compile them, just like Gentoo Linux
does); then they can be stored elsewhere. With a possibility to report
feedbacks/problems etc.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
| |
| Sektor van Skijlen 2006-03-21, 7:57 am |
| Dnia Mon, 20 Mar 2006 13:27:16 +0100, Robert Suetterlin skrobie:
> From Your comments I guess You really never tried to contribute code to
> the debian package system. And You most likely never used the stable
> Debian distribution. The debian system is neither easy nor up to date.
> (Still Debian is very impressive.)
Yes, of course. But Debian was used as an example of packaging, not as a base
idea. I think it would be better to base rather on Gentoo Portage.
> sourceforge, c.l.t and wiki.tcl.tk are very central places to
> participate.
This will not replace a formalized distribution system with unique
installation procedures and bugreport system.
> Also IMHO the TIP process is unique in its simplicity and
> efficiency to integrate new core features.
This is totally different thing.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
| |
| Sektor van Skijlen 2006-03-21, 7:57 am |
| Dnia 16 Mar 2006 07:55:19 -0800, Eckhard Lehmann skrobie:
> But I agree with you that the extensions are too scattered on the net -
> I am often in the situation of not finding the right thing at the right
> time. A solution would be to have the latest releases and descriptions
> for them aggregated at http://www.tcl.tk/. That is the first entry
> point to Tcl/Tk related information on the net and I think a extension
> repository is well placed there. Maybe under the "software" section (I
> remember that it was something like this before...)
I would rather see software.tcl.tk and updating this way:
% tcsup update
% tcsup install IncrTcl -exact 3.2
# (Will spawn wget, fetch sources, unpack, compile and install)
[TCSUP stands for Tcl Central Software Update Place - or Procedure/Point as
you like :) ]
There may be a problem on Windows; so first tcsup would have to be installed
manually, leaving up to the user, how to use or install support tools, like
wget. On Windows, anyway, packages would be available in binaries only; for
Windows it is enough. This will need only wget, tar and gzip/bzip2 to install.
> Extensions should take place there, together with a short description,
> a link out to the extension homepage and a direct download link.
And issue database.
> I think I have seen such a site somewhen, but it was out of date.
> Maintenance could be made easy with a modified wikit, that integrates
> in www.tcl.tk. I think the best way is, that extension developers
> update/maintain their section in this wiki by themselves.
I think it would be best to have one central point, where new packages with
their homesites and maintainers would be registerred. Bug reports will be
redirected to them also.
> It would also be a good starting point for installer like scripts - but
> I consider this as second requirement. The most important thing would
> be aggregation/integration of the scattered extensions.
Once it is done, this "second requirement" will not be a problem.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
| |
| Adrian Ho 2006-03-21, 7:57 am |
| On 2006-03-21, Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> Gerald W. Lester wrote:
>
> That's why we've got to keep on telling them. Help them understand that
> the world is richer than they perceive it to be. I refuse to give up on
> this point...
In this case, with apologies to Santayana, "those who do not know history
are doomed to repeat the good bits very late, if at all". 8-)
- Adrian
| |
| Sektor van Skijlen 2006-03-21, 10:07 pm |
| Dnia 19 Mar 2006 12:56:51 -0800, Robert Hicks skrobie:
> I have been looking into Tclhttpd recently. That is a very piece
> of software.
Very good. So it has to be easy to make some tclwget?
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
| |
| Jochem Huhmann 2006-03-21, 10:07 pm |
| Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
> Dnia 17 Mar 2006 01:32:46 -0800, Lisa Pearlson skrobie:
>
> I would rather suggest that this be something more like Gentoo's Portage.
> Apart of usual storage and dependencies it has also "use flags", which, for
> example, state that some package is available only on some platforms, or on
> some platforms that package is still unstable.
Suggesting even another system: DarwinPorts. It is written in Tcl
already, handles compilation and even has an GUI tool, also written in
Tcl/Tk (only for OS X now, but oviously quite portable).
It has also the added virtue that is downloads the actual code from its
home site, so it does not need a repository (except for the ports, which
are not much more than some info, optional patches and other meta
stuff).
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
| |
| Sektor van Skijlen 2006-03-21, 10:07 pm |
| Dnia Tue, 21 Mar 2006 17:58:56 +0100, Jochem Huhmann skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
[color=darkred]
> Suggesting even another system: DarwinPorts. It is written in Tcl
> already, handles compilation and even has an GUI tool, also written in
> Tcl/Tk (only for OS X now, but oviously quite portable).
Much better then. Of course, compilation should be available on demand. I
hope it does not use any external tool for fetching and unpacking the
packages?
> It has also the added virtue that is downloads the actual code from its
> home site, so it does not need a repository (except for the ports, which
> are not much more than some info, optional patches and other meta
> stuff).
Gentoo's Portage also does. However Darwin probably will be better as a
template, since Gentoo Portage is scripted in Python.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
| |
| Cameron Laird 2006-03-21, 10:07 pm |
| In article <441c64f4$0$482$e4fe514c@dreader31.news.xs4all.nl>,
Lisa Pearlson <no@spam.plz> wrote:
| |
| Robert Hicks 2006-03-22, 7:06 pm |
| "Regarding a "central repository" for Tcl: I'm personally
discouraged, to the point that I can't offer any useful
counsel."
Is that because it has been "talk" for so long and no "action"?
Robert
| |
| John Perry 2006-03-22, 7:06 pm |
| Robert Hicks wrote:
> "Regarding a "central repository" for Tcl: I'm personally
> discouraged, to the point that I can't offer any useful
> counsel."
>
> Is that because it has been "talk" for so long and no "action"?
>
Yes, there has been action. Steve Cassidy's CANTCL has 30'ish packages
available. I don't know why it hasn't gone any further -- it's been
online several years.
| |
| Sean Woods 2006-03-23, 7:06 pm |
| Ok guys, my chs are sore from being smacked with a guantlet.
Mainly, I am a Tcl developer, and I write TONS of databases in
Tclhttpd, and I am the lord high network engineer at a non-profit with
a really fat pipe to the Internet. Oh yeah, and I have a pretty
domain name: etoyoc.com (also .net .org) that has been lodged into
google for so many years that I could put up a page about "Eskimo Pie
Sand Castles" and it would be on the first item in a search topic the
next time my site's indexed. (Which looking at my logs is several times
daily.)
Here is the plan.
Instead of worrying about indexes and spec files and all that happy
crap, let's index the information into Sqlite. Develop some scripts to
syncronize one's personal repository with a central one (I nominate
me). Downloading packages is cake, use the http package. Sqlite at this
point is compiled for just about everyone's platform and happily runs
inside of the interpretor.
For large collections of objects, our repository will also maintain a
tclIndex file and the paths for Tcl to find them. For every platform we
designate a directory where the packages are installed, preferably
relative to the local Tcl interpretor.
On the developer end, we provide a website with pre-canned forms for
filling in meta-information and documentation. Man files, html pages,
even Latex and PDF documents can be auto-generated by scripts. We
provide an upload button for new versions of the code. We can even
provide an automatically generating test scripts for debugging.
And to add icing to the cake, everything about the package handling
system will itself be a package and be written 100% in tcl.
I'm in the midst of a massive re-write on my intranet application. It
uses a pile of in-house software libraries and itcl code. It will make
an excellent test case to exercise a new package management system.
(I'm currently just dumping the code base to a designated directory and
rsyncing copies to each of the servers that need it.)
I have a website that is currently indexing Magic the Gathering cards.
I'll probably have that reworked by the end of the afternoon at:
tcl.etoyoc.com
-Sean
| |
| lvirden@gmail.com 2006-03-28, 7:04 pm |
|
According to Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>:
:I also think that the problem is not with appropriate storing packages, but
:managing them. Just one central place with a list of all available packages
:for Tcl (with possibility to fetch and compile them, just like Gentoo Linux
:does); then they can be stored elsewhere. With a possibility to report
:feedbacks/problems etc.
The complaints that I generally hear usually fall into these categories:
1. It's too hard to find whether there is an extension I want
2. It's too hard to find the source for an extension that I know I want
3. It's too hard to build the source for an extension that I know I want and
that I've found
4. My employer/customer/whatever doesn't want to use seperately downloaded
extensions - they only want to use tcl... why don't you
put extension XYZ into the tcl core?
Finding the name of an extension, to me, always seemed like a matter
for google. If google isn't finding it, that means that it wasn't
documented well enough or that it doesn't exist, or at least is no longer
around on the internet.
Finding the source, for me, is, typically, the same thing - as long as
the developer still is around on the net. Google works fine for this.
However, the building of the extensions is what is painful. And that's where,
when CPAN works, it's beauty lies. Not as a search engine (though the
editorially controlled categories and descriptions are useful), and not even
as a location from which to download the modules. But the fact that a
common build technology is simple to use. And of course, the biggest failure,
in my mind, are the cases in CPAN where the module writer deviates from the
default structure and the resulting module doesn't build... During this
particular iteration of discussion of the topic, I haven't noticed
(perhaps it has yet to arrive here) anyone discuss potential solutions to
the most critical problem.
And of course, the way to make all of this appear as if the extensions were
a part of Tcl, would be to have a single command, which when executed, would
download tcl and build it (or optionally download a pre-built tcl), and then,
when additional extensions are required, would download those in the same
fashion. So that the entire database of software would be, in essence, one
integrated environment, where the addition of an extension isn't seen as
something seperate. And of course one would want an interface where problems,
when reported, would get routed to the appropriate developer (or a team
which would then assign appropriately).
--
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
|
|
|
|
|