1. My 10c on namespaces
I've been lurking with interest ever since Rob mentioned that he would be
attempting a
solution to the namespaces issues in Euphoria 2.3. Taking a step back from
the proposals:
Whatever the technical syntax Rob goes for, I hope that these factors are
considered, in order:
1. Clarity.
2. Flexibility
3. Redundancy of previous code
Clarity comes first, because its of vital importance for the program creator
(and anyone else)
to understand what the intent of the code is. Hopefully with a minimum of
comments or
reading manuals. A silly example: Personally I don't code in the format "a
+= 1" because:
a) Its more obscure than "a = a + 1" and therefore harder to understand,
particularly for newbies.
b) It appears to be a "neat trick" from another language. Why? Who are we
trying to impress?
c) Using it makes old code break, for virtually no gain.
d) Why are we wasting Rob's time, altering his parser for something so
inconsequential?
We are using Euphoria because it is clear, easy, stable, quick etc. Not
because it is the same as
something else.
Flexibility - as in the solution/syntax should allow for as many factors as
possible. Eg, have a
solution that elegantly (and clearly) handles subsequent references to a
variable as the second
reference. Don't build in restrictions that are not required. Do have
meaningful error messages
and options that can be used on demand.
Redundancy.. ie breaking of old code is less important then the
abovementioned two factors
IMHO, despite argument to the contrary . Why?
a) Euphoria must move forward. Using an obscure solution that does not break
old code may set us
up for a headache that will never go away. The listserv will abound with
the same tired explanations
of why it works that way. Answering the "Why couldn't Euphoria have done
this easier (CLEARER)"
and "Why does this (seemingly obvious) code not work" will be right up
there with the "How do
I get off this list" used to be, or "deleteItem does not work"... Ring a
bell, Derek ?
b) How much old code do we REALLY use, both in bytes and in persons doing
it? With the
exception of Win32lib, I would suggest not much. IMHO those skilled
enough to include others'
code, will be skilled enough to make the required changes. I submit that
most old code written
by others is purely reference material.
c) Nothing is stopping us from binding old code and using the executable,
until such time as we
get around to correcting the breakages brought about by the namespace
solution. Even simply
persisting with the old release of Euphoria would work.
Rob, how about putting the suggestions up on rapideuphoria.com , and
allowing licenced users
to vote? Each methodology to have the pros and cons mentioned.
You don't have to go for the most popular of course ;)
Regards,
Alan (now ducking for cover)
2. Re: My 10c on namespaces
> Rob, how about putting the suggestions up on rapideuphoria.com , and
> allowing licenced users
> to vote? Each methodology to have the pros and cons mentioned.
> You don't have to go for the most popular of course ;)
>
> Regards,
> Alan (now ducking for cover)
My vote is not to have this extra added hasle....
I cant say for sure that the namespace fix will benefit me,
other than makeing me type more, learn more, read more,
become confused more, make me want to use C or Java.
hmmmm maybe thats a good idea!
Euman (now ducking for cover)
3. Re: My 10c on namespaces
----- Original Message -----
From: Euman <euman at bellsouth.net>
>
> My vote is not to have this extra added hasle....
>
> I cant say for sure that the namespace fix will benefit me,
> other than makeing me type more, learn more, read more,
> become confused more, make me want to use C or Java.
> hmmmm maybe thats a good idea!
But, it won't affect you at all.
Just keep using the current version, and you won't have to learn anything.
Make a few backup copies, and you'll have that option forever.
Those of us who want or need a more professional development tool
will continue to lobby for a more professional tool. If we see that we
aren't likely to get it here, we'll move elsewhere.
With all Euphoria users either satisfied or gone, Rob can retire.
Regards,
Irv
4. Re: My 10c on namespaces
Hello Alan,
>Whatever the technical syntax Rob goes for, I hope that these factors are
>considered, in order:
>1. Clarity.
>2. Flexibility
I whole heartedly agree with these. I, however, believe in re-using
code. This is not why I responded though.
>A silly example: Personally I don't code in the format "a += 1" because:
>a) Its more obscure than "a = a + 1" and therefore harder to understand,
>particularly for newbies.
I completely DISagree with the idea that the += style operators
take away from the clarity of code. This shortcut was not
intended for the purpose your example demonstrates. It is meant
to shorten AND clarify (by means of making easy reading of)
code that would otherwise have to be done like this:
objects[Object][Location][X] = objects[Object][Location][X] +
objects[Object][Velocity][X]
With the (-+*/&)= operators we can shorten it to:
objects[Object][Location][X] += objects[Object][Velocity][X]
You don't have to scrutinize the code to tell that the first
expression is being being used as both the recipient of the
assignment and a part of the equation as well. The former way
makes you look closely to make sure it's not something ELSE
that is being added to. What about this code:
objects[Object][Location][X] = objects[Object][Location][Y] +
objects[Object][Velocity][X]
If you dont' look close enouph you might think it is the same as
my first example.
>c) Using it makes old code break, for virtually no gain.
No it doesn't! You can still use the longhand method. You said that
you do so yourself. The only thing that breaks is if you try to use
this new shorthand in code that you run with an old interpreter.
And since the new interpreter is just as free as the old one was,
there is no reason to do so.
I agree with most of the other stuff you said.
later,
Lewis Townsend
5. Re: My 10c on namespaces
> ----- Original Message -----
> From: Euman <euman at bellsouth.net>
>
> >
> > My vote is not to have this extra added hasle....
> >
> > I cant say for sure that the namespace fix will benefit me,
> > other than makeing me type more, learn more, read more,
> > become confused more, make me want to use C or Java.
> > hmmmm maybe thats a good idea!
>
> But, it won't affect you at all.
> Just keep using the current version, and you won't have to learn anything.
> Make a few backup copies, and you'll have that option forever.
>
> Those of us who want or need a more professional development tool
> will continue to lobby for a more professional tool. If we see that we
> aren't likely to get it here, we'll move elsewhere.
>
> With all Euphoria users either satisfied or gone, Rob can retire.
>
> Regards,
> Irv
namespace is inconsequential in relation to alot of things I would
have chosen to be the next upgrade......
I would like to see Internet based production maybe along the lines
of CGI, ASP or JSP because this is where there seems to be a whole
for programmers.
Who cares whether or not two names are the same across procedures
(get an error go back and fix it, big deal.)
lets start thinking *CASH* here....
Euphoria could rule the Internet with its ease of use but you want a
namespace fix. huh............
Euman
6. Re: My 10c on namespaces
----- Original Message -----
From: Euman <euman at bellsouth.net
> namespace is inconsequential in relation to alot of things I would
> have chosen to be the next upgrade......
>
> I would like to see Internet based production maybe along the lines
> of CGI, ASP or JSP because this is where there seems to be a whole
> for programmers.
> Who cares whether or not two names are the same across procedures
> (get an error go back and fix it, big deal.)
> lets start thinking *CASH* here....
> Euphoria could rule the Internet with its ease of use but you want a
> namespace fix. huh............
We are trying for some improvements that we think have at least a small
chance of actually happening. Your wish - quite a reaonable one - has as
much chance as I have of winning the lottery without buying a ticket.
Regards,
Irv
7. Re: My 10c on namespaces
- Posted by gertie at ad-tek.net
Jun 28, 2001
On 28 Jun 2001, at 17:38, Euman wrote:
<snip>
> I would like to see Internet based production maybe along the lines
> of CGI, ASP or JSP because this is where there seems to be a whole
> for programmers.
Interconnectivity is the name of the info-sharing game (in my opinion).
> Who cares whether or not two names are the same across procedures
> (get an error go back and fix it, big deal.)
> lets start thinking *CASH* here....
>
> Euphoria could rule the Internet with its ease of use but you want a
> namespace fix. huh............
I would prefer threads and "goto" first!
Threads in the interpreter should be easiest, since it would be a simple matter
of
timeslicing and internal stacks. Let the OS do the slicing, each time the
interpreter
gets the cpu time, index to and process the next thread. <shrug> The compiler
should
be easy too, since it could use real OS threading, but i admit i don't know what
i am
talking about here.
Kat
8. Re: My 10c on namespaces
----- Original Message -----
From: "Alan Oxley" <fizzpop at icon.co.za>
To: "EUforum" <EUforum at topica.com>
Subject: My 10c on namespaces
Howzit Alan,
>
> Whatever the technical syntax Rob goes for, I hope that these factors are
> considered, in order:
> 1. Clarity.
> 2. Flexibility
> 3. Redundancy of previous code
>
> Clarity comes first, because its of vital importance for the program
creator
> (and anyone else)
> to understand what the intent of the code is. Hopefully with a minimum of
> comments or
> reading manuals.
I agree with all this stuff. And I'd even add "Simplicity" as well.
I have a big sign in my office that reads: "Is it Simple? Is it Clear?". I
need reminding of this principle often because its very easy to get complex
and obscure.
> A silly example: Personally I don't code in the format "a
> += 1" because:
> a) Its more obscure than "a = a + 1" and therefore harder to understand,
> particularly for newbies.
> b) It appears to be a "neat trick" from another language. Why? Who are we
> trying to impress?
> c) Using it makes old code break, for virtually no gain.
> d) Why are we wasting Rob's time, altering his parser for something so
> inconsequential?
Okay, here we differ. But ain't that just like us humans. Put 3 people into
a room and you get 4 mutually exclusive opinions!
When I first started to program in languages that used the "a = a + 1"
syntax, I found it very amusing because I came from a maths background, and
the formula "a = a + 1" doesn't make algebraic sense. I started with COBOL
and used the "add 1 to a" syntax - wordy it made sense to me. Later, when I
came across 'C' with its "a++" and "a += 1" syntax, I yelled "Hooray! Now
this is clever. This will make my code easier to understand." Weird eh!?
I went from writing such things as ...
(vCustomer->AuditCount) = (vCustomer->AuditCount) + 1;
to
(vCustomer->AuditCount)++;
which to my eye is simpler and clearer.
As for the "neat trick" idea. What's wrong with borrowing useful concepts
from other languages! Imagine if every language had to be totally different
from the next. You'd end up with APL or Forth 
The idea of avoiding neat tricks also sounds like a variation of the "not
invented here" syndrome.
How does using "a += 1" break old code? It might break old versions of
Euphoria though. But I'm sure don't mean that we should never upgrade
Euphoria to get improved functionality. If you don't want to use "a += 1"
then don't. No one is forcing you to.
Hmmmm, "inconsequential". And yet to me, this simple construct indicates a
maturity of thought in the product and an effort to make the users' life
easier. Nowadays I regard languages that don't support this construct as
old-fashioned and ornery. But this is all just opinion, eh?
> We are using Euphoria because it is clear, easy, stable, quick etc. Not
> because it is the same as something else.
Exactly! But this doesn't mean Euphoria is as good as it can get, yet!
> Flexibility - as in the solution/syntax should allow for as many factors
as
> possible. Eg, have a
> solution that elegantly (and clearly) handles subsequent references to a
> variable as the second
> reference. Don't build in restrictions that are not required. Do have
> meaningful error messages
> and options that can be used on demand.
Great stuff.
> Redundancy.. ie breaking of old code is less important then the
> abovementioned two factors
> IMHO, despite argument to the contrary . Why?
> a) Euphoria must move forward. Using an obscure solution that does not
break
> old code may set us
> up for a headache that will never go away. The listserv will abound with
> the same tired explanations
> of why it works that way. Answering the "Why couldn't Euphoria have done
> this easier (CLEARER)"
> and "Why does this (seemingly obvious) code not work" will be right up
> there with the "How do
> I get off this list" used to be, or "deleteItem does not work"... Ring a
> bell, Derek ?
Have not got a clue
> b) How much old code do we REALLY use, both in bytes and in persons doing
> it? With the
> exception of Win32lib, I would suggest not much. IMHO those skilled
> enough to include others'
> code, will be skilled enough to make the required changes. I submit that
> most old code written
> by others is purely reference material.
> c) Nothing is stopping us from binding old code and using the executable,
> until such time as we
> get around to correcting the breakages brought about by the namespace
> solution. Even simply
> persisting with the old release of Euphoria would work.
I'm a little confused here. Earlier you seemed to be concerned that "a += 1"
would break old code but now you're saying that is the price one pays for
progress. Did I miss something?
IMHO, I believe it will be possible to come up with a namespace solution
that will not force existing code to be changed.
> Rob, how about putting the suggestions up on rapideuphoria.com , and
> allowing licenced users
> to vote? Each methodology to have the pros and cons mentioned.
> You don't have to go for the most popular of course ;)
>
I've suggested this to Robert privately some time back. He would rather not.
He has another system for keeping tabs on wishlist items. I'm just glad he
is allowing us the opportunity to comment on this important addition to the
language before he commits it to code.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, work slower."
9. Re: My 10c on namespaces
- Posted by gertie at ad-tek.net
Jun 28, 2001
On 29 Jun 2001, at 10:26, Derek Parnell wrote:
> > Clarity comes first, because its of vital importance for the program
> creator
> > (and anyone else)
> > to understand what the intent of the code is. Hopefully with a minimum of
> > comments or
> > reading manuals.
>
> I agree with all this stuff. And I'd even add "Simplicity" as well.
>
> I have a big sign in my office that reads: "Is it Simple? Is it Clear?". I
> need reminding of this principle often because its very easy to get complex
> and obscure.
Like when trying to avoid using a "goto" by setting and repeatedly testing
flags. Or
using a while loop and an exit when a test for the exit condition at the bottom
and a
"goto start" would work easier.
> which to my eye is simpler and clearer.
>
> As for the "neat trick" idea. What's wrong with borrowing useful concepts
> from other languages! Imagine if every language had to be totally different
> from the next. You'd end up with APL or Forth
Like "goto".
> The idea of avoiding neat tricks also sounds like a variation of the "not
> invented here" syndrome.
>
> How does using "a += 1" break old code? It might break old versions of
> Euphoria though. But I'm sure don't mean that we should never upgrade
> Euphoria to get improved functionality. If you don't want to use "a += 1"
> then don't. No one is forcing you to.
Like using "goto".
> Hmmmm, "inconsequential". And yet to me, this simple construct indicates a
> maturity of thought in the product and an effort to make the users' life
> easier. Nowadays I regard languages that don't support this construct as
> old-fashioned and ornery. But this is all just opinion, eh?
Like,, err, nm, you get the idea.
Kat
10. Re: My 10c on namespaces
Kat wrote:
> I would prefer threads and "goto" first!
For a brief time, Dave had a "bug" in his PY interpreter which allowed
multiple includes of the same file, under different names. For example:
import blecch.pi as foo
import blecch.pi as bar
This was interesting to me, because I had just created two unique copies of
everything in file blecch: All the global variables, and all the global
routines.
(Most likely all the local variables and routines, also, but they werent
accessable)
Supposing I had a "connect" function in file blecch, I could have called
x = foo.connect("url 1")
y = bar.connect("url 2")
And, with some minor changes to the interpreter, I could have had "objects"
with their own private "methods", and you could have had "threads"
Even though I never got a crash from this, Dave saw this as a bug,
rather than an opportunity, and took it out. I hope Rob will try to see
such things, including our suggestions, as opportunities.
Regards,
Irv
11. Re: My 10c on namespaces
----- Original Message -----
From: Tony Bucholtz <tony_bucholtz at hotmail.com>
> Alan, I'm not sure that voting on improvements would be a good idea.
> >From reading a lot of the old posts re changes to Eu, the vote would
> probably end up with most people voting for their "pet project".
> Besides, why only "licenced" users? I'm pretty sure that some of us
> uncommitted users have some good ideas, too 8-)
Past experience has been that Rob tends to come up with unexpectedly
clever ways to do things, so I wouldn't bother with the voting. The
discussion
however, is very worthwhile. Better to have possible problems brought up
on the list, than have them pop up only after the new version has been
released.
People on the list can look at things with a broader perspective,
considering
such things as usability and interoperability, without getting bogged down
in the details of implementation.
Regards,
Irv
