1. Euphoria Developers Group Discussion
ChrisBurch2 wrote:
> c.k.lester wrote:
> > So, somebody set up a Euphoria Developers forum and those who care about
> > Euphoria development can join.
> Absolutey bang on the nail CK. A developers group should be split off.
I nominate http://www.assembla.com/ to host the developer's group. :)
It is faster than SourceForge and free. I don't know if it's as feature-rich,
but it looks like it has all we need. But you guys can look it up and compare.
I am using Assembla for BBCMF development.
2. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
> > > So, somebody set up a Euphoria Developers forum
> I am using Assembla for BBCMF development.
But the sourceforge site is already established and workable. What would be the
incentive to move to yet another 'forum'.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
3. Re: Euphoria Developers Group Discussion
Derek Parnell wrote:
>
> c.k.lester wrote:
>
> > > > So, somebody set up a Euphoria Developers forum
>
> > I am using Assembla for BBCMF development.
>
> But the sourceforge site is already established and workable. What would be
> the incentive to move to yet another 'forum'.
"Use Assembla spaces for rapid software development, and agile team
collaboration.
Get free workspaces with unlimited team size and integrated tools like wiki,
discussion, alerts, chat, ticketing, Trac, Git and Subversion."
Mike
4. Re: Euphoria Developers Group Discussion
Derek Parnell wrote:
>
> c.k.lester wrote:
>
> > > > So, somebody set up a Euphoria Developers forum
>
> > I am using Assembla for BBCMF development.
>
> But the sourceforge site is already established and workable. What would be
> the incentive to move to yet another 'forum'.
>
I would stick with what we have. However, I'm not sure the "EDG" is the answer
either. We've always had one, sorta. A few of us developers have talked via email
about such a thing and we agree that we do not want the Euphoria community to
feel as though the "Elite" drive the direction and leave the Euphoria community
in the dark.
Sure, anyone can join the list, but do you want to filter through all the nitty
gritty of development questions dealing with implementing things internally like
what does Line 605 do of parser.e just to pick up on one idea of a new feature?
And at that, one feature that is suggested and then subsequently put aside due to
it being a bad idea or whatever?
I suspect that many people would join in with the EDG and initially it would
seem like a good idea, but eventually it will be one or two people max posting on
the list/forum/whatever. And their questions will go like this:
What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's nice..."
day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc...
I don't think that solves anything and from my experience in Open source
development as well as closed source development it's not a matter of if this
will happen, it's a matter of if it is 2, 3 or 6 weeks from now.
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: Euphoria Developers Group Discussion
Derek Parnell wrote:
> c.k.lester wrote:
> > > > So, somebody set up a Euphoria Developers forum
> > I am using Assembla for BBCMF development.
> But the sourceforge site is already established and workable.
"Established" is debatable, in that only a few people use it. I think we
could afford to move now, if we wanted to.
The incentive would be: better interface and faster server.
HOWEVER, I'm not against using SourceForge; in my dreams, we're using
something better, though. :)
6. Re: Euphoria Developers Group Discussion
Jeremy Cowgar wrote:
>
> Derek Parnell wrote:
> >
> > c.k.lester wrote:
> >
> > > > > So, somebody set up a Euphoria Developers forum
> >
> > > I am using Assembla for BBCMF development.
> >
> > But the sourceforge site is already established and workable. What would be
> > the incentive to move to yet another 'forum'.
> >
>
> I would stick with what we have. However, I'm not sure the "EDG" is the answer
> either. We've always had one, sorta. A few of us developers have talked via
> email about such a thing and we agree that we do not want the Euphoria
> community
> to feel as though the "Elite" drive the direction and leave the Euphoria
> community
> in the dark.
>
> Sure, anyone can join the list, but do you want to filter through all the
> nitty
> gritty of development questions dealing with implementing things internally
> like what does Line 605 do of parser.e just to pick up on one idea of a new
> feature? And at that, one feature that is suggested and then subsequently put
> aside due to it being a bad idea or whatever?
>
> I suspect that many people would join in with the EDG and initially it would
> seem like a good idea, but eventually it will be one or two people max posting
> on the list/forum/whatever. And their questions will go like this:
>
> What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's
> nice..."
> day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc...
>
> I don't think that solves anything and from my experience in Open source
> development
> as well as closed source development it's not a matter of if this will happen,
> it's a matter of if it is 2, 3 or 6 weeks from now.
You have hit upon the essential conundrum. If there is enough traffic which is
development related to be distracting (and, in fact, offputting) to those who
have no interest in such things, it is best to bifurcate. If, OTOH, combined
traffic is light it is actually a positive (from the perspective of those just
peeking their head in for a quick look see) to have all traffic on one list. It
implies a certain robustness in the community.
I can certainly tell you that one of my concerns about Euphoria when I first
looked into it was whether the community offered support to newbies or whether it
was hostile to them (as ANY developer's forum will appear, whether or not true).
A relatively active forum (as this was at the time, although it pales in
comparison to how active it has become) provided me with a glimpse of both and,
obviously, satisfied my concerns.
With that said, I am strongly in favor of bifurcation. Certainly the current
level of wheat to chaff for a newbie is offputting. And you want your support
forum to be as welcoming as possible if your goal is to invite Mr. Coder (which I
consider myself to be, BTW).
Keep in mind that any decision to bifurcate needn't be permanent. Heck, it
doesn't even have to be consistent. Things can be discussed on the general forum
until it makes sense to move things to a secondary avenue for detailed further
discussion amongst the interested.
I submit that the time to set up the secondary venue is right now, when
developer traffic is high and is likely to continue that way for at least the
next few weeks. Sort of a beta, if you will. If it won't fly now, it will never
fly.
Whether it keeps flying in the inevitable slow down to come is irrelevant to me.
If it does, great. If it doesn't, that doesn't mean it won't necessarily revive
itself when 5.0 is being actively considered.
$0.02
Mike777
7. Re: Euphoria Developers Group Discussion
Jeremy Cowgar wrote:
> Derek Parnell wrote:
> > c.k.lester wrote:
> > > > > So, somebody set up a Euphoria Developers forum
> > > I am using Assembla for BBCMF development.
> > But the sourceforge site is already established and workable. What would be
> > the incentive to move to yet another 'forum'.
> I would stick with what we have. However, I'm not sure the "EDG" is the answer
> either. We've always had one, sorta. A few of us developers have talked via
> email about such a thing and we agree that we do not want the Euphoria
> community
> to feel as though the "Elite" drive the direction and leave the Euphoria
> community
> in the dark.
I don't view it as the "Elite," but as those who have the time and
inclination to make sure Euphoria is the best it can be.
This idea of the Elite is silly. All Euphorians would have input, anyway.
It's just that development discussion would primarily be by those who
1. have the skillset
2. have the motivation
3. have the desire
> I suspect that many people would join in with the EDG...
I doubt it. You get very little response here on EuForum when asking for
ideas... maybe a core group of 5-10 people (out of how many Euphoria
programmers?).
> seem like a good idea, but eventually it will be one or two people max posting
> on the list/forum/whatever. And their questions will go like this:
>
> What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's
> nice..."
> day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc...
Unlikely doomsday scenario. :)
Current development with EuForum and IRC is rather rapid. I'm just tired of
y'all trying to get the approval of people who don't really care anyway (by
which I mean they don't care how good you make Euphoria, not about Euphoria
itself).
> I don't think that solves anything and from my experience in Open source
> development
> as well as closed source development it's not a matter of if this will happen,
> it's a matter of if it is 2, 3 or 6 weeks from now.
A Euphoria Developers Group can be quick and agile, so that it's more often
2 weeks and not 6 weeks.
8. Re: Euphoria Developers Group Discussion
Mike777 wrote:
>
>
> With that said, I am strongly in favor of bifurcation.
Mike777 +1
9. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> Mike777 wrote:
> >
> >
> > With that said, I am strongly in favor of bifurcation.
>
> Mike777 +1
Mike777 += 1
Certainly new-users should not be overwhelmed by language developer issues.
10. Re: Euphoria Developers Group Discussion
yuku wrote:
>
> Certainly new-users should not be overwhelmed by language developer issues.
And I wonder what sort of impact and draw v4.0 will have, now with its new
standard lib, Linux distributions, etc... Should we expect an influx of new
users?
Regardless, we need a separate developers forum.
11. Re: Euphoria Developers Group Discussion
Heh. I've read the whole thread but I'm just now responding.
I like this list, really. It's a simple and straightforward interface.
However.
A forum is a good idea in order to keep the regular users and user/developers
together in the same place but where each has their own subforum. One problem,
though, is keeping the community all in one place. I think that is why previous
attempts have failed. And I know that's why /I/ stay here instead of dealing with
the wiki and other stuff.
I've registered at the two forums set up for Euphoria, and even posted a couple
of times. But right now I don't even remember the addresses, because all of the
activity occurs right here.
So that's my point -- it would be nice to keep the development stuff separated
from the user/beginning user stuff, but it doesn't work if it's not still all in
one place. IMO.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
12. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> And I wonder what sort of impact and draw v4.0 will have, now with its new
> standard lib, Linux distributions, etc... Should we expect an influx of new
> users?
>
> Regardless, we need a separate developers forum.
Ok, what will we discuss on this developer forum? So far what has been discussed
on EUforum are new ideas. Should the developers on this forum just decide that
enums are a good thing and develop it w/no input from the EU community? Or
optional then/do's?
On EUforum we have not went into source level details. There have been email
conversations amongst developers w/source level details, we have not done any of
that on the forum.
I do not think that communication amongst developers is the problem with
direction for Euphoria. Direction is what we are really talking about. Not
communication amongst developers. A developers mailing list will solve the
problem of someone occasionally hitting Reply instead of Reply-to-all.
We need direction and better organization. Yes, that comes through
communication, but it's only 1 part. Now, you did recommend an organization tool
in the start, which is beneficial, if used, and it should be the focal point of
this discussion. I think we are already on SF, we should use the tools given to
us. SF is at times terribly slow, in fact, I hate using the wiki there, I
literally wait all the time for the pages to come up and it's not me, it's SF.
But, we can deal with that.
Now, back to discussion. The discussion on the forum has been flying, but we are
on the brink of a brand new release. The forum will always increase in activity
during these times. We do not want a new user coming to see Euphoria and look at
the user forum to find the last post was 3 days ago, or that there is 2 posts
today, 3 posts yesterday, the prior day no posts, etc...
--
Jeremy Cowgar
http://jeremy.cowgar.com
13. Re: Euphoria Developers Group Discussion
Jeremy Cowgar wrote:
> c.k.lester wrote:
> > And I wonder what sort of impact and draw v4.0 will have, now with its new
> > standard lib, Linux distributions, etc... Should we expect an influx of new
> > users?
> > Regardless, we need a separate developers forum.
>
> Ok, what will we discuss on this developer forum?
Changes to the core, including standard libs. These are things that
newbs aren't interested in and could be overwhelmed by.
> So far what has been discussed
> on EUforum are new ideas. Should the developers on this forum just decide that
> enums are a good thing and develop it w/no input from the EU community?
That's the funny thing... ONLY developers are getting involved anyway. How
much input are you seeing here? I'm only seeing a few involved. On a whole,
I think the community trusts those who are interested in developing
Euphoria... or they're too busy coding. :)
Changes to the interpreter do not require community input except when those
changes will introduce breaks with old code or will in some way harm the
current performance of Euphoria. Otherwise, it's just another feature they
can decide to use or not use.
What developers should do is discuss among themselves implementation details,
then present a vote to the community... MAYBE. As above, most changes can
be done without consulting the general population... and I don't think they'll
care! It's just another feature they can decide to use or not use.
> We do not want a new user coming to see Euphoria and look
> at the user forum to find the last post was 3 days ago, or that there is 2
> posts
> today, 3 posts yesterday, the prior day no posts, etc...
Why not? Stability and a smart userbase is a good thing. ;)
14. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> What developers should do is discuss among themselves implementation details,
> then present a vote to the community... MAYBE. As above, most changes can
> be done without consulting the general population... and I don't think they'll
> care! It's just another feature they can decide to use or not use.
Is this what users want?
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: Euphoria Developers Group Discussion
Jeremy Cowgar wrote:
>
> c.k.lester wrote:
> >
> > And I wonder what sort of impact and draw v4.0 will have, now with its new
> > standard lib, Linux distributions, etc... Should we expect an influx of new
> > users?
> >
> > Regardless, we need a separate developers forum.
>
> Ok, what will we discuss on this developer forum? So far what has been
> discussed
> on EUforum are new ideas. Should the developers on this forum just decide that
> enums are a good thing and develop it w/no input from the EU community? Or
> optional
> then/do's?
As primarily a user, I think the answers are basically:
Whatever makes sense for developers to discuss amongst themselves. You have
indicated below that there are some conversations which are held via email. In
an open source world, that is quite an indictment. If the reason is that it
seemed to be too detailed for discussion on the Forum you have made one of the
strongest arguments to making a better venue available.
Yes, enums should be in the hands of the developers until it is decided that it
is a good idea and that it can be implemented. At that point, as with any
implementation, some excited fool (probably me) will no doubt find him or herself
letting the cat out of the bag on the Forum. That is a very good thing. At that
point, the users can weigh in, as their input at that point is just what is
needed.
Optional then/do's wouldn't have seen the light of day on the Forum. Another
good thing.
> On EUforum we have not went into source level details.
This is subjective. When I see multiple implementations of a construct in a
single post, I see the same thing. Little arrow diagrams. MIGO.
> There have been email
> conversations amongst developers w/source level details, we have not done any
> of that on the forum.
See above. Egads.
> Now, back to discussion. The discussion on the forum has been flying, but we
> are on the brink of a brand new release. The forum will always increase in
> activity
> during these times. We do not want a new user coming to see Euphoria and look
> at the user forum to find the last post was 3 days ago, or that there is 2
> posts
> today, 3 posts yesterday, the prior day no posts, etc...
If you can conjecture that the developer traffic will decline at some point in
the future, I can conjecture that a new version with additional features will
increase the language's reach and therefore increase the user forum traffic. I'd
rather plan for future expansion and be disappointed than not do so and suffer
the consequences of a damaged reputation brought about by being described as
"unweildly".
Mike
16. Re: Euphoria Developers Group Discussion
> On 15 May 2008 at 11:21, Jeremy Cowgar wrote (maybe snipped):
> c.k.lester wrote:
> >
> > What developers should do is discuss among themselves implementation
> > details, then present a vote to the community... MAYBE. As above,
> > most changes can be done without consulting the general
> > population... and I don't think they'll care! It's just another
> > feature they can decide to use or not use.
>
> Is this what users want?
>
I hope not. The main target of any product is its user base. May I
suggest this willing group of developers get some "moderation", just
to keep the train on rails, and avoid that "MAYBEs" fell from where
they stand? Please?
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
17. Re: Euphoria Developers Group Discussion
Euler German wrote:
>
> > On 15 May 2008 at 11:21, Jeremy Cowgar wrote (maybe snipped):
>
> > c.k.lester wrote:
> > >
> > > What developers should do is discuss among themselves implementation
> > > details, then present a vote to the community... MAYBE. As above,
> > > most changes can be done without consulting the general
> > > population... and I don't think they'll care! It's just another
> > > feature they can decide to use or not use.
> >
> > Is this what users want?
> >
>
> I hope not. The main target of any product is its user base. May I
> suggest this willing group of developers get some "moderation", just
> to keep the train on rails, and avoid that "MAYBEs" fell from where
> they stand? Please?
Why do you conclude that developer actions will be completely independent of
user input?
Mike
18. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> Changes to the interpreter do not require community input except when those
> changes will introduce breaks with old code or will in some way harm the
> current performance of Euphoria. Otherwise, it's just another feature they
> can decide to use or not use.
>
> What developers should do is discuss among themselves implementation details,
> then present a vote to the community... MAYBE. As above, most changes can
> be done without consulting the general population... and I don't think they'll
> care! It's just another feature they can decide to use or not use.
I think part of the reason we look for validation from the community is that
the development model is so open. No one is really in charge at this point.
In theory, Rob's opinion would likely weigh more heavily than others, but
he's certainly not a dictator (benevolent or otherwise) at this point.
When a change is proposed that will have large effects upon the way we code
in euphoria, I'm nervous about imposing my views on others without getting
feedback first. I think one thing that most of us want to preserve (even
while improving the language) is to preserve what we like about euphoria.
Of course, this is different for each person. Adding a function here or
there is relatively trivial in impact compared to modifying the include
system, or changing other syntax.
Matt
19. Re: Euphoria Developers Group Discussion
Matt Lewis wrote:
>
> c.k.lester wrote:
> >
> > Changes to the interpreter do not require community input except when those
> > changes will introduce breaks with old code or will in some way harm the
> > current performance of Euphoria. Otherwise, it's just another feature they
> > can decide to use or not use.
> >
> > What developers should do is discuss among themselves implementation
> > details,
> > then present a vote to the community... MAYBE. As above, most changes can
> > be done without consulting the general population... and I don't think
> > they'll
> > care! It's just another feature they can decide to use or not use.
>
> I think part of the reason we look for validation from the community is that
> the development model is so open. No one is really in charge at this point.
> In theory, Rob's opinion would likely weigh more heavily than others, but
> he's certainly not a dictator (benevolent or otherwise) at this point.
>
> When a change is proposed that will have large effects upon the way we code
>
> in euphoria, I'm nervous about imposing my views on others without getting
> feedback first. I think one thing that most of us want to preserve (even
> while improving the language) is to preserve what we like about euphoria.
> Of course, this is different for each person. Adding a function here or
> there is relatively trivial in impact compared to modifying the include
> system, or changing other syntax.
I don't see the bifurcated system as a prescription for avoiding user input on
any specific decision. The fact that you feel this way is a very, very good
thing and will work to ensure that even if there is 100% consensus amongst the
developers somebody will no doubt suggest that it should at least be mentioned on
the Forum. Good.
Mike
20. Re: Euphoria Developers Group Discussion
Matt Lewis wrote:
> c.k.lester wrote:
> > Changes to the interpreter do not require community input except when those
> > changes will introduce breaks with old code or will in some way harm the
> > current performance of Euphoria. Otherwise, it's just another feature they
> > can decide to use or not use.
> >
> > What developers should do is discuss among themselves implementation
> > details,
> > then present a vote to the community... MAYBE. As above, most changes can
> > be done without consulting the general population... and I don't think
> > they'll
> > care! It's just another feature they can decide to use or not use.
>
> I think part of the reason we look for validation from the community is that
> the development model is so open.
And my argument is that "the community" isn't very vocal, ever. You have a
core base of developers who do want to voice their input, but I would say
95% of Euphoria users are happy with the direction Euphoria is going.
Otherwise, we'd hear about it.
The other possibility is that we're the only ones using Euphoria, and that's
why there's so little input. :)
> When a change is proposed that will have large effects upon the way we code
> in euphoria, I'm nervous about imposing my views on others without getting
> feedback first.
I somewhat agree, but not really. Generally, the changes the developers
agree on will be double-plus-good for Euphoria. Now, on code breakage, I
did say a population query would probably be good. But for changes like
enum, it doesn't break code and it makes Euphoria coding easier. PLUS, you
don't even have to use it. Stick with the old way if you want. The point
being, no negatives and only positives means we don't need to consult the
other 95% of the people who won't care anyway.
21. Re: Euphoria Developers Group Discussion
- Posted by CChris <christian.cuvier at agricul?u?e.gouv.fr>
May 15, 2008
-
Last edited May 16, 2008
c.k.lester wrote:
>
> Matt Lewis wrote:
> > c.k.lester wrote:
> > > Changes to the interpreter do not require community input except when
> > > those
> > > changes will introduce breaks with old code or will in some way harm the
> > > current performance of Euphoria. Otherwise, it's just another feature they
> > > can decide to use or not use.
> > >
> > > What developers should do is discuss among themselves implementation
> > > details,
> > > then present a vote to the community... MAYBE. As above, most changes can
> > > be done without consulting the general population... and I don't think
> > > they'll
> > > care! It's just another feature they can decide to use or not use.
> >
> > I think part of the reason we look for validation from the community is that
> > the development model is so open.
>
> And my argument is that "the community" isn't very vocal, ever. You have a
> core base of developers who do want to voice their input, but I would say
> 95% of Euphoria users are happy with the direction Euphoria is going.
> Otherwise, we'd hear about it.
>
You know, we are such a small group of vocal people here. There will always be
disagreement for the sake of disagreeing. Just have some random reading of this
list for the past 18 months, and see how productive it had got. Keep pushing
hard, Jeremy.
> The other possibility is that we're the only ones using Euphoria, and that's
> why there's so little input. :)
>
I have exactly zero idea of how we forum posters are representative of the user
base at large. I don't want to look pessimistic, but I wouldn't be surprised of
you were almost right.
> > When a change is proposed that will have large effects upon the way we code
> > in euphoria, I'm nervous about imposing my views on others without getting
> > feedback first.
>
> I somewhat agree, but not really. Generally, the changes the developers
> agree on will be double-plus-good for Euphoria. Now, on code breakage, I
> did say a population query would probably be good. But for changes like
> enum, it doesn't break code and it makes Euphoria coding easier. PLUS, you
> don't even have to use it. Stick with the old way if you want. The point
> being, no negatives and only positives means we don't need to consult the
> other 95% of the people who won't care anyway.
Did you notice how many improvements that would have broken zero code, because
they were giving meaning to something currently illegal, were brought down
because "name is not right", "one keyword more is too much" and such? A lot.
CChris
22. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at gm?i?.com>
May 15, 2008
-
Last edited May 16, 2008
Mike777 wrote:
>
> I don't see the bifurcated system as a prescription for avoiding user input
> on any specific decision. The fact that you feel this way is a very, very
> good thing and will work to ensure that even if there is 100% consensus
> amongst the developers somebody will no doubt suggest that it should at
> least be mentioned on the Forum. Good.
Personally, I like the idea of having a developers forum or mailing list, but
I'd probably only use it for talking about implementation details that most
people wouldn't want to hear. Just like I tend to take conversations about
other projects off-line.
For example, I don't think that most people are interested in the finer
points of crafting a Watcom makefile. Or even hacking on the front end,
which is all euphoria.
Matt
23. Re: Euphoria Developers Group Discussion
- Posted by Jeremy Cowgar <jeremy at cowgar.c??>
May 15, 2008
-
Last edited May 16, 2008
Matt Lewis wrote:
>
> Mike777 wrote:
> >
> > I don't see the bifurcated system as a prescription for avoiding user input
> > on any specific decision. The fact that you feel this way is a very, very
> > good thing and will work to ensure that even if there is 100% consensus
> > amongst the developers somebody will no doubt suggest that it should at
> > least be mentioned on the Forum. Good.
>
> Personally, I like the idea of having a developers forum or mailing list, but
> I'd probably only use it for talking about implementation details that most
> people wouldn't want to hear. Just like I tend to take conversations about
> other projects off-line.
>
> For example, I don't think that most people are interested in the finer
> points of crafting a Watcom makefile. Or even hacking on the front end,
> which is all euphoria.
>
> Matt
Agreed. Matt, should I set one up on SF for that use? Anyone who wants to listen
to use to chat about the horrors of making a Watcom makefile work on DOS, Win98
and XP/Vista are free to join.
I also think it would be OK for us to discuss *possible* improvements on the
developer list. For example, I may suggest "Hey, let's get rid of the include
statement and just make everyone write it all in a big file. That would be faster
for the parser." ... Immediately I'd be shot down on the developer list. No need
to panic the userbase about that! 
But if we propose a function, syntax,
etc... and the majority of the developers think its a good idea, we can solicit
EUforum for input.
--
Jeremy Cowgar
http://jeremy.cowgar.com
24. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ckles?er.c?m>
May 15, 2008
-
Last edited May 16, 2008
CChris wrote:
> Did you notice how many improvements that would have broken zero code, because
> they were giving meaning to something currently illegal, were brought down
> because
> "name is not right", "one keyword more is too much" and such? A lot.
Such is the dynamics of design by committee. :)
25. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.com>
May 15, 2008
-
Last edited May 16, 2008
CChris wrote:
>
> You know, we are such a small group of vocal people here. There will always
> be disagreement for the sake of disagreeing.
No there won't!
Matt
26. Re: Euphoria Developers Group Discussion
- Posted by Derek Parnell <ddparnell at b?gpo?d.com>
May 15, 2008
-
Last edited May 16, 2008
c.k.lester wrote:
>
> CChris wrote:
>
> > Did you notice how many improvements that would have broken zero code,
> > because
> > they were giving meaning to something currently illegal, were brought down
> > because
> > "name is not right", "one keyword more is too much" and such? A lot.
>
> Such is the dynamics of design by committee. :)
Before we accept this assertion, can we have some examples of what you are
talking about Chris?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
27. Re: Euphoria Developers Group Discussion
- Posted by ChrisBurch3 <crylex at ?m?il.com>
May 15, 2008
-
Last edited May 16, 2008
Matt Lewis wrote:
>
> CChris wrote:
> >
> > You know, we are such a small group of vocal people here. There will always
> > be disagreement for the sake of disagreeing.
>
> No there won't!
>
> Matt
Tweaked the syntax
Yes there
Chris
28. Re: Euphoria Developers Group Discussion
Derek Parnell wrote:
>
> c.k.lester wrote:
> >
> > CChris wrote:
> >
> > > Did you notice how many improvements that would have broken zero code,
> > > because
> > > they were giving meaning to something currently illegal, were brought down
> > > because
> > > "name is not right", "one keyword more is too much" and such? A lot.
> >
> > Such is the dynamics of design by committee. :)
>
> Before we accept this assertion, can we have some examples of what you are
> talking
> about Chris?
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
- Structure field declarations
- continue, select ... case
- min, max and friends
- [] desequence operator
- sequence of <type>
an many more, didn't keep a complete tally, being tired of the repeating
pattern.
CChris
29. Re: Euphoria Developers Group Discussion
CChris wrote:
>
> Derek Parnell wrote:
> >
> > c.k.lester wrote:
> > >
> > > CChris wrote:
> > >
> > > > Did you notice how many improvements that would have broken zero code,
> > > > because they were giving meaning to something currently illegal, were
> > > > brought down because
> > > > "name is not right", "one keyword more is too much" and such? A lot.
> > >
> > > Such is the dynamics of design by committee. :)
> >
> > Before we accept this assertion, can we have some examples of what you are
> > talking
> > about Chris?
>
> - Structure field declarations
This one certainly isn't about "name." There are some serious differences of
opinion about how detailed this should be.
> - continue, select ... case
Could you point out where the name/keyword issue has stopped this? I
thought everyone was in agreement about the implementation. Continue
is already in there. We could still change the name easily enough. I
also thought that we've basically agreed about the need for case, but
not the details yet. Either way, your argument doesn't fit.
> - min, max and friends
There were debates about what sort of arguments, etc, this should take.
> - [] desequence operator
I don't recall arguments about this one...
> - sequence of <type>
There are serious performance issues here that I don't think were ever
addressed. Plus serious disagreements about how it should behave.
> an many more, didn't keep a complete tally, being tired of the repeating
> pattern.
Sorry, but unless you can find some real examples, I'm calling BS. C'mon,
there were substantial disagreements about how most of these things should
be implemented. It's too bad that we can't all agree, but that's life.
Matt
30. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> Mike777 wrote:
> >
> >
> > With that said, I am strongly in favor of bifurcation.
I don't agree with a separate developer forum in the form that seems to be
developing.
I think users of the language do need to be involved with the discussion of its
features, development, and direction.
I have looked through the source code for Euphoria but do not have the detailed
understanding of how it all works.
So I think Jeremy had it right when he said the developer's list (if needed) is
more for "What does this block of code do?, How does this stuff work?" etc.
But it is a conundrum I agree. Before running off and possibly ruining the
momentum that this list has gathered I would like to propose a suggestion for the
EUForum itself.
What if each thread could be 'tagged' with a section? For example this thread is
tagged "Development Organisation" or whatever, a thread on how to make a button
change its text is tagged "Win32lib"
A thread about the roadmap could be tagged 'Development' etc. etc.
When new message is created, you tick the section(s) that apply. Or when
replying to a message you change the tick boxes around if it's going off topic.
In your preferences for the list you tick the sections you want to see
(defaulting to all)
When you see the list, you only see what you're interested in, and perhaps a
message like "142 messages filtered".
Old messages continue to expire to the archive, but perhaps maintain their
section tag to enhance their searchability.
What this means is that if you are not interested in seeing any developer stuff,
or wxEuphoria examples, or off-topic quips they will be efficiently filtered.
I'm not sure how this would affect RSS readers.
This of course requires Rob's buy-in or whoever is maintaining the EUForum
itself, and of course everyone's buy-in to tick the boxes.
Gary
31. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> Changes to the core, including standard libs. These are things that
> newbs aren't interested in and could be overwhelmed by.
What 'newbs'? I don't think I've seen more than about 10 new users posting in
EUForum in the last three years? (I could be wrong?)
Half the time a new name turns out to be an old-hand with a new email address,
or just someone who has search out a better way and found Euphoria, ie someone
interested in programming principles.
Without detailed access logs to the forum, or a proper user survey, I don't
think anyone is in a position to say how effective or ineffective 'this way' is.
> Changes to the interpreter do not require community input except when those
> changes will introduce breaks with old code or will in some way harm the
> current performance of Euphoria. Otherwise, it's just another feature they
> can decide to use or not use.
I don't agree. Sure they can decide whether to use it or not, but if it has been
implemented in an 'unusable' (or limited/inefficient) way, that decision will
have already been made for them.
> What developers should do is discuss among themselves implementation details,
> then present a vote to the community...
That seems a bit too ... democratic to me... in the negative sense of the word.
The community needs to drive the development not make multiple choices about it;
given the good graces of the developers who will actually get their hands dirty
doing it, of course :)
Gary
32. Re: Euphoria Developers Group Discussion
c.k.lester wrote:
>
> ChrisBurch2 wrote:
> > c.k.lester wrote:
> > > So, somebody set up a Euphoria Developers forum and those who care about
> > > Euphoria development can join.
> > Absolutey bang on the nail CK. A developers group should be split off.
>
> I nominate <a href="http://www.assembla.com/">http://www.assembla.com/</a> to
> host the developer's group. :)
>
> It is faster than SourceForge and free. I don't know if it's as feature-rich,
> but it looks like it has all we need. But you guys can look it up and compare.
> I am using Assembla for BBCMF development.
Or, just split THIS list into two lists, Support & Development,
with either (or both combined) selectable at Euphoria Home.
or, as a re-design IDEA,
http://audacityteam.org/forum/index.php
Dan
33. Re: Euphoria Developers Group Discussion
gshingles wrote:
> c.k.lester wrote:
> > Changes to the interpreter do not require community input except when those
> > changes will introduce breaks with old code or will in some way harm the
> > current performance of Euphoria. Otherwise, it's just another feature they
> > can decide to use or not use.
> I don't agree. Sure they can decide whether to use it or not, but if it has
> been implemented in an 'unusable' (or limited/inefficient) way, that decision
> will have already been made for them.
That's why I said "those changes that will introduce breaks with old code
or will in some way harm the current performance..."
It won't be implemented in an unusable/limited/inefficient way.
> The community needs to drive the development...
This has been tried and it fails. When asked for input, only a few people
ever respond, if any. I'm saying gather those interested parties together
and leave everybody else alone.
I use PHP. I don't care about its development so I'm not part of that
developers group. I'm sure there are many Euphoria users who feel the
same about Euphoria.
But I use Euphoria and I care what happens to it, so I would want to
give my input and help guide its development.
