Tcl/TK is indeed dying
Rodericus
minimalistic and expresive, low weight and extensible, lisp and C
similar, ideal for embedding it in other programms. Now it is getting
fat and "object oriented" with a lot of unnecesary "features" that
would belong to extensions for special purpose applications. It is
getting a "Cool Programming Language (CPL)" for cool people, not any
more a "Tool Command Language". I think, a splitting and a renaming of
the cool language to something like Cpl/Tk#++ would have been a much
better approach. I think this is the result of having very good
developers not knowing what to do. Please, dont consider this posting
a flame war provocation: it is my oppinion.
Rodrigo Readi
APN
Father's Tcl" (nyf-T, how's that for a new language name - nifty,
no?). But that is a good thing.
Personally, I feel many/most of the new features greatly expand the
scope and size of software systems you can build using Tcl. So I
suppose that means it is no longer restricted (if it ever was) to be
solely viewed as "tool" language. In that sense, I understand your
point of view but if you feel a language should not "grow" features,
what's preventing you from sticking with older, smaller versions (even
Tcl 7.6) for embedding?
/Ashok
Kevin Kenny
It's hard to ignite a flame war here. :)
I'm sorry that recent developments make the language fail to serve your
needs. Alas, you really have not given me much to go on to address
your criticism. Most such complaints fall into two major categories.
Either the complaint is that the image has become too large to
fit comfortably on smaller machines, or that the language has
become too difficult to learn.
Regarding the first complaint (that the language doesn't fit any more):
Many of us have had the experience that even "small" platforms
have grown over time, Moore's Law being what it is. A couple of
megabytes of object code would have been quite a large program
when Tcl was introduced, but now represent a smallish library that
can be included almost without thought on anything bigger than a
handheld platform.
Over the last decade or so, there have been several attempts to get
a group of people to evolve the language from a base of Tcl 6.7 or
Tcl 7.6 so that a tiny version is available for those who live with
such tight constraints. They haven't been very successful. My guess
is that it represents a vanishingly small niche: small platforms
for which the vendor offers user-programmability and that aren't
capable enough for a newer version. That immediately rules out
most mobile devices. Mobile vendors view applications as
a profit centre, and typically forbid user programming; the iPhone
application store, widely castigated by developers, is actually
nearly the most open model out there!
Moreover, small platforms that are not tied to the telephone system
tend to be deeply embedded in devices. Those that have the resouces
to develop for such beasts also have the resources to pull a smaller
Tcl over from SourceForge and adapt it to there needs. Since older
versions do get downloaded occasionally, I presume there are still
developers doing just that.
If the complaint is rather that the abundance of new features has
made the language too hard to learn, I have sympathy, but not much
to offer. Surely freezing the language and not offering new development
would also be a "death strategy;" the choice of what goes in and what
stays out is quite a narrow tightrope to walk.
Object orientation,
to use your example, is something that has been extremely widely
demanded, and for which at least half a dozen mutually incompatible
extensions had been in wide use. All of the extensions suffered from
performance (and usually stability) issues, caused in large measure
by the failure of the core language to export appropriate interfaces
for them to use. It seemed to me that the existence of multiple
extensions for the same task, and the immense difficulty of getting
those extensions to perform adequately, was a compelling argument
that we had here a missing core language feature. Moreover, OO
as specified in TIP 257 does not (thankfully!) make Tcl into an
aggressively "object oriented" language like Java or Python. A
programmer can ignore the '::oo' namespace entirely and still
contrive to lead a useful life without it.
Reading between the lines, I suspect that your posting may also
be suggesting that you feel that we have neglected something
more important, in favour of implementing features that offer you
little benefit. In that case, it would be more effective for you
to lobby affirmatively for the development you need. But you have
to recognize that volunteers, as we are, have a complex set of
motivations. An all-volunteer initiative is somewhat unpredictable
in its direction.
The compensating advantage is that development is open. You can
help steer things, either by contributing your own time and effort,
or by paying someone else to do so. And there are developers out
there who would be happy to take on core-improvement efforts for
pay. Alas, the good ones are expensive, but isn't that always the
way of it?
In short, you can't please everyone. If your priorities are enough
different from ours that you no longer find Tcl tenable, I for
one wish you well with whatever language suits you needs better, and
we part friends.
--
73 de ke9tv/2, Kevin
Les Cargill
SFAIK, you can still download and use the older releases of the
language.
--
Les Cargill
Arndt Roger Schneider
>To borrow an old slogan from oldsmobile, this indeed is "Not Your
>Father's Tcl" (nyf-T, how's that for a new language name - nifty,
>no?). But that is a good thing.
>
>Personally, I feel many/most of the new features greatly expand the
>scope and size of software systems you can build using Tcl. So I
>suppose that means it is no longer restricted (if it ever was) to be
>solely viewed as "tool" language. In that sense, I understand your
>point of view but if you feel a language should not "grow" features,
>what's preventing you from sticking with older, smaller versions (even
>Tcl 7.6) for embedding?
>
>
>
[snip]
support.
M. Strobel
Did you have a look at eTCL?
/Str.
Kevin Walzer
Lua is emerging as a popular small language for embedded scripting.
Perhaps that might meet your needs better.
I would, however, disagree that Tcl is getting bloated. Even with object
orientation being added to the core (which is an optional feature, not
something you must use), it's still a very compact language. Sometimes,
in fact, Tcl is insufficient for my needs, and so for certain projects
I'm using Python instead.
As always, use the right tool for the job.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Gerald W. Lester
You have the sources.
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Gerald W. Lester
> .... Sometimes,
> in fact, Tcl is insufficient for my needs, and so for certain projects
> I'm using Python instead.
Kevin,
Out of curiousity where are you finding Tcl insufficient?
Arndt Roger Schneider
> Arndt Roger Schneider wrote:
>
>> APN schrieb:
>>
>>> To borrow an old slogan from oldsmobile, this indeed is "Not Your
>>> Father's Tcl" (nyf-T, how's that for a new language name - nifty,
>>> no?). But that is a good thing.
>>>
>>> Personally, I feel many/most of the new features greatly expand the
>>> scope and size of software systems you can build using Tcl. So I
>>> suppose that means it is no longer restricted (if it ever was) to be
>>> solely viewed as "tool" language. In that sense, I understand your
>>> point of view but if you feel a language should not "grow" features,
>>> what's preventing you from sticking with older, smaller versions (even
>>> Tcl 7.6) for embedding?
>>>
>>>
>>>
>> [snip]
>>
>> support.
>
>
> You have the sources.
>
Support as in support by a community speaking a language.
A language spoken by a single person ceases to be a language
and becomes a cypher.
It's not a technical matter.
-roger
sleb...@gmail.com
In that case what's preventing you from ignoring new features?
note: Although arrays were introduced a very long time ago I only
started using it around 2004 simply because I wanted to ignore new
stuff. Similarly I'm still not using dicts opting instead for [foreach
{x y} ...] processing of key-value lists (which is basically what
dicts are). Old habbits die hard and tcl, unlike some other languages,
allow me to keep using my old habbits.
Arndt Roger Schneider
>On Dec 14, 1:06 am, Arndt Roger Schneider <arndt.ro...@web.de> wrote:
>
>
>>APN schrieb:
>>
>>
>>
>>>To borrow an old slogan from oldsmobile, this indeed is "Not Your
>>>Father's Tcl" (nyf-T, how's that for a new language name - nifty,
>>>no?). But that is a good thing.
>>>
>>>
>>>Personally, I feel many/most of the new features greatly expand the
>>>scope and size of software systems you can build using Tcl. So I
>>>suppose that means it is no longer restricted (if it ever was) to be
>>>solely viewed as "tool" language. In that sense, I understand your
>>>point of view but if you feel a language should not "grow" features,
>>>what's preventing you from sticking with older, smaller versions (even
>>>Tcl 7.6) for embedding?
>>>
>>>
>>[snip]
>>
>>support.
>>
>>
>
>In that case what's preventing you from ignoring new features?
>
>
>
*me*? Nothing.
My answer is about why not to stick with an extremely old versions.
>note: Although arrays were introduced a very long time ago I only
>started using it around 2004 simply because I wanted to ignore new
>stuff. Similarly I'm still not using dicts opting instead for [foreach
>{x y} ...] processing of key-value lists (which is basically what
>dicts are). Old habbits die hard and tcl, unlike some other languages,
>allow me to keep using my old habbits.
>
>
I think, you did miss the point of the original posting.
To remind you: the author complained that the Tcl language resembles
every other language out there and this goes against the fundamental
design of said Tcl-language.
He got a point there.
-roger
David N. Welton
> Lua is emerging as a popular small language for embedded scripting.
> Perhaps that might meet your needs better.
Another thing worth considering that I haven't seen in this thread so
far is Jim:
It's very small and compact, and is actively used for eCos, which is
an embedded operating system targetting fairly small systems.
Arjen Markus
You beat me to it :).
Regards,
Arjen
Donal K. Fellows
> Tk/Tk was my predilect language for small programms, because it was
> minimalistic and expresive, low weight and extensible, lisp and C
> similar, ideal for embedding it in other programms.
As others have noted, the definition of lightweight has changed over
time. Moore's Law applies at the bottom end too, and not just by
driving down the cost of the baseline. Given that, Tcl's increases in
size are relatively reasonable.
> Now [Tcl] is getting fat and "object oriented" with a lot of
> unnecesary "features" that would belong to extensions for special
> purpose applications.
There's quite a few people who disagree with you. But for further
progress to be made, we need to identify if you're displeased with
having an object system in Tcl itself specifically or an example of
what you feel to be a wider problem. With respect to objects-in-Tcl,
it's actually quite a small feature, and mainly serves to help clean
out the Augean mess that was the homebrew OO system scene (you might
not have noticed it, but it definitely was there). It's not about
doing anything nasty like changing the fundamental value system of
Tcl!
Looking at the wider issue, I think it's hard for me to grasp how to
answer your point. Tcl has features because someone wanted them and
persuaded others that adding the feature was a good idea. Almost all
of them are useful for many things (though I'd be surprised if you
found all useful for you; different apps need different subsets).
If you'd really wanted to complain, you'd have picked on things other
than the object system. The unicode support is pretty large (what with
all the encodings and memory implications) and the new [clock] command
is sizable too. Yet these things seem popular too. (A truly-aimed barb
would be [unload].)
> It is getting a "Cool Programming Language (CPL)" for cool people, not
> any more a "Tool Command Language". I think, a splitting and a renaming
> of the cool language to something like Cpl/Tk#++ would have been a much
> better approach.
There's another language called CPL already.
Generally, I've looked at splitting Tcl into several pieces to make it
easier to strip out things not wanted by the hardcore embedders, but
it's difficult. The things that are easy to remove tend to be the
things that a large preponderance of scripts want, and which are
pretty small too. The large parts that embedders think they don't need
are right at the core of what modern Tcl is.
> I think this is the result of having very good developers not
> knowing what to do. Please, don't consider this posting a flame war
> provocation: it is my opinion.
I think you slightly failed in the targeting of your post, you know.
It feels like a provocation. It feels like an insult. It also feels
like a railing rant against the changing of the world. Generally
speaking, saying "thus far and no further" without a deeply principled
reason for saying it, well, it doesn't tend to earn much respect or
notice. The crowd just streams past you.
I'll get off your lawn now. :-)
Donal.
jr4412
<donal.k.fell...@manchester.ac.uk> wrote:
> I think you slightly failed in the targeting of your post, you know.
> It feels like a provocation. It feels like an insult. It also feels
> like a railing rant against the changing of the world.
no man. the original post makes an excellent point -- Tcl is
undergoing change for change's sake, it is getting feature heavy,
trying to supply all programming paradigms to all men, nothing like
Ousterhout's original aim.
"Tcl was born of frustration. In the early 1980s my students and I
developed a number of interactive tools at the University of
California ... the command language for one tool was never quite right
for the next tool ... fall of 1987 it occurred to me that the solution
was to build a reusable command language." (from the Preface to JK
Ousterhout 'Tcl and the TK Toolkit').
rather than feeling "provoked" tell me why modern Tcl is becoming more
and more indistinguishable from the Python's, Ruby's, Perl's of this
world.
you say: "Tcl has features because someone wanted them and persuaded
others that adding the feature was a good idea."
I say, that how Windows (TM) came about ;(
anyway, FWIW, I share Rodericus concern that Tcl/Tk has lost its way.
Rodericus
Etcl, lua, jim: I will see them , but I do not think they are the
alternative, for example due to licence, due to object orientation
that I do not like.
Using an older version (7.6) is not the solution, due to mantainace: C
compiler and OS developes/mutates. I also do not condemn every
developement, I like for example the idea of stackles bytecode engine.
I do not like the inflation that goes against the original idea of Tcl/
Tk. This inflation is specially patent in 8.5 and 8.6, so that a split
would be a good idea. Why are there now widgets that do escentially
the same? Only because the new ones are prettier?
I do use old computers, with few RAM. Tcl is a language for binding it
to other programs, Tcl may be used also for embeded systems: Small
image is a very important feature, it is part of the concept of tcl.
Cool features is not what I expect from Tcl/Tk, and much less if they
make it unnecessarily fatter, even if it makes it only a little
fatter.
Indeed I can ignore the new cool features and use Tcl/Tk as usual. The
usual things remains easy to learn. The problem begins, when many
people are involved in the developement and everyone must read what
other write. It was part of the concept of Tcl that it is easy to
learn and minimalistic.
Tcl/Tk ist an extensible language. Cool Extensions, cool features,
cool object orientation can be added as extension, but the core of the
language is the false place. As long as extensions are written and
hence the language used, the language is not death. Those writing
extensions could perfectionate the core language: in its original
spirit. This is not a death strategy. I continously use Tcl with
databases, but never expected that an API be added. I dont need png as
native image format, I use for example the API of graphics magic in a
small application I am writing. I used many times the extension for
processing SGML (Cost).
That object orientation was added, says a lot. I would be much happier
seing a goto statement in the language. Object orientation is good for
making big programs readable, although it hides algorithms and hence
adds inefficiency. Programming with "goto" is much easier and makes
programs more efficient, but programs are less readable, big programs
perhaps unreadable. The question is now, if Tcl/Tk is a language for
big programs or small ones. That Tcl/Tk works with big programs proves
that the language is stable and realiable, but writing big programs
with Tcl/Tk remains an abuse. There are a lot of languages for big
programms.
Somewhere in the TK source, where it is shown that TK can work with
unicode, it appears in many languages the greating "hallo world" or
something similar. Only in hebrew its stays something different:
"Jerusalem, Israel" in hebrew letters. (In arabic in should stay
"Jerusalem, Palestine"). This issue shows, that arbitrarity is
imposing itself: giving Jerusalem to the european jewish colonists is
becomming more important than the concept of Tcl.
Rodrigo Readi.
Rodericus
Kevin Walzer
> Kevin Walzer wrote:
>> .... Sometimes,
>> in fact, Tcl is insufficient for my needs, and so for certain projects
>> I'm using Python instead.
>
> Kevin,
>
> Out of curiousity where are you finding Tcl insufficient?
>
>
Python has better support for some things than Tcl in its standard
library or extensions:
1. A complete parser for Atom/RSS feeds, Mark Pilgrim's Feedparser.
2. A complete implementation of SSH support, paramiko.
I realize these things are probably technically possible in Tcl, but I
don't have time to code them myself, so Python is a better tool for
projects requiring these capabilities.
--Kevin
Bruce Hartweg
> I think, you did miss the point of the original posting.
> To remind you: the author complained that the Tcl language resembles
> every other language out there and this goes against the fundamental
> design of said Tcl-language.
>
> He got a point there.
>
seemed more like an opinion, rather than a point.
Bruce
Arndt Roger Schneider
> Arndt Roger Schneider wrote:
>
>> I think, you did miss the point of the original posting.
>> To remind you: the author complained that the Tcl language resembles
>> every other language out there and this goes against the fundamental
>> design of said Tcl-language.
>>
> how so? - what is "The fundamental design of Tcl" ?
Message-ID:
<62f4746b-9a02-4720...@d21g2000yqn.googlegroups.com>
... did make a present out of my own copy of Ousterhout's book many
years ago,
so thanks for posting it for me :-)
>> He got a point there.
>>
> seemed more like an opinion, rather than a point.
>
> Bruce
His opinion is: that Tcl/Tk should follow its initial design,
but I guess here. He made a point and has an opinion--
-roger
Shin
Hi,
you'll never find a "pure doctrin" named Tcl. Even in it's earliest
versions Tcl had a lot of syntaxes like simple function call, object
orientation and commands/subcommands constructs. Categorised such, Tcl
has never been a minimalistic language. Actually, there is no language
"Tcl", but a bunch of syntaxes for your comfort. - IMO Tcl is more
like a meta-language for creating problem oriented scripting languages
and so doesn't pull every new concept into a syntactically predictable
form. It's pure freedom ;)
tom.rmadilo
"Probably technically possible"?
Basically you are blaming Tcl because it is missing an application you
want to use. I have python on my machine, but it doesn't have an Atom/
RSS parser.
Problem is, if I was interested in Atom or RSS feeds, I might want to
maintain some kind of database of the feeds. But neither Python or Tcl
have real database capabilities. For that I would need to install
another application and communicate with it. This is where Tcl ends up
being ahead of the game. It could use any available RSS parser and
store the results in a database. Tcl would also be very good at the
server side of Atom or RSS.
As far as parsing this stuff, one problem is the poor quality of the
XML which is generated. But if it is valid XML, the Tcl community has
developed two different parsers. As someone who has developed an XML
application in Tcl (tWSDL/TWiST, which requires parsing, processing
and generating XML documents), I can tell you Tcl works very well.
Since the next fad is probably JSON, note that we have two pure Tcl
packages for that data structure...although my version can only round-
trip data from JSON to tcl list and back. It lacks a clean interface
for creating a JSON structure. But you can validate a JSON structure
via a web interface: http://junom.com/json/json.tcl
Hopefully Tcl (the language) will remain insufficient for everyone's
needs, I mean, the list of built-in Tcl commands is only one browser
sized page. It is also very hard to argue that the number of new
commands add bloat. For all the additional bloat, certain things have
simplified code development: namespaces, auto-initializing incr
variables and lists, portable arrays (dict). Also things have been
sped up by compiling some scripts into bytecodes.
And yet Tcl remains insufficient for my needs. Thankfully I know how
to write library and application code to build up to something which
is sufficient.
Donal K. Fellows
> But neither Python or Tcl
> have real database capabilities. For that I would need to install
> another application and communicate with it.
Well, the sqlite3 package will do. There are other database interfaces
too, some of which are to embedded DBs (i.e., the implementation is
built in to the interface) and others are to remote database servers.
You get to choose which you want to use. That's one of the *great*
things about Tcl, that you can easily extend it with extra
functionality through packages, your own code, or through calling
external programs.
Donal.
Óscar Fuentes
[snip]
> That's one of the *great* things about Tcl, that you can easily extend
> it with extra functionality through packages, your own code, or
> through calling external programs.
And how is this different from every other existent programming
language?
--
Óscar
David Gravereaux
Ever written a Perl extension? How about one that involves I/O? Some
nice OS level hacking you have to do to get under libc on windows, eh?
What a joy. Not so with Tcl as the channel API is wonderful. About the
only thing it lacks is the inverse of channel stacking where it operates
as a container... But only kooks like me ever get into stuff like that.
Python extensions aren't so bad, though. I got up to speed pretty
quick. Although with Python, the concept of a command returning a value
(an eval) is a bit odd as there are two types of execution: statements
and expressions. So first you need to source the code block with
PyRun_String(Py_file_input), then execute it with
PyRun_String(Py_single_input). I find that just odd.
--
Gerald W. Lester
> First of all, I thank everybody answering. ...
>
> ...
>
> Indeed I can ignore the new cool features and use Tcl/Tk as usual. The
> usual things remains easy to learn. The problem begins, when many
> people are involved in the developement and everyone must read what
> other write. It was part of the concept of Tcl that it is easy to
> learn and minimalistic.
Which brings us to the question of what is Tcl -- and no I'm not being funny.
To me Tcl is the Endekalogue -- *everything* else is just an extension and
can be overwritten (including the "built in" commands).
All one has to really learn is the Endekalogue, everything else can be
looked up.
> .. The question is now, if Tcl/Tk is a language for
> big programs or small ones. That Tcl/Tk works with big programs proves
> that the language is stable and realiable, but writing big programs
> with Tcl/Tk remains an abuse. There are a lot of languages for big
> programms. ...
I disagree that writing big programs with Tcl/Tk is an abuse -- and have for
years. In fact J.O. was shocked at the first Tcl/Tk workshop when a paper
was presented about a system that was ~300,000 lines of Tcl/Tk. The system
was deployed over time at several sites and grow to ~500,000 line of Tcl/Tk.
Very few bugs and easy to maintain.
Of course it has been overshadowed by at least an order of magnitude by two
other systems written in Tcl/Tk by two other vendors.
Kevin Walzer
>
> "Probably technically possible"?
>
> Basically you are blaming Tcl because it is missing an application you
> want to use. I have python on my machine, but it doesn't have an Atom/
> RSS parser.
>
> Problem is, if I was interested in Atom or RSS feeds, I might want to
> maintain some kind of database of the feeds. But neither Python or Tcl
> have real database capabilities. For that I would need to install
> another application and communicate with it. This is where Tcl ends up
> being ahead of the game. It could use any available RSS parser and
> store the results in a database. Tcl would also be very good at the
> server side of Atom or RSS.
I'm not quite sure what in my reply has made you so indignant.
I'm not blaming Tcl for anything. I'm saying, among other things, that
it lacks a well-supported library for parsing RSS/Atom feeds.
I'm well acquainted with Tcl's abilities to cooperate with and to drive
external applications. Most of my Tcl/Tk applications make use of this
feature. That's not especially relevant in this instance because I'm not
aware of any good command-line RSS parser.
>
> As far as parsing this stuff, one problem is the poor quality of the
> XML which is generated. But if it is valid XML, the Tcl community has
> developed two different parsers. As someone who has developed an XML
> application in Tcl (tWSDL/TWiST, which requires parsing, processing
> and generating XML documents), I can tell you Tcl works very well.
Yes, I realize that Tcl can parse XML. But if I wrote my RSS application
in Tcl, I would still have to figure out how to parse the different
kinds of RSS and Atom feeds in Tcl, which would be a lot of work. By
contrast, Python has Mark Pilgrim's feedparser library, which is a
comprehensive parser for RSS and Atom feeds. By choosing Python for my
specific application to parse RSS/Atom feeds, I can take advantage of
this library: I don't have to figure out how to parse all the different
RSS and Atom formats. By avoiding the work of writing my own feed
parsing library, I can develop my application faster and with fewer bugs.
>
> Hopefully Tcl (the language) will remain insufficient for everyone's
> needs, I mean, the list of built-in Tcl commands is only one browser
> sized page. It is also very hard to argue that the number of new
> commands add bloat. For all the additional bloat, certain things have
> simplified code development: namespaces, auto-initializing incr
> variables and lists, portable arrays (dict). Also things have been
> sped up by compiling some scripts into bytecodes.
I agree that Tcl is not a bloated language and I would number all of the
things you are listing as advantages of the language.
>
> And yet Tcl remains insufficient for my needs. Thankfully I know how
> to write library and application code to build up to something which
> is sufficient.
>
I think in many cases this is the correct approach. I've extended Tcl
and, especially, Tk many times myself to add functionality that was
missing. I also leverage system/command-line tools to fill in gaps in
Tcl's functionality. However, this isn't always the best or fastest
approach. By choosing Python and its robust, widely-praised, widely used
feedparser extension library, I can complete my application much sooner
than I could if I were developing it in Tcl.
Kevin Kenny
> I think in many cases this is the correct approach. I've extended Tcl
> and, especially, Tk many times myself to add functionality that was
> missing. I also leverage system/command-line tools to fill in gaps in
> Tcl's functionality. However, this isn't always the best or fastest
> approach. By choosing Python and its robust, widely-praised, widely used
> feedparser extension library, I can complete my application much sooner
> than I could if I were developing it in Tcl.
And, until and unless you or someone else develops the library you need,
I think you've made a wise choice. If your problem is solved, that's
good. (If Tcl solves it, that's even better, but solving the problem
is paramount.)
--
73 de ke9tv/2, Kevin
Rob
> Somewhere in the TK source, where it is shown that TK can work with
> unicode, it appears in many languages the greating "hallo world" or
> something similar. Only in hebrew its stays something different:
> "Jerusalem, Israel" in hebrew letters. (In arabic in should stay
> "Jerusalem, Palestine"). This issue shows, that arbitrarity is
> imposing itself: giving Jerusalem to the european jewish colonists is
> becomming more important than the concept of Tcl.
<rant>
That is your opinion. There is, at this time, no official country of
Palestine. I also object strongly to your choice of words.
</rant>
The code you refer to is presumably in a demo rather than the actual core
code. If you find it offensive, please feel free to create a "fix" and ask
to maintainers to apply it. Also, while discussion of language issues is
most welcome here, I believe your injection of a political statement is
definitely NOT appropriate. Requesting that the Arabic version
say 'Palestine' would be fine, but the comment on "giving Jerusalem to the
european jewish colonists" is, IMO, absolutely off-topic in this
newsgroup...
Rob.
tom.rmadilo
I agree this sounds like the correct choice in this case. So if there
is any question, my so called indignation is with the characterization
of Tcl as "merely" a glue language. Or even a language which has
"gaps" in functionality. Or that any programming language should be
deemed "insufficient" just because nobody got around to writing and
distributing your favorite application using the language.
Tcl takes advantage of well written applications in any programming
language. By well written, I mean that they export their functionality
via some useful interface. Maybe it is just a shell command, or a C
or Tcl library, or a mail program which deposits message files in a
particular directory. Or an external tcp server or local ipc server
(including stdin/stdout/stderr i/o). Note that Tcl itself does many of
these things: exported C and Tcl libraries, great tcp/ipc support,
many language features for packaging code into reusable components.
What is generally lacking is any enforcement of well structured code.
In a sense, that means the learning curve is not very steep. You might
write ugly code for a few years, but your code still works. And it
works on windows, mac and unix.
And it is very possible to write large, even very large programs in
Tcl. And you can do what I usually do: write programs which write
programs (not always Tcl programs either) so you can enforce code to
be well structured, and automatically improve the structure of all
generated code.
Most of these tasks are made easy because Tcl imposes no particular
"world view" on really anything. The only thing that is really
enforced is the basic syntax of the language.
sleb...@gmail.com
> "Donal K. Fellows" <donal.k.fell...@manchester.ac.uk> writes:
>
> [snip]
>
> > That's one of the *great* things about Tcl, that you can easily extend
> > it with extra functionality through packages, your own code, or
> > through calling external programs.
>
> And how is this different from every other existent programming
> language?
>
The word "easily"
Donal K. Fellows
> I disagree that writing big programs with Tcl/Tk is an abuse -- and have for
> years. In fact J.O. was shocked at the first Tcl/Tk workshop when a paper
> was presented about a system that was ~300,000 lines of Tcl/Tk. The system
> was deployed over time at several sites and grow to ~500,000 line of Tcl/Tk.
> Very few bugs and easy to maintain.
Thinking about it, one of the genuine themes of the whole Tcl 8.*
series has been increasing support for writing large programs. Which
isn't to say that it couldn't be done in previous versions (I've done
it) but it took a lot of discipline. Making things easier in this
regard is a good thing; it makes Tcl easier for newcomers to use, and
it's helpful for old hands too.
[Digression Alert!]
The other thing that I really like is the starkit distribution model.
It's an area where the closest I've heard of elsewhere is Java Web
Start, and that's not easy to deploy at all. (Well, going by the
comments of my colleagues at work on JWS; I've not used it myself.)
Let me be crystal clear; what Tcl has there is ahead of the
opposition. We don't know how far ahead though, because they're not
yet up to the level where we were at in 2002...
If we look at Tcl the language, the big changes have been the adoption
of UNICODE, the addition of the expansion syntax, and the introduction
of a new datatype (the dict, though it really just captures ideas in
Tcl that already existed), and 8.6 adds an object system and a much
more powerful execution model (coroutines). In terms of the
implementation, 8.0's upgrading of Tcl's value model and the
introduction of compilation are the massive features. For Tk, the
really big thing is the new themed widgets, both conceptually (the new
state model) and in implementation terms (Tk no longer has to look
utterly outmoded).
Donal.
Uwe Klein
> What is generally lacking is any enforcement of well structured code.
> In a sense, that means the learning curve is not very steep. You might
> write ugly code for a few years, but your code still works. And it
> works on windows, mac and unix.
1. If it works you won't improve on it anymore ;-?
2. The Peter Prinziple of Software Creation:
Any Code is beautyfied towards the death of it's usefullness ?
uwe
Donal K. Fellows
> The code you refer to is presumably in a demo rather than the actual
> core code.
It's supposed to say "Hebrew Language" or equivalent. But I don't read
any Hebrew script at all (or Arabic) so it's quite possibly wrong.
Fixes welcome. (Well, it's actually changed now so fixes are not
needed now.)
> Requesting that the Arabic version say 'Palestine' would be fine,
In a demonstration that is supposed to be totally non-controversial?
Not at all. There has never been any intent for Tcl/Tk to display
*any* political point of view on topics like this, even an even-handed
basis.
Donal.
Rob
Donal
So the demo should say "hello world" in whatever language it displays. If I
understand your comment you are saying that the discrepancy has already
been fixed, which is a good thing.
My response re 'the fix' was somewhat flippant and not at all appropriate.
My apologies to all on that point.
I actually posted my message simply because I was annoyed with Rodrigo
making a totally inappropriate political statement (as stated in his final
sentence) in a place that should be totally non-political (as you have said
yourself).
Rob.
Arndt Roger Schneider
> [snip]
>For Tk, the
>really big thing is the new themed widgets, both conceptually (the new
>state model) and in implementation terms (Tk no longer has to look
>utterly outmoded).
>
>Donal.
>
>
Tk and Tile are memory wise the largest parts in Tcl/Tk.
Tile is dependent on Tk, but Tk should not be dependent on Tile.
In order to reducing the memory footprint of Tcl/Tk:
Separate Tile into a shared library, create an alternative
wish loading tile, importing the ttk windows
into the global namespace as default.
The other wish(Tk) is then still able to load tile as
a package.
Requires under X11 to implement all Tcl-dialogs independent
from either Tk or tile aka separate the file dialog into its own
namespace, put styles and visual configuration inside the option database.
Second Tk:
Remove all embedded bitmaps and replace them with font-glyphs,
very much as you did with the warning symbols inside the message box,
but with anti-aliased glyphs, instead!
Do progressingly the same with all controls: corners, shadows,
highlightthickness, indicators... start with radiobutton and checkbutton
indicators.
Make the glyph-font user customizable:
Gives a full vectorized themed engine, anti-aliasd, fast as hell,
low memory footprint.
Third Panedwindow:
Reduce platform dependencies:
The panedwidow is a simple geometry manager
and should not be implemented as a window, make
it the fourth general purpose geometry in Tk and
leave the stash configuration to the developer using it.
Remove the redundant version in tile.
-roger
Larry W. Virden
> Or even a language which has
> "gaps" in functionality.
Depends on one's definition of "gaps in functionality". If one says
that, meaning "the language is incapable of implementing the
functionality", then I agree that phrase is inaccurate.
However, in most cases that I've seen using that type of statement,
what is meant is that "out of the box, Tcl does not provide working
code that provides the functionality". Certainly one has to admit that
there are quite a large number of areas not addressed by Tcl code out
of the box. If one created a checklist comparing Perl, Python, Java,
Tcl, and compared the functionality that is implemented a) after
compiling the source tar/zip file, or even b) including the online
automated repository (aka CPAN, teapot, etc.) I have no doubt that Tcl
would have the smaller list of functionality. That's because, despite
the original poster's claim, Tcl continues to be a relatively small
language, out of the box. There are languages which start out smaller
- C is pretty darn small when you look at JUST what is built as the
compiler. Even after you add in libc, it is pretty small. Java, when
you look at a distribution like the runtime distribution, is a pretty
small functional set.
But there are numerous additional packages outside of the source
distribution, or even package repository, which allows one to add
functionality.
For instance, there are various scripts for reading RSS feeds -
http://panoptic.com/tcllian/scripts/view.adp?script=rss.tcl for
example (and there are more that show up when web searching). Do they
do everything that the python library in question do? Probably not.
Tcl packages tend to be "just enough" to get the job done that the
writer needs.
If they are so inclined to make their code available, they have the
expectation that others who need more will code it.
But that, of course, doesn't "get the job done" as quickly as a
library that has been worked on over a period of time.
And there's the struggle in an open source community - how to get
higher quality libraries from people who are quite busy accomplishing
their day jobs (and sometimes their night jobs and weekend jobs,
etc.).
It takes help by the entire community, to test, fix, enhance, and
contribute back code so that, in the end, the community has better
packages.
Of course, using "the best tool" is a great approach. However, for
those who spend significant amount of bytes discussing what someone
else needs to do to make Tcl better, there is a useful contribution
area for them to pay forward. Take a look at the Tcl you use. Learn
the package better. Write tutorials, submit improvements to the docs,
write examples that can go on the web either at http://wiki.tcl.tk/ or
the package's home site. Answer questions patiently. Contribute useful
code that allows others to get jobs done well using Tcl.
>
> Most of these tasks are made easy because Tcl imposes no particular
> "world view" on really anything. The only thing that is really
> enforced is the basic syntax of the language.
Well said. Thank you.
Larry W. Virden
<donal.k.fell...@manchester.ac.uk> wrote:
> If we look at Tcl the language, the big changes have been the adoption
> of UNICODE, the addition of the expansion syntax, and the introduction
> of a new datatype (the dict, though it really just captures ideas in
> Tcl that already existed), and 8.6 adds an object system and a much
> more powerful execution model (coroutines). In terms of the
> implementation, 8.0's upgrading of Tcl's value model and the
> introduction of compilation are the massive features. For Tk, the
> really big thing is the new themed widgets, both conceptually (the new
> state model) and in implementation terms (Tk no longer has to look
> utterly outmoded).
And of all those changes, every one can be ignored to some extent.
UNICODE is probably the closest thing that really impacts the way
someone codes, and that only if the input is going to be UNICODE. The
rest of these changes are features that one can make use of, but need
not worry about if they so choose.
There have been more 'minor' changes that result in a need to tweak
programs than there have been 'major' changes to the scripting
language itself. Certainly from a C API, there have been a variety of
changes (ANSIfication, stubs library, etc.) that has resulted in the
need to change code. But in general, the language has stayed
relatively stable.
David N. Welton
> First of all, I thank everybody answering. About the recommendation of
> Etcl, lua, jim: I will see them , but I do not think they are the
> alternative, for example due to licence, due to object orientation
> that I do not like.
http://www.lua.org/license.html
http://jim.berlios.de/license.html
Both of these are very liberal licenses that let you include the code
in your own proprietary works and basically do whatever you want with
it.
It took me all of 5 minutes to find that information.
Lua has some sort of OO, but it's fairly minimalistic, and it's
evident that you did not even look at it before writing your post.
Jim, as far as I know, doesn't really have an OO system, and is very
small and minimalistic.
What was it that you are actually trying to build or do?
Rodericus
> > Or even a language which has "gaps" in functionality.
> Depends on one's definition of "gaps in functionality".
No, it depends on the definition of Tcl/Tk, on what people think it
is, on its image to the exterior world. If it is a cool object
oriented all purpose software development language with a lot of cool
features, specially for writing big programms, then it has very big
gaps on functionality. If it is a tool comand language, and people,
specially software developers, are aware of it, then it is very
powerful tool. Every piece of software with an API to Tcl makes the
value of Tcl much bigger, even if Tcl/Tk developers arent involved on
it, because the possibility of efficiently combining software grows. I
was for example very glad to find the API for GraphgicsMagick some
weeks ago. And yes, for this, Tcl/Tk should remain as small as
possible, because the real work ist done by the software it glues. If
you need a cool object oriented language, the glue it!
Rodrigo Readi.
Rodericus
> Which brings us to the question of what is Tcl -- and no I'm not being funny.
>
> To me Tcl is the Endekalogue -- *everything* else is just an extension and
> can be overwritten (including the "built in" commands).
>
> All one has to really learn is the Endekalogue, everything else can be
> looked up.
No, syntax is not all. You have objects, like numbers and strings, and
you must be able to write all recursive functions on them without
having to program a turing machine. You must be able to communicate
with the system and the outer world. You must be able to efficiently
write efficient programs with a minimal tool command language. I think
for example that the addition of expansion syntax, if this was done
efficiently, is a very good improvement, perhaps based more on
programming experience than on reflection of what is the ideal
language.
Rodrigo Readi.
Rodericus
> What was it that you are actually trying to build or do?
99,999% of people dealing with computers are either application users
that never write a program or professional application writers, that
need cool programming languages. I am neither the first nor the
second. For me a computer is a programmable tool. I dont write any
comercial program, from time to time a program that run only once to
solve a task, or an application with the functionality I need for my
work (at the time historical research on the german Recihsbank).
As Emacs became extreemely fat, I began to use vi, althought till now
I use emacs for programming. As Tcl/Tk is dying, I will have perhaps
to use more C, I will find the way.
Rodrigo Readi
Uwe Klein
> And of all those changes, every one can be ignored to some extent.
> UNICODE is probably the closest thing that really impacts the way
> someone codes, and that only if the input is going to be UNICODE. The
> rest of these changes are features that one can make use of, but need
> not worry about if they so choose.
Worldwide only a minority of users produce pure ASCII content.
for the nonminority it used to be an unending PITA ( and still is
to some extend on the web, people still start flamewars on botched
up encodings in netnews messages ;-)
uwe.
David N. Welton
> I use emacs for programming. As Tcl/Tk is dying, I will have perhaps
> to use more C, I will find the way.
You might have a look at 'ed', as "ed is the standard text editor".
Bruce Hartweg
And yet you still haven't given concrete reasons/questions/problems
with the new Tcl other than "I don't like change", or it isn't exactly
what JO thought is was many decades ago, It has things I don't want
or need or like. But none of those generalities preclude you from
continuing to use Tcl in the same way as you always have.
Bruce
drsc...@gmail.com
> The system was deployed over time at several sites and grow to ~500,000
> line of Tcl/Tk. Very few bugs and easy to maintain.
>
> Of course it has been overshadowed by at least an order of magnitude by
> two other systems written in Tcl/Tk by two other vendors.
And they are?
DrS
Will Duquette
The ttk::panedwindow is far from redundant; in my experience it works
*much* better (in both behavior and appearance) than the non-ttk
panedwindow.
On top of this, moving the ttk widgets into a separate package would
be a major step backward for Tk.
Arndt Roger Schneider
Fine, use the ttk:panedwindow code for the stand-alone geometry manager.
>On top of this, moving the ttk widgets into a separate package would
>be a major step backward for Tk.
>
>
Why? You have two applications, one linked against tile,
and another one only with tk, where is the step backward?
It provides the same environment as is current in 8.5, plus the
option to use a smaller set on such platforms which don't
have themes or were the extra memory requirements are to
big a burden.
-roger
Óscar Fuentes
"easily" here is subjective. It is "easy" to introduce new commands for
interfacing with C code, in the sense of requiring less boilerplate than
other languages. But Tcl requires more work than others (notably, some
languages or implementations requires one line of code per C/C++
reflected function/method, some languages requires none.)
It is not so easy to reflect complex external data on the Tcl data
model, though.
The above is for interfacing with external libraries. Certainly, a
programmer who can't get the grips on Tcl's weirdness will say that is
not easy to add functionaility to Tcl writting Tcl code.
And EIAS is not all that great for some tasks. Being interpreted forces
you to write C from time to time.
So, Donal's is reflecting its own personal likes and dislikes. What he
says makes no sense otherwise.
--
Óscar
Will Duquette
The Ttk widgets are not a replacement for the classic Tk widgets; the
two sets are complementary.
Georgios Petasis
And there is always SWIG. This makes interfacing easy for all languages.
However, Tcl has the advantage of stubs. Not all languages have a stub
library, where you link with it and forget the binary: it runs with any
version greater than the one linked (officially, unofficially it runs
also with earlier versions as long as you don't use functions not
available in earlier versions).
George
Tcl Bliss
is still alive and better than ever, a lot of it due to ActiveState
http://www.activestate.com actively :) supporting it. Thanks
ActiveState. Of course, there are other contributors, thank you all.
One very visible major shortcoming, IMHO, is a flaky support of
command line history browsing. Most modern scripting languages support
readline but in TCL it doesn't work by default and requires a good
effort to make it work. I have not been patient enough lately to make
it work. Of course, I can use Tkcon but not when I ssh to a remote
system, which I do a lot.
Óscar Fuentes
>> What was it that you are actually trying to build or do?
[snip]
> I dont write any comercial program, from time to time a program that
> run only once to solve a task, or an application with the
> functionality I need for my work.
[snip]
> As Tcl/Tk is dying, I will have perhaps to use more C, I will find the
> way.
Troll alert!
(Well, actually I don't think he intends to troll. Too often a troll is
indistinguishable from a clueless, self-righteous dude.)
--
Óscar
Rodericus
> > As Emacs became extreemely fat, I began to use vi, [...]
> You might have a look at 'ed', as "ed is the standard text editor".
Ed was the first editor I used on a Unix computer. Before I used "sos"
editor on a DEC 10 computer connected to an LT100 paper terminal (tops
10 operating system).
Rodrigo
Rodericus
> And yet you still haven't given concrete reasons/questions/problems
> with the new Tcl other than [...]
I think, you do not get the point, or do not want to get it, so that
the whole discussion sound ideological.
I am not a programmer, programming is not my work, I do not like to
learn continously a new programming/scripting language. I am very glad
to find Tcl everywhere, I used it for example among others with MySQL
at client side, with Postgresql at server side, as Cost for processing
SGML (a beautiful extension with a clear concept), as websh apache
module, with GraphicsMagick, now with sqlite. The main advantage using
Tcl lies less in the language self, more in the fact that it is beeing
bound to other software. A growing image, new features that may add
new bugs, mutations for the sake of mutation, the fact that it is
becoming a scripting language like any other goes against this
original goal of Tcl. The problem lies that you see Tcl at the center,
as a tool command language it is at the margin of the application. My
only critic was against inflating the core with new features that
belog to extensions, and your answer is that I should ignore the
inflation. Shin remarks with right, that I will never find a pure
doctrine, but every programming language has a concept and some
deviations of it for practical reasons, and I think the inflation is
because the original concept was forgotten. Object orientation in the
core is too much!
The alternative is C, in each good piece of software you have a good C
API. Indeed is programming in C not always so easy as in Tcl, and for
gluing software I like the scripting language. I never programmed a
GUI with C, and I suspect here is one of the biggest advantages of Tk.
Rodrigo.
Pat Thoyts
>Tk and Tile are memory wise the largest parts in Tcl/Tk.
>Tile is dependent on Tk, but Tk should not be dependent on Tile.
...blah blah blah ...
[big pile of suggestions snipped]
Its an open source project. You can fork it anytime you want.
It will be interesting to review your forked version. You can announce
it here when you have something ready.
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Bruce Hartweg
> Bruce Hartweg wrote:
>
>> And yet you still haven't given concrete reasons/questions/problems
>> with the new Tcl other than [...]
>
> I think, you do not get the point, or do not want to get it, so that
> the whole discussion sound ideological.
you are the one that seems to not get (or have) a point, and
keep throwing out the "ideological" discussion of what tcl "should"
be, based on the past. You still havent't shown an actual problem
that the "new" Tcl has caused in your usage.
>
> I am not a programmer, programming is not my work, I do not like to
> learn continously a new programming/scripting language. I am very glad
> to find Tcl everywhere, I used it for example among others with MySQL
> at client side, with Postgresql at server side, as Cost for processing
> SGML (a beautiful extension with a clear concept), as websh apache
> module, with GraphicsMagick, now with sqlite. The main advantage using
> Tcl lies less in the language self, more in the fact that it is beeing
> bound to other software. A growing image, new features that may add
> new bugs, mutations for the sake of mutation, the fact that it is
> becoming a scripting language like any other goes against this
> original goal of Tcl. The problem lies that you see Tcl at the center,
> as a tool command language it is at the margin of the application. My
> only critic was against inflating the core with new features that
> belog to extensions, and your answer is that I should ignore the
> inflation. Shin remarks with right, that I will never find a pure
> doctrine, but every programming language has a concept and some
> deviations of it for practical reasons, and I think the inflation is
> because the original concept was forgotten. Object orientation in the
> core is too much!
object orientation in the core has zero impact to anything you
want to do with tcl. just ignore it. it is NOT changing the language
itself - it is adding new capabilities for those who want/need it
so all those things you mentioned above that you like, what
no longer works? what can you no longer do?
Bruce
Arndt Roger Schneider
>Arndt Roger Schneider <arndt...@web.de> writes:
>
>
>
>>Tk and Tile are memory wise the largest parts in Tcl/Tk.
>>Tile is dependent on Tk, but Tk should not be dependent on Tile.
>>
>>
>...blah blah blah ...
>[big pile of suggestions snipped]
>
>Its an open source project. You can fork it anytime you want.
>It will be interesting to review your forked version. You can announce
>it here when you have something ready.
>
>
>
Thanks for the suggestion! I am not interested in forking it.
Rodericus
> object orientation in the core has zero impact to anything you
> want to do with tcl.
A fat Tcl interpreter has impact to all wanting to see Tcl linked to
other software and embedded in hardware, because fatness make it less
attractive to those that do not like fatness and do not like to link a
fat interpreter as tool command language to their meager software they
write. Those liking fatness will not have a problem linking a meager
interpreter. The solution is to clear distinguish what is the core of
Tcl (and also Tk) and what is an extension that may be make fat to
satisfy those that like fatness. Is it realy so difficult to
understand?
The proposal of Pat Thoyts to Arndt Roger Schneider also confirm that
the first do not get the point: Forking Tcl/Tk would only make it
unattractive to potential linkers. Tile as a separated package, as a
complement to a meager Tk, should not be a problem.
Rodrigo.
Uwe Klein
_That_ is bloat man!
On the third hand:
nobody beyond the starpackers does static linking anymore.
my wish binary ( as an example of an app with embedded tcl _and_ tk ;-)
is 6kB small.
On small custom (embedded) system I have used jim ( incl. hardware IO
and userspace interrupts ) with good results.
common to all my tcl apps is that I don't embed an interpreter
in a spaghetti monster of c code but provide extra functionality
as loadable packages ( tcl or jim ).
My apps are interpreted script.
OK, I usually arrange it such that I get paid for my work.
No need to jump through hoop to hold users up for ransom ;-)
Which obviates the need for "hiding" my IP.
uwe
MSEdit
I am not sure where all this bloat you are seeing comes from.
My 8.6 full GUI binary is 90k bigger than my 8.5.7 binary for me 90k
is not bloat.
Martyn
Bruce Hartweg
> On 16 Dez., 00:50, Bruce Hartweg <doNOTmai...@example.com> wrote:
>
>> object orientation in the core has zero impact to anything you
>> want to do with tcl.
>
> A fat Tcl interpreter has impact to all wanting to see Tcl linked to
> other software and embedded in hardware, because fatness make it less
> attractive to those that do not like fatness and do not like to link a
> fat interpreter as tool command language to their meager software they
> write. Those liking fatness will not have a problem linking a meager
> interpreter. The solution is to clear distinguish what is the core of
> Tcl (and also Tk) and what is an extension that may be make fat to
> satisfy those that like fatness. Is it realy so difficult to
> understand?
>
What you don't get is your arbitrarily definition of "Fatness"
you want things you want, but not other stuff. You are running this
link with databases, webserservers, image libraries etc. so the
physical size of the Tcl interpreter is not *really* an issue.
if you were doing embedded systems and said I only have x bytes
and Tcl is now Y bytes (where Y > x) then you would have a gripe
but there is nothing actually preventing you from using it other
than your preconceived notions and attitude.
Bruce
Rodericus
> What you don't get is your arbitrarily definition of "Fatness"
> you want things you want, but not other stuff.
I have just done man perl: >>The Perl motto is "There’s more than one
way to do it."<<
Perl is always there when I install Free- or OpenBSD, Tcl/Tk is
unfortunately not anymore in the base distribution of FreeBSD. Perhaps
because it is trying to compete with perl. You have now at least 15
ways:
(1) Like LISP (but with less parenthesis).
(2) Typical Tcl, writing scripts that write and change themselves
before running over their change.
(3) like C.
(4) Object oriented.
(5) - (15) Every combination of some of the above possibilities.
Having a goto command, you could also have the possibility of writing
like FORTRAN and the combinations, a total of 31 possibilities. You
can argue that this is good, you have the freedom to chose a style and
ignore the other possibilities, and this is correct as far as you are
the only one that write and read what he writes. Years ago there were
big discussions for and against the goto statement (that I like very
much). In C you have the goto, in Tcl not, perhaps because it was
considered bad style. The question of style has an impact in software
developement, and the restriction in the language a sense. I like the
description of Tcl as a "Toy Language", it was only a misunderstanding
of its minimality and simplicity that allowed to have a clear view
over the whole language, that made it easy to learn it completely.
This was an advantage that seems to be not more understood.
I am still using Tcl8.4, I was disgusted as I saw widget repetitions
and the object orientation. If Tcl/Tk is not jet fat, then it is
perhaps on the way. I think, obeject orientation in a scripting
language is fat. I think object orientation self is fat hiding
algorithms, but this is an opinion.
Rodrigo.
Georgios Petasis
I didn't understand the relation with perl. Perl also has OO.
And the difference in sizes of the involved dlls is about 60K.
Do you compare with perl because perl is a "slim" language, or you are
considering perl also as fat?
George
tom.rmadilo
> Having a goto command, you could also have the possibility of writing
> like FORTRAN and the combinations, a total of 31 possibilities.
Yes, one would "think" that Tcl does not have a goto.
A few months back I ran a few experiments: translate C code into a
Tclish equivalent. The experiment consisted of finding fast algorithms
for solving sudoku and translating them directly into Tcl code. I
didn't even try to "understand" the algorithm. This meant that I had
to follow the naming conventions and the algorithms steps as closely
as possible.
On example used a single C function with goto:. You can compare the
results:
http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test
basic-exact-cover.tcl is the Tcl version of ec.c.
If you read my notes in the tcl file, you will find that I originally
thought that the code didn't work all the time. But when I compiled
the original c code, it gave exactly the same answers, even when it
appeared to not find a solution.
I later discovered that the original algorithm searched for every
possible solution and I was printing out the final state of the
algorithm, not the found solutions. Turned out to be a pretty good
check on the goals of the experiment.
The basic idea is to use a while loop and a switch statement. The
switch arms are the goto points, and [continue] is the [goto]. The
code could have been made to look even more like the C code by
defining a proc [goto point], which set the switch variable and did a
[return -code continue].
I also use something like a [goto], I call it a pipeline, used to jump
to the end of a code block:
while {1} {
(conditional statements which might break) ...
break
}
Turns out this pipeline idea is just a special case of the new goto
example.
Tcl lends itself to this type of experimentation. Nobody set out to
create a [goto] in Tcl. You also might notice that I simulate a two
dimensional array to hold the sudoku puzzle, using the same basic
syntax as in the original C code.
Rodericus
> Tcl lends itself to this type of experimentation. Nobody set out to
> create a [goto] in Tcl. You also might notice that I simulate a two
> dimensional array to hold the sudoku puzzle, using the same basic
> syntax as in the original C code.
Thanks! Now I know how to program with goto in Tcl. :)
By the way, the proof that everything you can program with "goto" can
also be programmed without it, is like that, with an exterior "while".
It is a complicated way of circumscribing something very simple: set
the program counter to something different instead of increasing it by
one. I think no one wanted the goto because of style: structured
programming was the spirit of that time, as today is object
orientation.
Rodrigo.
Rodericus
> I didn't understand the relation with perl. Perl also has OO.
> And the difference in sizes of the involved dlls is about 60K.
> Do you compare with perl because perl is a "slim" language, or you are
> considering perl also as fat?
Perl does not claim to be minimalistic.
We are equating the language with that, what the interpreter does, so
that the language is growing like perl as the interpreter gets new
cool features that people want. There is no definition, no concept of
the languge, perhaps only the syntax is the whole concept.
Rodrigo.
tom.rmadilo
Something you can do with this "Tclish" goto that you can't with a
regular goto: you can replace the code following the label, that is
you can substitute in a new set of switch case bodies. (Actually you
can do this in C by using a function pointer in place of a function
name, but then you have left the original execution environment.)
But it should be pointed out that this particular form of goto isn't
in any way unstructured, the original code in C and my use are
designed as an efficient loop contained within a single procedure (so
many function calls and variable passing are avoided). In Tcl this is
probably more of a help than in C in terms of speed. Not every use of
goto will fall into this category, so don't expect this example to
settle any arguments against using goto.
Something else we have in Tcl that is similar to a goto (execution
within a fixed environment) is [namespace eval], or also using
[namespace code]. I once called these named stacks, but was
corrected. A namespace is like a named stack level. At any time, you
can "goto" that label and execute arbitrary code, not fixed code.
But the fact that code can shift under your feet in Tcl means that you
can't implement a [goto] which is implemented anything like your
program counter.
Ivan Shmakov
>> What was it that you are actually trying to build or do?
> 99,999% of people dealing with computers are either application users
> that never write a program or professional application writers, that
> need cool programming languages. I am neither the first nor the
> second. For me a computer is a programmable tool. I dont write any
> comercial program, from time to time a program that run only once to
> solve a task, or an application with the functionality I need for my
> work (at the time historical research on the german Recihsbank).
... I wonder, where did you get the estimate above from?
To me, the picture seems to be quite different. The tale as I
read is, like: I use computers as, as you've stated,
``programmable tools'', just like you. Why, a few of my
colleagues do the same. Recently, I've visited an institute in
the city some 200 km away from here, and, well, what did I
notice? There're the people just like that, too!
So, to conclude, it seems to me like there're much more people
like that than you've stated.
... And, working as an instructor at a local university, how do
you think, how will I teach my students? Will my point be that
they're to be ``application users'', without any programming
skills, or should I help them become ``pro application
writers''?
> As Emacs became extreemely fat, I began to use vi, althought till now
> I use emacs for programming.
Do you mean that the newer versions of Emacs require much better
hardware to run than the older?
Don't take it as an offence. IIUC, most of those who develop
Emacs aren't ``professional developers'', either. I guess that
they're rather unpaid volunteers, but what matters even more is
that they're explorers, and they explore new paths to solve the
problems they (and the other Emacs users) encounter. The (very
moderate, in my opinion) increase of the system requirements is
the price that has to be paid for these efforts, as is the (very
moderate, again) increase of the number of settings needed to be
changed to keep Emacs from doing anything in a new and unhandy
(but, since now on, default) way.
Of course, we may try to constrain the developers with the
hardware we're personally accustomed to, and, I guess, we could
even pay them for the efforts, but then -- we're turning them
into ``professionals'', and they're not just explorers anymore.
To me, it's just a too bitter price to pay.
Fortunately for me, I can quite afford ``upgrades'' (i. e.,
switching to a wholly new hardware, sans the display and the
keyboard) every few years. A few years ago, I was using an
K6-266 based machine at home, and since then switched to a more
recent one. However, I still use the former as a terminal (by
the means of SSH) -- I just know, and like, how she behaves, and
its video adapter is supported by SVGATextMode, etc. Though I
no longer run Emacs there.
> As Tcl/Tk is dying, I will have perhaps to use more C, I will find
> the way.
My usual advice would be: there're no single ``ultimate
solution''. If whatever in this world forces you to explore
other software, languages, or whatever else -- then so be it.
PS. Regarding the trip I've mentioned above: to collect the results I
was to present there, I've used my skills in (to name just the
languages, alphabetically): Bourne Shell, C, Fortran, GNU Make,
M4 and, of course, Tcl. And my opinion is: would it take less
than five languages to do the whole task, it wouldn't be that
interesting to bother.
--
FSF associate member #7257
J R Houck
<snip>
> IMO Tcl is more like a meta-language for creating problem oriented scripting languages
> and so doesn't pull every new concept into a syntactically predictable
> form. It's pure freedom ;)
Well said... :)
Rodericus
> But it should be pointed out that this particular form of goto isn't
> in any way unstructured, the original code in C and my use are
> designed as an efficient loop contained within a single procedure (so
> many function calls and variable passing are avoided). [...]
I never came to the idea of jumping from to an uncalled procedure, is
that possible in C?
How are the local variables of the new procedure set?
> But the fact that code can shift under your feet in Tcl means that you
> can't implement a [goto] which is implemented anything like your
> program counter.
Yes, there may be a problem.
Rodrigo.
Rodericus
> To me, the picture seems to be quite different. The tale as I read is, like: I use computers
> as, as you've stated, ``programmable tools'', just like you.
I think only computer scientists are professional programmers,
software engeneers. All other engeneers and scientists, with very few
exceptions, are amateur programmers. This does not mean that their
programs are inneficient or get bad results, the last could end in a
big catastrophe, but that
their programs do not have commercial quality.
> Do you mean that the newer versions of Emacs require much better hardware to run than the older?
Since long ago it takes seconds to start. For the use I give emacs, I
dont see since years any progress. And perhaps due to its weight, it
is difficult to fix bugs or make it better. Note that its very base,
the lisp implementation, is far away of beeing a normal lisp or
scheme, it is nothing
very pretty. Emacs as other software must develope for the sake of
developement, in order that the unpaid volunteers do not be jobless.
For simple editing I prefer now vi.
> Fortunately for me, I can quite afford ``upgrades'' (i. e., switching to a wholly new hardware, ..
That is the good side of fatware: it promotes hardware developement
and falling prices of hardware.
> PS. Regarding the trip I've mentioned above: to collect the results I was to present there,
> I've used my skills in (to name just the languages, alphabetically): Bourne Shell, C, Fortran,
> GNU Make, M4 and, of course, Tcl.
FORTRAN and Tcl (<8.5) are for amateur programmers. In your list there
is no programming
language like C++, C#, Visual Basic or Java.
Rodrigo.
Uwe Klein
> On 17 Dez., 17:04, Ivan Shmakov <i...@main.uusia.org> wrote:
>
>
>>To me, the picture seems to be quite different. The tale as I read is, like: I use computers
>>as, as you've stated, ``programmable tools'', just like you.
>
>
> I think only computer scientists are professional programmers,
> software engeneers. All other engeneers and scientists, with very few
> exceptions, are amateur programmers. This does not mean that their
> programs are inneficient or get bad results, the last could end in a
> big catastrophe, but that
> their programs do not have commercial quality.
If you mean something else than
below par closed source riddled with bugs software
pedled for money by twisting customer arms.
I would like to contest that.
programming in an engineering environment is ancillary qualification.
"computer scientists" usually don't have the (engineering) mindset.
and in quite a lot of cases it is nearly impossible to "upgrade" them.
Story on the side:
As a hardware designer I had once requested a memory test tool
from our very professional highly esteemed programmers.
Their code could not :
detect amount memory present
detect shorts between data lines
detect shorts between address lines.
Quite the dissapointment, they had absolutely no idea on
how to isolate imperfections or differences in model <> reality.
Reality requires that you are able
to apply theory to reality in a meaningfull way.
uwe
Donal K. Fellows
> I never came to the idea of jumping from to an uncalled procedure, is
> that possible in C?
Only by an egregious hack.
> How are the local variables of the new procedure set?
Hah! You jest, yes? (Non-local gotos are true evil. Just about
anything else you could consider would be better.)
Donal.
Alexandre Ferrieux
>
> One very visible major shortcoming, IMHO, is a flaky support of
> command line history browsing. Most modern scripting languages support
> readline but in TCL it doesn't work by default and requires a good
> effort to make it work. I have not been patient enough lately to make
> it work. Of course, I can use Tkcon but not when I ssh to a remote
> system, which I do a lot.
Uh, on Windows it works out of the box, and on major Unices you can
use the universal readline wrapper "rlwrap".
Not reinventing the wheel is a rather smart choice when people are
worrying about bloat (and I do worry about bloat from time to time).
-Alex
Ivan Shmakov
>>>>> "IS" == Ivan Shmakov <i...@main.uusia.org> wrote:
IS> To me, the picture seems to be quite different. The tale as I read
IS> is, like: I use computers as, as you've stated, ``programmable
IS> tools'', just like you.
R> I think only computer scientists are professional programmers,
R> software engeneers. All other engeneers and scientists, with very
R> few exceptions, are amateur programmers. This does not mean that
R> their programs are inneficient or get bad results, the last could
R> end in a big catastrophe,
Yes.
R> but that their programs do not have commercial quality.
If you mean that these cannot be packaged in a nice wrapping and
sold to the general public, then you're probably right.
... But then, does anyone really need such software? It seems
to me that the computer world is ran by the amateur programmers,
much less the ``professional'' ones.
Anyway, one doesn't have to ``sell'' the software in such a
uncanny manner in order to be paid for the work.
IS> Do you mean that the newer versions of Emacs require much better
IS> hardware to run than the older?
R> Since long ago it takes seconds to start.
How does it matter? Usually, I start Emacs every few weeks or
so (depending on the power blackouts here), and then have it
running (or, mostly, ``sleeping'') inside a Screen session.
R> For the use I give emacs, I dont see since years any progress.
I saw multi-lingual support improved quite considerably duiring
the recent few years. Given that my native language uses a
non-latin based script, and given that I have to write
considerable amounts of text in it, it makes a difference.
I could say pretty much the same about the rest of the GNU
system, be it Coreutils, or (pdf)LaTeX, or db2latex, or a number
of other tools I use. For sure, I have to use less kluges in
typesetting that I've used to have a decade ago.
R> And perhaps due to its weight, it is difficult to fix bugs or make
R> it better. Note that its very base, the lisp implementation, is far
R> away of beeing a normal lisp or scheme, it is nothing very pretty.
Yes. But does it /have/ to be pretty?
R> Emacs as other software must develope for the sake of developement,
R> in order that the unpaid volunteers do not be jobless.
And in order to cover the ever-widening set of problems that
arise before (ever-widening set of) its users.
R> For simple editing I prefer now vi.
For years I prefer Vim and ed to do simple editing, especially
when working under the privileged user.
[...]
IS> PS. Regarding the trip I've mentioned above: to collect the
IS> results I was to present there, I've used my skills in (to name
IS> just the languages, alphabetically): Bourne Shell, C, Fortran, GNU
IS> Make, M4 and, of course, Tcl.
R> FORTRAN and Tcl (<8.5) are for amateur programmers. In your list
R> there is no programming language like C++, C#, Visual Basic or Java.
Well, I've used just a few software packages in my field that're
implemented (at least partially) in either C++ or Java. I don't
remember using anything depending on either VB or C#.
Notably, GDAL, http://www.gdal.org/, is implemented in C++,
while HDF-EOS to GeoTiff contains a Java-based GUI (which isn't
particularly useful for my purposes, BTW.)
Sean Woods
> "Donal K. Fellows" <donal.k.fell...@manchester.ac.uk> writes:
>
> [snip]
>
> > That's one of the *great* things about Tcl, that you can easily extend
> > it with extra functionality through packages, your own code, or
> > through calling external programs.
>
> And how is this different from every other existent programming
> language?
>
> --
> Óscar
I guess to the extent to which I can bend it to my will. ;)
Sean Woods
> Tk/Tk was my predilect language for small programms, because it was
> minimalistic and expresive, low weight and extensible, lisp and C
> similar, ideal for embedding it in other programms. Now it is getting
> fat and "object oriented" with a lot of unnecesary "features" that
> would belong to extensions for special purpose applications. It is
> getting a "Cool Programming Language (CPL)" for cool people, not any
> more a "Tool Command Language". I think, a splitting and a renaming of
> the cool language to something like Cpl/Tk#++ would have been a much
> better approach. I think this is the result of having very good
> developers not knowing what to do. Please, dont consider this posting
> a flame war provocation: it is my oppinion.
>
> Rodrigo Readi
Popularity and survival are not synonymous. A company is not going to
take 10 years of R&D and re-write it from scratch into something else
simply because it's not en vogue.
(Pause)
Ok, we can all stop laughing.
Sean Woods
Hey 90k used to be a huge deal.
Back when we were dealing with 120k floppies. When I was a lad. And we
had to walk uphill both ways to school...
tom.rmadilo
> On 17 Dez., 17:00, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > But it should be pointed out that this particular form of goto isn't
> > in any way unstructured, the original code in C and my use are
> > designed as an efficient loop contained within a single procedure (so
> > many function calls and variable passing are avoided). [...]
>
> I never came to the idea of jumping from to an uncalled procedure, is
> that possible in C?
> How are the local variables of the new procedure set?
As Donal said, this is beyond the abstraction of the C language, but
isn't impossible. It is about as safe as browsing the internet. You
can use non-recursive function calls in C and still use goto in the
main function. Anyway I never suggested jumping to another function, I
suggested changing the code run within a label, in C you just us a
function pointer instead of a name.
The way you "share" variables in C is to declare/define them outside
the functions, usually at the top of the file (the variables will be
shared with all functions in the file).
I just added an example of this style, again using a sudoku exact
cover algo, this time without backtracking. This required two helper
procs and a few shared variables:
http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test
The .c and .tcl file named no-backtrack-exact-cover
In Tcl you just use a namespace, but you have to add the [variable]
syntax inside each tcl proc.
One good reason to use this type of algorithm, instead of a recursive
method is to run inside of a fixed memory and stack space.
> > But the fact that code can shift under your feet in Tcl means that you
> > can't implement a [goto] which is implemented anything like your
> > program counter.
>
> Yes, there may be a problem.
Not really a problem. I haven't shown any uses of goto which are
really an abuse.
Truth is you can abuse anything. On further analysis of the original C
code, I noticed that the backtracking step "abused" the fact that C
will just continue on working even if a function returns an error, or
if you try to access uninitialized array indexes. (In this case, the
zero indexes are unused.)
Tcl still complains when you do this, but has stopped complaining if
you try to increment an uninitialized (non-existing) variable.
This is an area where you could have an honest disagreement about
bloat. Is is better to force users to initialize variables prior to
use? This seems to bloat every application. If you initialize on first
use, user code is less bloated...at least initially. But now the bloat
is in the internal code which handles the initialization. This bloat
only handles the special case, so you are stuck with any non-default
initializations.
I think the right decision was made in this case: you can't force
users to write good code, but if you can make most code easier to
write, then more time is available for the hard parts.
Helmut Giese
>take 10 years of R&D and re-write it from scratch into something else
>simply because it's not en vogue.
>
>(Pause)
>
>Ok, we can all stop laughing.
Tcl Bliss
wrote:
Thank. Works great. I wasn't aware of "rlwrap" until now.
Rodericus
> As Donal said, this [jump to other funktion] is beyond the abstraction of the C language, but
> isn't impossible.
From Kernighan Ritchie's book:
"A label has the same form as a variable name, and is followed by a
colon. It can be attached to
any statement in the same function as the goto. The scope of the label
is the entire function".
This means, by definition of C is a goto to other procedure not
allowed. If it is possible, then
due to a bug in the compiler (it should give an error) or due the
hacker exploiting the bug.
It stays also:
"Although we are not dogmatic about the matter, it does seem that goto
statements should be used
rarely, if at all"
The authors were aware of the dogmatic discussions.
>> How are the local variables of the new procedure set?
> The way you "share" variables in C is to declare/define them outside the functions,
But then they are not anymore local. There is also no memory allocated
for the arguments
of the function, that are also local: this is done when calling the
function, and this do
not happend when you jump inside.
I could not reach the link:
> http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test
> you can't force users to write good code, but if you can make most code easier to
> write, then more time is available for the hard parts.
I agree.
Rodrigo.
Rodericus
R>> Since long ago it takes seconds to start.
IS>> How does it matter? Usually, I start Emacs every few weeks or
IS>> so (depending on the power blackouts here), and then have it
IS>> running (or, mostly, ``sleeping'') inside a Screen session.
Not pretty solution!
R>>> [...] Note that its [emacs] very base, the lisp implementation,
is far
R>>> away of beeing a normal lisp or scheme, it is nothing very
pretty.
IS>> Yes. But does it /have/ to be pretty?
I think yes. Aesthetics plays also role in programming and makes it
easier.
Rodrigo.
tom.rmadilo
> On 18 Dez., 18:55, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > As Donal said, this [jump to other funktion] is beyond the abstraction of the C language, but
> > isn't impossible.
>
> From Kernighan Ritchie's book:
>
> "A label has the same form as a variable name, and is followed by a
> colon. It can be attached to
> any statement in the same function as the goto. The scope of the label
> is the entire function".
>
> This means, by definition of C is a goto to other procedure not
> allowed. If it is possible, then
> due to a bug in the compiler (it should give an error) or due the
> hacker exploiting the bug.
I'm thinking of buffer overflows. Maybe the original programmer didn't
think about it, but viruses take advantage of this.
> It stays also:
>
> "Although we are not dogmatic about the matter, it does seem that goto
> statements should be used
> rarely, if at all"
>
> The authors were aware of the dogmatic discussions.
>
> >> How are the local variables of the new procedure set?
> > The way you "share" variables in C is to declare/define them outside the functions,
>
> But then they are not anymore local. There is also no memory allocated
> for the arguments
> of the function, that are also local: this is done when calling the
> function, and this do
> not happend when you jump inside.
There is no local only solution if you use helper functions, the
example below just demonstrates the equivalent syntax for Tcl (which
doesn't support the file based variable scope).
Another example is in sd-basic-exact-cover.tcl, which uses a global
variable to hold the result. This just allows the print function to be
external while maintaining everything else within one procedure.
The sd::solveCellFast algo uses a recursive method which is slower,
but solves arbitrary dimension puzzles. solveCellFast is compared to
solveCell, which uses two external helper procedures.
This series of experiments indicates that if speed is important, it is
better to keep an open mind as to the organization of the program. But
the key is organization. Most valid complaints about things like goto
is that they lend themselves to becoming hacks and help produce
spaghetti code. In essence, they can be used as an escape hatch for a
poorly constructed program. In this case the mere fact that the
spaghetti code "works". It is possible that since the developer wasn't
implementing a well thought out algorithm that the code will fail in
some cases which are not immediately apparent. If you have ever been
stuck trying to untangle such code, you might start implementing a no-
tolerance rule.
> I could not reach the link:
>
> >http://www.junom.com/gitweb/gitweb.perl?p=sd.git;a=tree;f=test
Copy and paste, looks like google groups has put in a redirect. (you
can also go to the upper level and work your way down sd.git->tree-
>test.
Les Cargill
http://video.google.com/videoplay?docid=2255807183978932387#
Sorry. Been wanting to post that link all week.
--
Les Cargill
Ivan Shmakov
R> Since long ago it takes seconds to start.
IS> How does it matter? Usually, I start Emacs every few weeks or so
IS> (depending on the power blackouts here), and then have it running
IS> (or, mostly, ``sleeping'') inside a Screen session.
R> Not pretty solution!
Why?
I've never used one, but the rumors are that the Lisp Machines
were taking a lot of time to boot. So, preasumably, their users
weren't booting them all too often.
R> Note that its [emacs] very base, the lisp implementation, is far
R> away of beeing a normal lisp or scheme, it is nothing very pretty.
IS> Yes. But does it /have/ to be pretty?
R> I think yes. Aesthetics plays also role in programming and makes it
R> easier.
On the other hand, Emacs is certainly /prettier/ than the other
text editing-oriented Lisp implementations, since it works.
The software that doesn't work cannot be pretty.
Donal K. Fellows
> On 18 Dez., 12:46, Ivan Shmakov <i...@main.uusia.org> wrote:
> R>> Since long ago it takes seconds to start.
FWIW, on this system (6 years old?) the startup time of Emacs is near-
instant - too fast to easily measure - when the machine is otherwise
quiescent. Someone needs to stop citing problems from the last
millennium as still being current...
> IS>> How does it matter? Usually, I start Emacs every few weeks or
> IS>> so (depending on the power blackouts here), and then have it
> IS>> running (or, mostly, ``sleeping'') inside a Screen session.
>
> Not pretty solution!
Agreed. He needs to put that machine on a good UPS so that it doesn't
need to be rebooted so often. I only reboot my Unix systems to apply
system patches...
Donal.
Ivan Shmakov
Hash: SHA1
>>>>> "DKF" == Donal K Fellows <donal.k...@manchester.ac.uk> writes:
>>>>> "R" == Rodericus <sc...@web.de> wrote:
>>>>> "IS" == Ivan Shmakov <i...@main.uusia.org> wrote:
R>> Since long ago it takes seconds to start.
DKF> FWIW, on this system (6 years old?) the startup time of Emacs is
DKF> near- instant - too fast to easily measure - when the machine is
DKF> otherwise quiescent.
The Emacs start-up time depends also on the libraries loaded
from ~/.emacs, as well on the major and minor modes loaded for
the file or files specified via the command line.
DKF> Someone needs to stop citing problems from the last millennium as
DKF> still being current...
The millennium may have be gone, but the hardware is still
there.
IS> How does it matter? Usually, I start Emacs every few weeks or so
IS> (depending on the power blackouts here), and then have it running
IS> (or, mostly, ``sleeping'') inside a Screen session.
R> Not pretty solution!
DKF> Agreed. He needs to put that machine on a good UPS so that it
DKF> doesn't need to be rebooted so often.
The UPS isn't an extra, anyway.
DKF> I only reboot my Unix systems to apply system patches...
So do I.
Sans the occasional necessity to reboot my machines a few times
in a row (say, replacing the kernel, and then realizing that the
userspace tools doesn't support it), the typical uptime for my
systems ranges from weeks to months.
- --
FSF associate member #7257
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkstqLkACgkQMBO2oCMOM0oZHQCfUFMna6R2ufn/FhkUgIQLxvys
89AAoL+bUr+IuRbppUQRKiSZqm8tjO1n
=+FX6
-----END PGP SIGNATURE-----
Rodericus
> On Dec 18, 1:48 pm, Rodericus <sc...@web.de> wrote:
> There is no local only solution if you use helper functions, the
> example below just demonstrates the equivalent syntax for Tcl (which
> doesn't support the file based variable scope).
If you are using non recursive function calls, then you could also
write a (main) program not calling any function. Writing recursive
programs is easier, I always try to avoid it, for making it more
efficient.
> This series of experiments indicates that if speed is important, it is
> better to keep an open mind as to the organization of the program. But
> the key is organization.
I preffer analytical arguments than empirical ones with examples.
Those that write operating systems are aware also of how the C
compiler makes the object code.
> Most valid complaints about things like goto
> is that they lend themselves to becoming hacks and help produce
> spaghetti code.
Programs with goto can be more efficient, shorter, and much better
readable. The argument against it was more or less ideological. You
can find this discussions with google.
Rodrigo.
Rodericus
<donal.k.fell...@manchester.ac.uk> wrote:
> On Dec 18, 10:11 pm, Rodericus <sc...@web.de> wrote:
>
> > On 18 Dez., 12:46, Ivan Shmakov <i...@main.uusia.org> wrote:
> > R>> Since long ago it takes seconds to start.
>
> FWIW, on this system (6 years old?) the startup time of Emacs is near-
> instant - too fast to easily measure - when the machine is otherwise
> quiescent. Someone needs to stop citing problems from the last
> millennium as still being current...
The editor (n)vi is 277.820 bytes big, depends only libcurses.so,
libc.so (bsd) and ld.so. The multimedia text editor Emacs that I never
use for something else than editing texts is 4.969.524 bytes big, it
depends on 22 libraries, among them libtiff.so, libjpeg.so, libpng.so,
libungiff.so and libossaudio.so. Indeed, I work with a computer of the
last milenium. Until few years ago I worked with an old laptop with
less than 4MB running NetBSD. When you start emacs the first time it
is slower than starting it again, I dont know why. And indeed, the
initial lisp libraries makes it slower.
Rodrigo.
Rodericus
> I've never used one, but the rumors are that the Lisp Machines
> were taking a lot of time to boot. So, preasumably, their users
> weren't booting them all too often.
Indeed, starting Emacs is like booting the system.
> On the other hand, Emacs is certainly /prettier/ than the other
> text editing-oriented Lisp implementations, since it works.
>
> The software that doesn't work cannot be pretty.
This is the reason of fatware inflation. The only thing that matters
when developimg is that it works. Developers rely on powerful
hardware, not only on the existent one: they write for the hardware of
the future.
Rodrigo.
Donal K. Fellows
> The argument against [goto] was more or less ideological. You
> can find this discussions with google.
The argument's really a three-way one, between the extremists on
either side, and the pragmatists in the middle. The extreme pro-goto
position isn't seen very often though; you're the first person I've
seen expound it for a while now. FWIW, you're in the position of
advocating something that is sufficiently unpopular that people
(reasonably) believe it was comprehensively defeated. I hope you've
got new arguments to bring to the table...
Donal.
Donal K. Fellows
> Until few years ago I worked with an old laptop with
> less than 4MB running NetBSD.
What rock were you hiding under? I calculate (comparing with this
machine and applying Moore's Law in reverse) that that system is
approximately 15 years behind the state of the art (maybe more). While
yes, it was current enough back in 1995 I suppose, it's really not up
to coping with a real workload. Nobody really cares about supporting
such ancient kit, nor does anyone care about the performance of any
application on it. My phone, not a top of the range model by any
means, massively outperforms it.
If you think Emacs is big and bloated, try Eclipse on a mixed Java, C+
+ and J2EE project, and remember that people use it for real and are
highly productive.
Donal.
Ivan Shmakov
Hash: SHA1
>>>>> "DKF" == Donal K Fellows <donal.k...@manchester.ac.uk> writes:
>>>>> "R" == Rodericus <sc...@web.de> wrote:
R> Until few years ago I worked with an old laptop with less than 4MB
R> running NetBSD.
DKF> What rock were you hiding under? I calculate (comparing with this
DKF> machine and applying Moore's Law in reverse) that that system is
DKF> approximately 15 years behind the state of the art (maybe
DKF> more). While yes, it was current enough back in 1995 I suppose,
DKF> it's really not up to coping with a real workload. Nobody really
DKF> cares about supporting such ancient kit,
Actually, there're some retrocomputing activists, such as yours
truly, which have and occasionally use even older hardware.
(And yes, I do own a working ZX Spectrum clone.)
... Sometimes, you're getting this reccuring feeling that the
programmers of yesterday were much clever, being able to put
what've seemed the whole world in just a few kiB of machine
code. And it's, of course, just a feeling.
But this view is not that uncommon among the ``amateur''
programmers. On the one hand, investing a lot of effort into
programming, not to talk about the occupation proper,
occasionally leaves one little time to do much anything else,
including reading computer-related magazines, or exploring the
new computer hardware in the nearby shops.
On the other hand, while a novice programmer feels limited by
his or her own hardware, a more experienced one tends to feel
him- or herself limited by his or her own brain. Alas, the
upgrades for the latter are nowhere to be found.
These two observations sometimes lead one to conclusion that the
ever-rising hardware requirements of software are something
unnatural, and that the hardware upgrades are something related
to the world of non-programmers, something to be avoided. Add
to this the usual conservatism of any sufficiently developed
animal (including human), the necessity to attach to things,
and... well, the picture doesn't look that good.
DKF> nor does anyone care about the performance of any application on
DKF> it.
[...]
DKF> If you think Emacs is big and bloated, try Eclipse on a mixed
DKF> Java, C++ and J2EE project, and remember that people use it for
DKF> real and are highly productive.
That's what, well, we?, call professional programming.
- --
FSF associate member #7257
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksuYPIACgkQMBO2oCMOM0qnVgCgxzOFzazsTUjPBXckEyKB2Mv9
+c0AoPlNmy46LAeSbEM+xHOuyVvqJlHE
=sGho
-----END PGP SIGNATURE-----
Ivan Shmakov
Hash: SHA1
>>>>> "R" == Rodericus <sc...@web.de> writes:
>>>>> "IS" == Ivan Shmakov <i...@main.uusia.org> wrote:
IS> I've never used one, but the rumors are that the Lisp Machines were
IS> taking a lot of time to boot. So, preasumably, their users weren't
IS> booting them all too often.
R> Indeed, starting Emacs is like booting the system.
Well, anything having a rich set of tools with a general purpose
programming language at its core is like an operating system.
Anyway, as I've said before, I prefer not to boot Emacs often.
IS> On the other hand, Emacs is certainly /prettier/ than the other
IS> text editing-oriented Lisp implementations, since it works.
IS> The software that doesn't work cannot be pretty.
R> This is the reason of fatware inflation.
No, it isn't.
R> The only thing that matters when developimg is that it
R> works. Developers rely on powerful hardware, not only on the
R> existent one: they write for the hardware of the future.
I doubt so. While it can be true for professional programming
(in my experience, companies are much likely to pay for the
hardware, rather than to the employees), in the amateur
programming world there's no one to pay for one's hardware but
the one him- or herself. As a volunteer, one simply uses the
hardware that's available to him or her, whether it's powerful
or not.
The thing that dictates the direction this world will follow is
motivation. Those who're sufficiently motivated to develop
Emacs (paying mind not only to their own demands for it, but
also, to an extent, to the demands of other users), do it and,
thus, determine the direction of the development.
Those who lack the motivation to participate in the development,
don't.
Those who believe in Emacs and its users, those who have enough
spare time, and those who believe that there're things yet to be
added to it, develop it.
Those who tend to think that Emacs is broken beyond all repair,
that it was once good, but was changed and isn't any longer, and
those who have no spare time to invest, don't.
Whoever does the work makes the decision.
PS. ... And if one doesn't care about the Emacs development, why the
Emacs developers should care about him or her?
- --
FSF associate member #7257
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksuZ2YACgkQMBO2oCMOM0pHUwCeJVHWCfD7L208nKtW0Wle8NrC
+b0Anifzrg50aPpfTS9f2j80+5/q8v9g
=+AEg
-----END PGP SIGNATURE-----
Kevin Kenny
I've had rather a lot to say on the issue in the past, and on
rereading what I've had to say, I see no need to say it again.
Interested readers can find a twenty-year-old essay of mine at
starting around post #85 in the thread. My essay probably needs
to be understood in the context of Knuth's 1974 classic,
"Structured Programming with GO TO statements," which can be found,
among other places, at
http://compilertools.googlepages.com/Knuth-StructuredProgrammingwithgotos.pdf
--
73 de ke9tv/2, Kevin
Rodericus
> My phone, not a top of the range model by any means, massively outperforms it.
A computer is not only a processor. Under circumstances periferals
like keyboard and screen are much more important than the hardware
inside, specially if you are using the computer as a typewriter. My
first programming experience was with pocket calculators (HP 25, Casio
fx 502p): inspite of the limitation I did programs that did
meaningfull calculations for me. An old laptop is much more than a
typewriter or a pocket calculator, and at a public library or archive
you need to care of it less than of your telephone when you make a
pause. Old microprossesors, even the oldest ones like 8038, are beeing
produced till today for control purposes. I think it would be nice if
Tcl continue running on old hardware.
> The argument's really a three-way one, between the extremists on
> either side, and the pragmatists in the middle. The extreme pro-goto
> position isn't seen very often though; you're the first person I've
> seen expound it for a while now.
Do you think, the pragmatists forbide or completely hinder the use of
goto like the proponents of structured GOTOless programming? I like
the possition of K&R: they did not encourage the use of goto, but put
one in C.
My first computer programming language was FORTRAN IV, it is like my
programming mother tongue, for many engeneers and scientists also.
FORTRAN is alive, among those that do numerical calculations, not
among computer scientists. Physicists and electric engeners tend also
to program in assembler like any other language. These are programming
languages with no other control flow than goto. The feeling for goto
is, that it is a control flow primitive, that while, for, etc are just
nice abreviations for some common structures of control flow. And from
the point of view of the machine this is the case. There are other
structures that are easily circumscribed with structured programming,
perhaps so easy that you do not need to add new variables, but in many
cases you feel gotos much more natural.
Computer scientists are educated with other languages, they have other
mother tongues, not only gotoless structured languages, perhaps object
oriented or functional. In the whole discussion for and against goto
you find continously the argument: I can do it my way (with or without
goto) and this is what I would naturaly do. The discussion is only
because you become aware of other ways of coding not a waste of time
(see post of Kevin Kenny), but it has a big component of discussing
about taste.
> FWIW, you're in the position of advocating something that is sufficiently unpopular that people
> (reasonably) believe it was comprehensively defeated. I hope you've
> got new arguments to bring to the table...
It is neither unpopular nor defeated. And I have no new arguments, I
think there arent. The whole discussion is exhausted with casuistics.
Most people like to hear music, other not only like to hear music, but
also to be heared that they are hearing their predilect music, and
mostly they are very loud.
Object orientation was added to Tcl, but no goto instruction. Sure was
John Ousterhout against goto, but it would be nice if someone asks
him, what does he preffer, goto or objects in Tcl, and brings the
answer to this newsgroup.
Rodrigo.
Uwe Klein
> Physicists and electric engeners tend also
> to program in assembler like any other language.
True enough. Any tool that does the job is OK.
( though some tools are more equal than others ;-)
> These are programming
> languages with no other control flow than goto.
Balooney!
I have still to see an instruction set that does
not have some form of
call some code elsewhere and return to this same place.
( with more or less state saving )
AND:
goto is definitely not control of programm flow.
If, while, ... or jump bit set, branch on zero ....
with the most primitive being "skip next cmd on <flag>"
thats control of programm flow.
uwe