1. Feature management
My 2c:
Before deciding on a feature/enhancement, how about getting a list of
determining factors with associated weightings and a feature freeze date.
No enhancements after the freeze, until the accepted features are in and
beta tested.
The idea is to be discourage emotions from clouding opinions.
Not that there has been much, this list is very well behaved IMHO
Eg for feature X:
a) Speed. Plus 20 points if this causes a speedup, minus 5 per percent slowdown.
b) Size. Minus 5 point per K added to the eu interpreter exe.
Minus 1 point per K added to the standard includes
c) Documentation. Plus 20 with docs, minus 50 without.
d) Obscurity. (Hard to judge this one....)
e) Backwards compatibility. Minus 60 without, plus 20 with.
f) Coding ease. Plus 20 if it makes shorter code, minus 10 if code is larger.
g) Difficulty to do. Minus 10 per week estimated time to code, and debug ;)
h) Importance. Suggest Rob be the judge here.
You get the idea. My scores are just an example.
So if feature X scores more than feature Y, do X first. Minimum score
to implement any feature should be 100.
Of course, this won't stop anybody thats keen on a feature from sending
their code in anyway but should be considered for official blessing.
Am I smoking my socks, or would this be a good idea?
2. Re: Feature management
Alan Oxley wrote:
[snip]
> You get the idea. My scores are just an example.
> So if feature X scores more than feature Y, do X first. Minimum score
> to implement any feature should be 100.
> Of course, this won't stop anybody thats keen on a feature from sending
> their code in anyway but should be considered for official blessing.
>
> Am I smoking my socks, or would this be a good idea?
You're smoking more than just your socks, dude! ;)) just kidding...
I agree....some form of prioritizing should be used. However, IMHO, I think
that at this stage of the game we, as a community should agree as to what
*purpose*
Should Euphoria be morphed and optimized for:
1. x-platform games programming
2. x-platform web-development and backend
3. other x-platform GUI apps
4. x-platform embedded systems
5. x-platform general programming/scripting (like Perl maybe)
6. whatever.....
Once we have a plan for Euphoria, then it will be a bit easier to define the
language requirements.
The context in which this morphing/optimizing will occur (i.e. OOP or no)
will have to be decided next. Some languages have an OOP extension - a super
library - that you include/require in order to do your OOP thing. Maybe that
could be the way to go.
But we need a plan. IF we want IT managers to show some interest in Euphoria,
then Euphoria must provide something *other* than speed. To date, the
programming community at large are not breaking the door down wanting to get
a copy of Euphoria. But maybe the Euphoria Community doesn't want that. Maybe
all that's needed by this community is the status quo! If that's the case, then
the more adventuresome folks in this community will have to do what the
folks in the Icon language community did -- they picked up there toys and left
to fork an off-shoot language called Unicon. I'm told that now, both communities
play nice together, and life's good. Might need to happen here!
--
duke
http://www.rootshell.be/~perlster/euphoria/
3. Re: Feature management
Hi Duke,
Yes, prioritizing is good - but deciding on what gets priority is an issue.
Its possible that a single vocal person's feature proposal will cause
a lot of noise on this list and hence get priority over another proposal
that has wider appeal. Also the sheer bandwidth expended on one person's
pet proposal can be significant in discouraging newbies.
With an agreed set of criteria, priority becomes transparent.
I betcha that Rob has a criteria list - even if its undocumented
and only in his mind. I'd like to see that list! We have had hints
though, and the rare emphatic "NO" from him too, eg "goto" and
certain forward variable referencing.
I dunno that Euphoria needs to be optimized for a particular purpose if
that detracts from its original purpose of being a general purpose
language. By all means add extras but be exceptionally wary of breaking
backwards compatibility. The super library you mentioned would be OK.
IMHO we have an opportunity to take a step back and say how we want
to take Euphoria forwards before we concentrate on specific features.
Kinda like writing code itself; its best to think about the goal and
strive for that - don't be tempted to add features as you are going along.
Regards
Alan
4. Re: Feature management
- Posted by Ray Smith <ray at RaymondSmith.com>
Jan 09, 2007
-
Last edited Jan 10, 2007
Hi Duke,
duke normandin wrote:
> I agree....some form of prioritizing should be used. However, IMHO, I think
> that at this stage of the game we, as a community should agree as to what
> *purpose*
Open Source development doesn't really work this way.
What usually happens is that someone proposes a change, it's discussed for
awhile, if most people agree the person who suggests it implements it.
You can't tell someone what to do unless you pay them ;)
Even a very insignificant change will get done before a very important one if
someone is willing to do it.
> Should Euphoria be morphed and optimized for:
> 1. x-platform games programming
> 2. x-platform web-development and backend
> 3. other x-platform GUI apps
> 4. x-platform embedded systems
> 5. x-platform general programming/scripting (like Perl maybe)
> 6. whatever.....
In *most* cases specific functionality for particular *types* of software is
provided by libraries.
It's best to listen to the library creators to help them develop libraries
that everyone else will use.
The *standard library* for instance will help!!!
(Note: Some things like threads and exception handling can only really be
provided
by the base language)
Regards,
Ray Smith
http://RaymondSmith.com
5. Re: Feature management
Ray Smith wrote:
>
> Hi Duke,
>
> duke normandin wrote:
> > I agree....some form of prioritizing should be used. However, IMHO, I think
> > that at this stage of the game we, as a community should agree as to what
> > *purpose*
>
> Open Source development doesn't really work this way.
> What usually happens is that someone proposes a change, it's discussed for
> awhile, if most people agree the person who suggests it implements it.
> You can't tell someone what to do unless you pay them ;)
> Even a very insignificant change will get done before a very important one >
> if someone is willing to do it.
I disagree! FreeBSD is a good example! Lots of discussion went on about which
direction FBSD should go. Lots of disagreement ensued. That gave birth to PCBSD
and DragonflyBSD. Same thing happened with the Icon programming language. Some
wanted OOP lots didn't. The OOP people took the Icon code and made Unicon.
And nobody's telling *anybody* what to do here. Where did *that* come from?
> > Should Euphoria be morphed and optimized for:
> > 1. x-platform games programming
> > 2. x-platform web-development and backend
> > 3. other x-platform GUI apps
> > 4. x-platform embedded systems
> > 5. x-platform general programming/scripting (like Perl maybe)
> > 6. whatever.....
>
> In *most* cases specific functionality for particular *types* of software
> is provided by libraries.
I agree! Library provide tools but it doesn't optimize a language for string
handling e.g. - if web development was the language's prime purpose. You'll never
make PHP into Tcl/Tk. Ramus didn't write PHP to do that.
> It's best to listen to the library creators to help them develop libraries
> that everyone else will use.
I think it is best that the library creators listen to the language's community
if their goal is to provide libraries for the community. That being said, they
can write all the tools they want for their own use and make them available to
all if they so desire.
> The *standard library* for instance will help!!!
You bet!
--
duke
http://www.rootshell.be/~perlster/euphoria/
6. Re: Feature management
- Posted by Ray Smith <ray at RaymondSmith.com>
Jan 09, 2007
-
Last edited Jan 10, 2007
Hi Duke,
duke normandin wrote:
> And nobody's telling *anybody* what to do here. Where did *that* come from?
... because you can have all the direction and priorities you want ... but
someone has to sit down and actually do the work ... it's best to let people
propose what "they" want to ... and after discussion and if most agree let
them do it.
Regards,
Ray Smith
http://RaymondSmith.com
7. Re: Feature management
- Posted by Chris Bensler <bensler at nt.net>
Jan 09, 2007
-
Last edited Jan 10, 2007
duke normandin wrote:
>
> Ray Smith wrote:
> >
> > Hi Duke,
> >
> > duke normandin wrote:
> > > I agree....some form of prioritizing should be used. However, IMHO, I
> > > think
> > > that at this stage of the game we, as a community should agree as to what
> > > *purpose*
> >
> > Open Source development doesn't really work this way.
> > What usually happens is that someone proposes a change, it's discussed for
> > awhile, if most people agree the person who suggests it implements it.
> > You can't tell someone what to do unless you pay them ;)
> > Even a very insignificant change will get done before a very important one
> > if someone is willing to do it.
>
> I disagree! FreeBSD is a good example! Lots of discussion went on about which
> direction FBSD should go. Lots of disagreement ensued. That gave birth to
> PCBSD
> and DragonflyBSD. Same thing happened with the Icon programming language. Some
> wanted OOP lots didn't. The OOP people took the Icon code and made Unicon.
>
> And nobody's telling *anybody* what to do here. Where did *that* come from?
I agree with Duke here.
People can discuss and implement whatever they want to, but the project is not
obligated to adopt it.
In general yes, most opensource projects are pretty ad-hoc and lack proper
project management. Well managed projects though have plans. Goals, milestones,
criteria, etc.
> > > Should Euphoria be morphed and optimized for:
> > > 1. x-platform games programming
> > > 2. x-platform web-development and backend
> > > 3. other x-platform GUI apps
> > > 4. x-platform embedded systems
> > > 5. x-platform general programming/scripting (like Perl maybe)
> > > 6. whatever.....
> >
> > In *most* cases specific functionality for particular *types* of software
> > is provided by libraries.
>
> I agree! Library provide tools but it doesn't optimize a language for string
> handling e.g. - if web development was the language's prime purpose. You'll
> never make PHP into Tcl/Tk. Ramus didn't write PHP to do that.
>
> > It's best to listen to the library creators to help them develop libraries
> > that everyone else will use.
>
> I think it is best that the library creators listen to the language's
> community
> if their goal is to provide libraries for the community. That being said, they
> can write all the tools they want for their own use and make them available
> to all if they so desire.
I think you are both right on this point. The creators and the community need to
cooperate with each other.
I have developed a set of standard libraries for example. But I made them mostly
for my needs and as a prototype for proof of concept, so they are quite biased.
While they are standard functionality to me, it may not be to others. And I can't
cater to areas of programming that I don't frequently use without knowing what
others need and want. On the other hand, I can't provide what others need unless
they contribute ideas and opinions and possibly assist with areas where I lack
experience.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
8. Re: Feature management
Ray Smith wrote:
>
> Hi Duke,
>
>
> duke normandin wrote:
>
> > And nobody's telling *anybody* what to do here. Where did *that* come from?
>
> ... because you can have all the direction and priorities you want ... but
> someone has to sit down and actually do the work ... it's best to let people
> propose what "they" want to ... and after discussion and if most agree let
> them do it.
Are you suggesting that the core developers of Euphoria should be involved in
this discussion? Am I in the wrong forum here? Is this a Euphoria users forum, or
a Euphoria Developers' forum? I think that we all have a stake in the
development, advocacy and maintenance of Euphoria. It's the same way with *any*
language. If the core development team is bent "on doing it there way, or the
highway" , then they'll eventually be playing with their toy by themselves. And
that may work for them! But if you want a language to grow in efficiency,
effectiveness and stature, then we need a plan and we have to *listen* to each
other.
And isn't that what we're doing now. Each of us is popping off with what we
believe to be the way to go? At the end of the day though, there will have to be
a concensus as to:
1. where the language is going
2. the best way to get there
3. who will do what
Take a look at the Perl and PHP communities. It took years of community
involvement to go from Perl4 to Perl5. They are currently working on Perl6.
Although not every Perl hacker is a C programmer (and therefore wont be hacking
any C code) some are truly Perl gurus and are encouraged to make all the
recommendations they want. That applies to the entire Perl community. I hope that
this community is of a like mind!
--
duke
http://www.rootshell.be/~perlster/euphoria/
9. Re: Feature management
Chris Bensler wrote:
>
> duke normandin wrote:
> >
> > Ray Smith wrote:
> > >
> > > Hi Duke,
> > >
> > > duke normandin wrote:
> > > > I agree....some form of prioritizing should be used. However, IMHO, I
> > > > think
> > > > that at this stage of the game we, as a community should agree as to
> > > > what
> > > > *purpose*
> > >
> > > Open Source development doesn't really work this way.
> > > What usually happens is that someone proposes a change, it's discussed for
> > > awhile, if most people agree the person who suggests it implements it.
> > > You can't tell someone what to do unless you pay them ;)
> > > Even a very insignificant change will get done before a very important one
> > > if someone is willing to do it.
> >
> > I disagree! FreeBSD is a good example! Lots of discussion went on about
> > which
> > direction FBSD should go. Lots of disagreement ensued. That gave birth to
> > PCBSD
> > and DragonflyBSD. Same thing happened with the Icon programming language.
> > Some
> > wanted OOP lots didn't. The OOP people took the Icon code and made Unicon.
> >
> > And nobody's telling *anybody* what to do here. Where did *that* come from?
>
> I agree with Duke here.
> People can discuss and implement whatever they want to, but the project is not
> obligated to adopt it.
>
> In general yes, most opensource projects are pretty ad-hoc and lack proper
> project
> management. Well managed projects though have plans. Goals, milestones,
> criteria,
> etc.
>
>
> > > > Should Euphoria be morphed and optimized for:
> > > > 1. x-platform games programming
> > > > 2. x-platform web-development and backend
> > > > 3. other x-platform GUI apps
> > > > 4. x-platform embedded systems
> > > > 5. x-platform general programming/scripting (like Perl maybe)
> > > > 6. whatever.....
> > >
> > > In *most* cases specific functionality for particular *types* of software
> > > is provided by libraries.
> >
> > I agree! Library provide tools but it doesn't optimize a language for string
> > handling e.g. - if web development was the language's prime purpose. You'll
> > never make PHP into Tcl/Tk. Ramus didn't write PHP to do that.
> >
> > > It's best to listen to the library creators to help them develop libraries
> > > that everyone else will use.
> >
> > I think it is best that the library creators listen to the language's
> > community
> > if their goal is to provide libraries for the community. That being said,
> > they
> > can write all the tools they want for their own use and make them available
> > to all if they so desire.
>
> I think you are both right on this point. The creators and the community need
> to cooperate with each other.
>
> I have developed a set of standard libraries for example. But I made them
> mostly
> for my needs and as a prototype for proof of concept, so they are quite
> biased.
> While they are standard functionality to me, it may not be to others. And I
> can't cater to areas of programming that I don't frequently use without
> knowing
> what others need and want. On the other hand, I can't provide what others need
> unless they contribute ideas and opinions and possibly assist with areas where
> I lack experience.
That's exactly what I've been trying to suggest in my post, that the enhancement
of a language, OS, and even libraries cannot happen in a vacuum - unless the
community in so small that it doesn't matter. Without wanting to offend anybody
here, take Perl and the CPAN project. The latter has thousands of modules and
packages (i.e. libraries) written by whoever wants to. Some of these modules are
bundled with every Perl5xxxxxx distribution as a "Standard Library" -- i.e they
provide core functionality. So CGI.pm would not be included, but with the CPAN
process, in seconds it's DLed and installed. Hell there is even a library to
interface Tk with Perl. Talk about hoop to jump through to get GUIs to happen in
Perl.
That leads me to my next point -- Perl was *never* created to do GUI. Its
strength lies in string and file manipulations etc. That's why it found a
beautiful niche in Web Development etc. As well, it can never compete with
Fortran in math applications -- it has not been created and optimized for that.
So... IMO, we need to identify what we want Euphoria to excel at besides its
speed? If its going to be a lightweight teaching language, how can we do this to
attract all of academia to Euphoria? If its web development, what do we offer to
attract the IT managers here? etc etc. We then optimize the language for the end
goal, and create kick-ass libraries to that end.
--
duke
http://www.rootshell.be/~perlster/euphoria/
10. Re: Feature management
duke normandin wrote:
>
> Are you suggesting that the core developers of Euphoria should be involved in
> this discussion? Am I in the wrong forum here? Is this a Euphoria users forum,
> or a Euphoria Developers' forum? I think that we all have a stake in the
> development,
> advocacy and maintenance of Euphoria. It's the same way with *any* language.
> If the core development team is bent "on doing it there way, or the highway"
> , then they'll eventually be playing with their toy by themselves. And that
> may work for them! But if you want a language to grow in efficiency,
> effectiveness
> and stature, then we need a plan and we have to *listen* to each other.
Obviously this list is for developers and users.
You should note though that (I think) all popular open source languages have
separate "user" lists and "developer" lists.
Anyone is able to read both and post messages if they wish.
But ... it's not a bad idea to split the list into a user and developer list.
My point being - most users will get more value out of what easily available
libraries that are available vs the features supplied by the base language.
In general base developers and library users should have more say in the
direction
(I'll note I'm not a base developer and only "just" ;) a library developer).
Keeping these people happy "will" eventually provide a better development
platform for everyone.
Secondly, if you can't convince someone to actually implement the community
voted top 3 items in the priority list they will never get done.
I'm more for an organically developed and grown Euphoria then saying ...
"Here is the grand plan we are attempting to achieve".
I do point I made a post when Euphoria was first open sourced saying we should
have a "mission statement" or "general design principles" that all enhancements
should be subject to. You could almost call it "The Spirit of Euphoria"!
Regards,
Ray Smith
http://RaymondSmith.com
