1. party cancelled
- Posted by jiri babor <jbabor at PARADISE.NET.NZ>
Sep 10, 1998
-
Last edited Sep 11, 1998
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
2. Re: party cancelled
*sigh* again i hesitate to reply...but...
{jiri}
> 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.
to be fair, before my 'real reply', and to emphasize this ever
so crucial point, i wholeheartedly agree.
an example that bit me quite viciously only recently:
whilst working on the truecolor library, just before my severely
fatal winBLOZE crapout, i decided to declare some constants for
color... simple enuff? Black={0,0,0} and Blue={150,0,0} and
Red={0,0,150} and Green={0,150,0} and etc etc etc (BGR by the way)
good so far right? well, when the mouse cursor decided to wrap
itself on the right edge of the screen to the left, i had to
enter that ever so fun 'fullblowndebugthisdamnthingmode' that
we have all done once or twice. lo! and behold! the library
included another file (graphics.e i think it was) that had
already!!! defined BLACK= WHITE= GREEN= etcetcetc...
ewwww nasty, bad bad thing, bad form!
this coulda reeked bloody havoc had I not caught it, from
some coder using this library, and trying to track down
BLACK versus Black...yuck!
onwards:
{jiri}
> 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,
ummmm.... perhaps???... maybe??? you didn't fully read 'the masters
letter'
as he says WHY!!! generic objects only as our choice are 'bad'.
{robert}
> >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.
Your suggestion to simply capitalize the first letter if it's
a constant (or whatever) really -wont- solve the problem
robert is referring to. Namely, readability!.... a very very crucial
concept, that goes byebye if you attempt 'naming conventions' that
aren't standardized in some fashion. What if joebob capitializes
the third letter if it's int, and the first if it's sequence whereas
bettyboob uses all cap except the second letter if its an atom...
see???? Without some amount of 'typing', even if it is 'fake' (such
as a strictly adhered to naming convention used by *all*),
readability (and even maintainability) just suffers horridly.
{jiri}
>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.
I could agree that having the interpreter do that, automagically,
as it does for constants anyway, might just be a good thing.
It would be the next logical extension to the arguement that
inspired EU (datsa Euphoria :) ) by robert. That C++ (for ex)
was just overburdened with overtyping (pascal aint far behind)
and it spawned the need for a separate routine for *each* data type.
Counterpoint? Can you proffer a solution, implementing this suggestion,
that does not hurt readability, elegance, efficiency (after all, having
the interpreter do all that 'figuring' might slow it down...easy
enuff to get around too i suppose...), maintainability,
portability, and reliability?
{jiri}
> 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.
this of course would be mandatory, in an 'object' only language.
to sum up: you seem concerned with readability, as marked by
your arguement for case insensitivity (which woulda flagged
my example real fast, and saved me and perhaps others a lotta
headaches), and this concern is good (IMO).
But, then... it seems to me that you almost revoke that
concern by taking away all 'typing' completely, and whilst
doing so, fail to offer an equitable solution to the
dilemma robert (and anyone else who has worked on a program
that is thousands of lines long) faced with readablity
and maintainability.
*shrug* that's just how i see it...
--take care all, and remember, if it wasn't for typos,
none of us would get any programming done at all, and
the term 'pre-alpha' would be meaningless (the horror!)
:)
*watches the ruffled feathers settle slowly, liltingly to
the computer printout riddled floor*
--g'night--Hawke'
all opinions expressed by my words are words that expressed my opinions.
3. Re: party cancelled
jiri babor wrote:
> >"unnecessarily long words and redundant brackets"
> >
> >they write it. Short, illegible syntax is bad: EU is good.
>
> What's EU again? (Beautifully observed, David! Thanks.)
For a newbie, EU is unknown. For "us," it's known. But it really doesn't
matter here.
Your point about somebody using "EU" outside programming is irrelevant. The
points regarding readability applied to program code that may need to be
altered/debugged/whatever, in the future, not informal electronic
correspondence.
cha-ching (two cents down the drain)
ck
4. Re: party cancelled
Hi
I think that case sensitivity is a good thing. What I find is that I
try to make my code self documenting by choosing nouns for variable
names and verbs for procedure and function names, and that I often
run out of synonyms for closely related items. Often enough too,
the appropriate word is already in use as a reserved keyword. The
ability to distinguish words by case give a much larger number of
useable names that are suggestive of the action they are associated
with.
The only argument I can see against case sensitivity is just that
people have trouble typing capitals - you know - hitting two keys at
once requires advanced digital coordination.
Why would anybody mind constants? If you use them they're handy, if
you don't they are not. Why deny them to those who like them?
Is there a proposal for a substitute for curly brackets? There aren't
all that many non-alphanumeric keys on my keyboard that don't need a
shift.
I use typechecking when I'm debugging during development. It's very
useful then, and can be turned off when you don't need it. What could
be the problem with it being included in Euphoria as an option,
instead of as a requirement as it is in most other languages that
I've seen.
Party on dudes
Bye
Martin
5. Re: party cancelled
[CasE SensiTiviTy]
>I think that case sensitivity is a good thing. What I find is that I
>try to make my code self documenting by choosing nouns for variable
>names and verbs for procedure and function names, and that I often
>run out of synonyms for closely related items. Often enough too,
>the appropriate word is already in use as a reserved keyword. The
>ability to distinguish words by case give a much larger number of
>useable names that are suggestive of the action they are associated
>with.
>
>The only argument I can see against case sensitivity is just that
>people have trouble typing capitals - you know - hitting two keys at
>once requires advanced digital coordination.
Fact: Programming uses lots of shift characters. That's why we make the
big bucks. (Well, sorta... just take out the 'big', and maybe the
'bucks'...)
I think case sensitivity is good, if keeps you from writing "ThIs" in
some places, and "This" in others, and "this" in still other places, all
meaning the samething. Instead, you can use all those as different
variable names!
Also, if you don't want to make your variable/constants/subroutines use
uppercase letters, don't. It's as simple as that.
Okay, so I don't see this coming to an end, there's no good argument on
either side. Let's just keep it as is so it gets compiled faster. (There,
we win!
[constant CONSTANT]
>Why would anybody mind constants? If you use them they're handy, if
>you don't they are not. Why deny them to those who like them?
Constants are good. Code that uses constants like PI will run just as
fast as programs that replaces the constant with the number, 3.14(more
numbers), and be more readable. Plus, if for some reason PI should happen
to change, you only have to change one number in the code . . .
[SHIFT+characters]
>Is there a proposal for a substitute for curly brackets? There aren't
>all that many non-alphanumeric keys on my keyboard that don't need a
>shift.
This is also why the suggested {30 (50+40) (40-3) -5} will fail. It
requires more shift9 and shift0's than the old style commas.
The reason the curly braces are used, is because that's what's used in C
for similar stuff:
// C code!
// Don't remember if this only works for constants or not, but I have
// done this with either variables or constants.
int sequence[5] = {0, 1, 2, 3, 4};
// Ah, safe
(Now somebody is going to bring up variable initializations in the
declaration, ie integer x=0, which I can agree with.)
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
