From: Aric Bills on
On 21 déc, 06:16, Rodericus <sc...(a)web.de> wrote:
> Donal K. Fellows schrieb:
>
> > 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.

Ousterhout didn't have a big problem with objects in Tcl, as he made
clear in the following article: http://home.pacbell.net/ouster/scripting.html
..
From: Uwe Klein on
Rodericus wrote:
> On 21 Dez., 17:26, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote:
>
>
>>Now, with the duality of code and data in tcl
>>you can take a better hammer from your toolkit.
>
>
> What I do not explote, better said: avoid.

So every problem turns into a goto ;-)

Being able to construct code programmatically,
loading variables with code and having
that code excecuted as desired is imho
one of the core benefits tcl provides.

It does not make sense to derive from the
limitations of one language the restrictions
you apply to another one.

With tcl jumping through the hoops you
are used to from another language
will have you flat on your face in
this programming environment.

uwe
From: Rodericus on
On 21 Dez., 18:17, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:

> Both the Knuth paper and your's [Kevin Kenny's] are great reading.

Inded, both are great reading. Are you now convinced, never to use
gotos?

Rodrigo.


From: Rodericus on
On 21 Dez., 18:52, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote:

> Being able to construct code programmatically,
> loading variables with code and having
> that code excecuted as desired is imho
> one of the core benefits tcl provides.

If the process cannot go to the code, the code goes to the process.

With your technic you cannot translate your programs easily to other
languages.

Rodrigo.
From: Uwe Klein on
Rodericus wrote:
> On 21 Dez., 18:52, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote:
>
>
>>Being able to construct code programmatically,
>>loading variables with code and having
>>that code excecuted as desired is imho
>>one of the core benefits tcl provides.
>
>
> If the process cannot go to the code, the code goes to the process.
>
> With your technic you cannot translate your programs easily to other
> languages.

Whatever circumstances would make me want to do that?

A tcl interpreter can be ported to about all systems ( and current
availability of ports is better than most other software ).
if not bloaty mainline tcl than jim or another small footprint version.

Over the years I have noticed that I invariable write applications
that are separated into engine, auxiliary items and script fodder.

Why should I write the engine again and again?

uwe