1. Re: crash_message
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Sep 03, 1999
-
Last edited Sep 04, 1999
> In light of all this, doesn't it make sense that an attempt is
> made to stay with the paradigm? I mean, I like a lot of
> languages that have 'gotos' or that let the programmer mess
> things up royally in exchange for power, but it seems clear
> that such things don't fit in with Euphoria. No offense Ralf,
> but you seem to dislike all (or most) of the above positive
> benefits of Euphoria. Why do you even use it?
Your points due create some annoyance, you're totally right.
But from another perspective, Euphoria is the most flexible language I can
come up with.
How many languages will let you manage variables in such a flexible (and
fast!) way Euphoria does. Lastly, I'm a hobbist more than anything. I like
to experiment. Secondly, I do like some of the strictness, if forces me to
limit my goals into something 'do-able', it creates a world ("rules are the
environment of a thought") which is challanging. You need 'rules' or a more
clear goal. Since all my programming lacks the last, eh. ..
Besides your points are not comparisable. Euphoria was (my assumption) is
based upon the compromize between needing as little expressive methods as
possible, yet retaining as much safety, flexibility, performance and power
of expression as possible. It does this, using those rules. But a
crash-routine feature is inline with this ideology. A goto is however, a
little less clear.
Irregardless of wether or not the current include mechanism is the most
perfect choice, having rules about it, is a choice on itself, do you give
programs more freedom, or less: enforcing patterns of communication. I hate
to say it, but the compromize is comparable to that of GUI. They are not as
expressive, but you pick 'em up quick, and they are consistent, at the cost
of use-efficiency. I mean, there are many cases where I was unaware how to
perform certain tasks using a DOS program, while when using a GUI/Window
based program, eveyrthing is clear. That too, are rules, and they have the
same advantages and disadvantages.
However, goto's, like with the short-cutted if-statements, are sometimes
almost irreplacable. (a label + exit (label) mechanism is btw what I
propose, rather than goto). A crash function however, is something totally
different. Its not part of the language, but of the implementation. I see a
clear distinction between the two. Currently, there isn't an alternative to
do something like this: therefor there is most certainly a place for it, in
some form. You might be tempted to use a goto, when its' implemented, when
you're feeling lazy, there I can understand your problem with it, but this
is not the case with a crash0\-routine.
But here's the last point, to still strenghten the goto-case rather than
weaken it. You don't have to use it. So your problem is the 500 bytes add to
the interpreter's parser code, and the fact that the goto definition is part
of the documentation. For this, I ask you, could you bare this pain, just
for me and those few others that _would_ use it occasionally ? Could you ?
Or is this too much effort to ask ? Yes, sarcasm, my point: no one can vote
against a feature that doesn't impact on a library-program level. Its as
ridiculas as the laws about wearing your seatbealts. Its' really not your
problem, and maybe, just maybe others don't see it that way. Maybe the
problem lies with the one seeing it as a problem.
Ralf N.
-- Its interesting how much of these discussions, eventhough
computer-related, show perspectives originating from different life styles,
and perspectives.
