Project size
Robert Hicks
Is there a "too big" for Tcl limit that you would self-impose?
Robert
Gerald W. Lester
> I am curious about the size of projects you are using Tcl for...
>
> Is there a "too big" for Tcl limit that you would self-impose?
If by large, you mean lines of code:
For the last couple of years Oracle and Cisco have been trading places for
who has the largest Tcl based project -- last number I remember hearing is
around 15,000,000 lines of code and I think that was from Oracle.
If by large, you mean number of users at the same time:
Of course AOLserver is used for very large number of users (don't know what
AOL's maximum user count has been over the years).
If by large, you mean number of programmers:
The largest I've seen on one project was about 20.
I guess the big question is what do you mean by large?
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Helmut Giese
>I am curious about the size of projects you are using Tcl for...
>
>Is there a "too big" for Tcl limit that you would self-impose?
from that I would answer: No, never.
I'll explain: Besides Tcl the languages I am fluent in are Pascal, C
and C++. I could probably get along with Java but that's unimportant
for the following.
Given this background and being asked the question above, what would
be realistic alternatives to Tcl? None of the above, simply because
code size would explode by a factor of 5, maybe even 10, making the
project even less manageable.
Let's put it this way: Everybody has a limit (LOC is not everything
but it is usually a good unit of measurement) beyond which things
become difficult: Once the project (or the part of it under your
responsability) grows beyond this limit, you lose the overview, you
cannot remember the whole API any more, you spend more and more time
looking thngs up - in short, from a certain point on productivity
declines.
(It doesn't matter, that this limit will be different for different
developers: I lose overview at 30,000 LOC and you can keep the
functions of a library of 80,000 LOC in your head - congrats, but the
point remains: Once this limit is passed, things will get more
complcated.)
Ok, so you bring in more people. But now you have a growing
communication overhead, you have to define interfaces etc. and - as
probably all of us know - you have to allocate more and more time to
meetings, in order to (hopefuly) assure, that in the end all the parts
fit together. This observation is of course true no matter which
language you use.
So my summary is: If you have a really big project, switching to one
of the above languages would make things a LOT worse - so stick with
Tcl.
-----------------
During proof reading I just realized that all I wrote above was based
on the assumption that the alternative to Tcl would be one of Pascal
.. Java. If that's not the case but the alternative would be another
scripting language, than all I wrote above is moot and beside the
point - sorry for wasting bandwidth .)
It's true for me, though, since Tcl is the only scripting language I
truly know.
Hm, somehow your question must have switched on my narrative mood.
Best regards
Helmut Giese
Robert Hicks
Gerald W. Lester wrote:
> Robert Hicks wrote:
> > I am curious about the size of projects you are using Tcl for...
> >
> > Is there a "too big" for Tcl limit that you would self-impose?
>
> If by large, you mean lines of code:
>
> For the last couple of years Oracle and Cisco have been trading places for
> who has the largest Tcl based project -- last number I remember hearing is
> around 15,000,000 lines of code and I think that was from Oracle.
>
>
> If by large, you mean number of users at the same time:
>
> Of course AOLserver is used for very large number of users (don't know what
> AOL's maximum user count has been over the years).
>
>
> If by large, you mean number of programmers:
> The largest I've seen on one project was about 20.
>
>
> I guess the big question is what do you mean by large?
>
One of the reasons I ask is that I am think Tcl is it for me and I can
learn that and then "C" when I need to speed parts up. Plus learning
"C" might get me to the point where I could help out with the Tcl core
(or something along those lines).
:Robert
Cameron Laird
Robert Hicks <sig...@gmail.com> wrote:
.
.
.
>15,000,000?!? Wow, that is what I would consider big.
>
>One of the reasons I ask is that I am think Tcl is it for me and I can
>learn that and then "C" when I need to speed parts up. Plus learning
>"C" might get me to the point where I could help out with the Tcl core
>(or something along those lines).
>
>:Robert
>
A. While many of us have idiosyncratic and passionately-
defended notions of where "big" begins, I haven't many
anyone yet who argues that 15,000,000 SLOC is anything
but.
B. Feel free to regard Tcl as universally-applicable until
you see strong evidence to the contrary. There are
shockingly few domains where Tcl simply doesn't belong.
You can go a long way with just Tcl.
Cameron Laird
Helmut Giese <hgi...@ratiosoft.com> wrote:
.
.
.
>Given this background and being asked the question above, what would
>be realistic alternatives to Tcl? None of the above, simply because
>code size would explode by a factor of 5, maybe even 10, making the
>project even less manageable.
.
.
>So my summary is: If you have a really big project, switching to one
>of the above languages would make things a LOT worse - so stick with
>Tcl.
.
.
SO TRUE.
My experience teaches me that, just after someone says, "This job
is too big for Tcl," he'll soon suggest an alternative that is far
more problem than solution. Helmut's points deserve reiteration.
Robert Hicks
Thanks that was a really good summary. As far as language it would
either be Perl or Tcl as those are the ones I know most. I like the Tcl
community better and I think that the overall install of Tcl is easier
to maintain than Perl (at least for me).
I have ideas...I just have to get better at Tcl. : )
:Robert
Tom Conner
"Gerald W. Lester" <Gerald...@cox.net> wrote in message
news:wiqFg.509$xk3.437@dukeread07...
> Robert Hicks wrote:
> > I am curious about the size of projects you are using
> > Tcl for...
> >
> > Is there a "too big" for Tcl limit that you would self-impose?
>
> If by large, you mean lines of code:
>
> For the last couple of years Oracle and Cisco have been trading
> places for who has the largest Tcl based project -- last number
> I remember hearing is around 15,000,000 lines of code and I think
> that was from Oracle.
>
I know the Cisco uses Tcl for software test automation. Does this
15,000,000 represent a single project, or is it just the cumulative total of
a lot a individual Tcl test cases?
Dennis LaBelle
> Hi Robert,
>>I am curious about the size of projects you are using Tcl for...
>>
>>Is there a "too big" for Tcl limit that you would self-impose?
> well, 'never' is a big word which one should rarely use, but apart
> from that I would answer: No, never.
>
> I'll explain: Besides Tcl the languages I am fluent in are Pascal, C
> and C++. I could probably get along with Java but that's unimportant
> for the following.
> Given this background and being asked the question above, what would
> be realistic alternatives to Tcl? None of the above, simply because
> code size would explode by a factor of 5, maybe even 10, making the
> project even less manageable.
>
> Let's put it this way: Everybody has a limit (LOC is not everything
> but it is usually a good unit of measurement) beyond which things
> become difficult: Once the project (or the part of it under your
> responsability) grows beyond this limit, you lose the overview, you
> cannot remember the whole API any more, you spend more and more time
> looking thngs up - in short, from a certain point on productivity
> declines.
>
.
.
.
That's why I like to shrink a problem's (or project's) size as much as
possible. TCL/TK helps me do this with great success. By shrinking the
problem it can be easier to convince others to start the project.
Unfortunately, some people assume that certain programming problem's are
inherently large and want to use a "standard" (i.e., popular) language to
get the job done "right". With a broader perspective, however, they might
realize that they could actually reduce the problem size (by choosing
another technology e.g., scripting, TCL/TK) to the point where it is quite
easy to do.
Dennis LaBelle
Donal K. Fellows
> My experience teaches me that, just after someone says, "This job
> is too big for Tcl," he'll soon suggest an alternative that is far
> more problem than solution. Helmut's points deserve reiteration.
My experience is that the only reason for switching is if it lets you
gain a lot through some other factor, e.g. someone has already written
a library that does almost exactly what you want. Indeed, the process
of switching itself is painful; without a big payoff at the end, it's
bound to be a net loss. That's probably true even with switching *to*
Tcl, though we've got some excellent payoffs available. :-)
Donal.
Neil Madden
[...]
>
> One of the reasons I ask is that I am think Tcl is it for me and I can
> learn that and then "C" when I need to speed parts up. Plus learning
> "C" might get me to the point where I could help out with the Tcl core
> (or something along those lines).
This is the right way to think of it -- Tcl has much better facilities
for abstraction and code organisation than C does (e.g., namespaces,
various OO extensions, packages, garbage collection/ref-counting,
ability to define your own control structures, etc), so you should use
Tcl to structure the in-the-large design of your program and then use C
to micro-optimise those places that really need it. If you are
programming large systems your number one priority should be to reduce
the size/complexity of the system as much as possible. This is contrast
to much of the "enterprise" programming literature which seems to assume
that programming large systems is an end in itself.
Not that Tcl is without problems for large-scale programming.
Performance might be an issue if you have enough interacting components.
As projects get larger the benefits of static typing become more
compelling, unless you really like writing lots and lots of test cases.
But I'd be much more inclined to turn to Haskell/OCaml than C/C++/Java.
At least, not until those languages at least get closures (possible for
C++0x and Java 7, AIUI).
-- Neil