party cancelled
Ok, guys, I am sorry, but there is going be no party. Insufficient
interest. Hawke was obviously keen, but unwilling to contribute. David
tried to sneak in, but was caught and disqualified. The guy obviously
makes too many mistakes and is looking for a more fault tolerant
system, but that would be a new feature and the party invitation
clearly specified only hatable *existing* features were admissible.
So now I have the unenviable task to deal with (some will say to) the
defenders of the faith.
First I will tackle 'irresistible' urges of John DeHope. John wrote:
>"case sensitivity"
>
>Euphoria does one thing that so many other languages don't: it makes you
>be a good programmer.
John, it's never that easy - you have watched too many TV commercials
if you really believe that. Seriously, I have change my mind on this
one so many times, I am not quite sure where I stand right now 
,
but the only significant benefit of case sensitivity is that it allows
you the lazy 'x' and 'X' as two distinct variables and set and Set and
SET as separate routine names - a programming practice which is very
difficult to recommend.
>"unnecessarily long words and redundant brackets"
>
>Again, readability. So many people shrug off this issue as if it didn't
>matter. The only people who think readability isn't an issue are A)
>people who have never had to debug or alter somebody else's code, and B)
>people who have never had to debug or edit their own code 3 months after
>they write it. Short, illegible syntax is bad: EU is good.
What's EU again? (Beautifully observed, David! Thanks.)
>"constants"
>
>It boggles my mind that anybody could really consider constants to be a
>bad thing. At this point I wonder if Jiri is just being silly.
Unfortunately, this item is slightly out of context, it would make
more sense following my 'automatic variable declaration' fiasco. I am
not saying the constant is a bad thing, but there is nothing
inherently special about it either. It is just a container with a
label, a piece of data, just like any other variable. So if you do not
want to change it, don't. And if you do not trust your memory,
capitalize its name, as I suggested previously. (In some programming
environments constants could be fetched faster than normal variables,
then, of course, it makes more sense to have a separate mechanism.)
>"comma separator"
>
>Maybe I have gone too far, because this is really going out on a limb.
>Jiri: You are kidding, right?
No, not kidding. Read again David's comment. It is quite refreshing,
because *he* knows what he is talking about!
>"curly brackets"
>
>This improves readability. The concept of a sequence it totally foreign
>to anything except Euphoria, it needs its own syntax.
In what possible way do the curly brackets improve readability? As you
said - mind boggles! I have studied dozens of languages (and used many
of them) so please believe me the concept of a sequence is nothing new
under the sun. I fact, there is probably not a single element of
Euphoria, taken in isolation, that cannot be found elsewhere. What is
pretty unique is a very clever selection of various bits and pieces,
and the way Robert beautifully welded the lot together.
>"types, type checking"
>
>I'm going mad! Please, somebody that knows Jiri, tell me he is just
>kidding!
I know jiri quite well and he is not going mad either. To use David's
phrase, there are no compelling reasons for types and type checking in
Euphoria. Once again I draw your attention to David's own comments,
and he has probably done more programming in Euphoria than the rest of
us together! And if that is not enough, I'll quote from the Master's
letter (Robert is not around at the moment, but I am sure he would not
mind). This was in response to my suggestion that types and type
checking were really nothing more than a debugging tool of doubtful
value:
>In the beginning (pre-1.0), all variables were declared as object.
>There were no types.
>About half way through coding language wars I found that
>this hurt the readability of the code, because I started to forget
>which variables normally contained sequences, and which
>contained atoms. That's when I worked out Euphoria's strange
>"type" mechansim. I created built-in types "sequence" and "atom",
>and then I wanted a way for the user to add his own types. ("integer"
>came later). With user-defined types, my intention was to
>have a debugging aid (and to some extent a documentation aid).
>It's a way of catching logical errors. I was thinking more in terms of
>very large projects, with many programmers.
Later on, when I suggested that a non-programmer user was not going to
be helped or impressed by "type check failure in line nnn" error
message, this is what Robert had to say:
>It was never my intention that user-defined types be used to validate
>user input. Types should only be used to enforce *internal*
>consistency of the program.
To be quite honest, I did not find that terribly convincing. So if
somehow they enhance your confidence, please, go on and use types as
much as you like, but at least until I find how 'enforced internal
consistency of the program' can really help me, I will follow David's
lead and shy away from them.
>"variable declaration"
>
>I can't go on. Nobody can question the wisdom of undeclared variable
>errors. RDS has come so close to creating the perfect programming
>language... this must be a joke.
No joke, he said with a dark promise in his voice... Should I ask what
is so innately wise about an error message. Appropriate perhaps, but
wise? Ok, let's take it slowly: what is a constant and what is a
variable is sometimes a difficult choice, and very often what started
its life as a constant becomes a variable, as the complexity of the
program increases. My point is the decision is often quite arbitrary.
When we declare our constants, we are quite happy to leave it to the
interpreter to fit them with the appropriate types internally. But
when it comes to variables, for some inexplicable reason and for *no
obvious benefits* we insist on telling the compiler what sort of
container we require when it is perfectly capable of deciding that on
its own.
It is just a modern trend in language design that also makes sense. If
you have listened to my argument and can now accept that *explicit*
types are completely redundant, then all we really need is a generic
object, and this proposition is just a logical extension of the
argument. I repeat: a variable can be implicitly, automatically
declared by the very first assignment of a value to it. In other
words, when you say x=20, for instance, the compiler checks the table
of variables for 'x', and if it finds it, it just changes the value.
If it does not, it simply creates a new object, an integer in this
case, with an appropriate label. An uninitialized variable would still
be flagged, so if you say y=x before 'x' is implicitly declared, you
would still get the usual dose of compiler 'wisdom' that you seem to
cherish so much.
Lastly and sadly, Alan Tu. Alan, this is not easy, because I am really
angered by you repeated demands that I get off the list. So I'll give
you just a couple of free tips: when you do not understand something,
it is not necessarily the writer's fault, more often it is your own
ignorance. And when you have absolutely nothing to contribute, just
shut up! I do. jiri
|
Not Categorized, Please Help
|
|
