1. Feature creep
Hi
There are so many changes going on at once, without solid feature
testing (no disrespect Jeremy, but unit tests will only give you back what
you want, and not always how they would react in real life (for this read
all over the place coders like me))
Assume I am Mr Bog Standard Joe Coder. I don't care about all the internal
shenannigans, I just want a robust, fast reasonably feature rich language,
that could evolve at a reasonable pace, without breaking vast tracts of previous
code and be well supported by all the authors.
Where's the release for general programmers? Mr Coder wants a precompiled
binary to run on Windows and Linux to just get going and testing (before you
say there you go, you do it, that would just create so many problems for other
poeple that its really not worth it). Mr Coder doesn't necessarily want to
compile the language to get it to work, on either platform. Also Mr Coder
wants to be able to test the new Eu, without de installing or breaking a
previous
setup until he gets confidence in the new install.
The feature list for eu 4 has crept from the standard libs (great work), all
the way to enums and (horror) optional then do s.
Shouldn't the evolution be defined first, that evolution achieved, then
released as a release. The way things are going, the language will have
morphed into C, D or Q before Mr Coder gets to do anything useful.
Also, there's a lot of voting going on in the list - why not just use
one of the free poll sites to ask a question and see what the majority
want, or, once there is a stable release, then add new features, and see
if poeple wish to retain it?
Yet another argument for forums, as opposed to the list (though the threads
go a little way to help - will be really useful once organised by date of the
last post). Most forums have an inbuilt poll.
So, Jeremy, since you are without doubt at the helm of Euphoria 4.0 now, I
charge
you to fix the feature list, achieve the list, and release for beta and
stability testing.
Chris
2. Re: Feature creep
ChrisBurch3 wrote:
>
> Hi
>
> There are so many changes going on at once, without solid feature
> testing (no disrespect Jeremy, but unit tests will only give you back what
> you want, and not always how they would react in real life (for this read
> all over the place coders like me))
>
> Assume I am Mr Bog Standard Joe Coder. I don't care about all the internal
> shenannigans, I just want a robust, fast reasonably feature rich language,
> that could evolve at a reasonable pace, without breaking vast tracts of
> previous
> code and be well supported by all the authors.
Yes, I agree with this.
> Where's the release for general programmers? Mr Coder wants a precompiled
> binary to run on Windows and Linux to just get going and testing
This will happen. It's not hard to do. Just takes a bit of time (and
figuring out when a good time would be). Most of the work to this point
has been in the libraries and modifying the build process to accommodate
the new library structure.
> Also Mr Coder wants to be able to test the new Eu, without de installing or
> breaking a previous setup until he gets confidence in the new install.
One of the benefits of less reliance on EUDIR and EUINC (in fact, you can do
completely without them!) is that this sort of testing will be easier to
do.
> The feature list for eu 4 has crept from the standard libs (great work),
> all the way to enums and (horror) optional then do s.
Yeah, I think Aku jumped the gun a bit on this one. It's a significant
change, and wasn't around on the forum for even a day before it was
committed.
> So, Jeremy, since you are without doubt at the helm of Euphoria 4.0 now,
> I charge you to fix the feature list, achieve the list, and release for
> beta and stability testing.
Yeah, he's definitely got the stick, though only because he seems to have
the most time and energy right now. I think we may be nearing time to
formalize some project governance, though I'm not sure what that should
look like.
One thing I've thought about is having each developer work in his own
branch, and then have some mechanism for what to put back into the trunk.
It would allow individuals to experiment, but would provide a bit of a
buffer to allow others to examine and comment before putting it into
the trunk.
Certainly open to others' thoughts and suggestions.
Matt
3. Re: Feature creep
ChrisBurch3 wrote:
>
> Hi
>
> There are so many changes going on at once, without solid feature
> testing (no disrespect Jeremy, but unit tests will only give you back what
> you want, and not always how they would react in real life (for this read
> all over the place coders like me))
I'm also worried about this. I'm a strong believer in unittests, but they can
only go so far. A well thought out plan and test suite for each facility in Eu
needs to be developed and maintained. It should be good enough to be the standard
that a compliant Euphoria system should be able to pass.
> So, Jeremy, since you are without doubt at the helm of Euphoria 4.0
> now, I charge you to fix the feature list, achieve the list, and
> release for beta and stability testing.
By the time Eu4 hits the streets, it should have gone through enough testing
that the only things that go wrong will be truly exceptional ones. The vast
majority of Euphoria code (once any broken syntax is repaired) should execute
without any surprises.
But that goes without saying, of course.
However, making sure that this actually happens will not be easy. I will require
a strong project manager, thorough planning, lots of consulation, and lots of
highly motivated people doing the testing and reviewing.
I'm sure we need a lot of alpha testing, at least one round of beta testing but
probably two, then a stage of having it available to cutting-edge dare-devil
coders before making it readily available to the masses.
The first thing to do, is decide who is going to be its lead person. I think
Jeremy is doing a good job and if he has time and energy, and wants to do it, I
vote for him.
The scope of the Eu4 changes need to be documented and very very soon we must
stop adding to it. Once closed, only changes that are absolutely and immediately
important, and agreed upon, can be added/changed/deleted.
Someone needs to take charge of the test plan, including the master test suite
development.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
4. Re: Feature creep
Looks like Euphoria development has gone from "glacially slow" to "avalanche".
Rob was terribly reluctant to make changes, even when they were totally
justified.
Now, we're changing stuff just because we can, without regard to whether the
changes
are needed or will actually work.
Still, none of the fundamental limitations that make Euphoria awkward to use
have
been addressed. I won't bother to enumerate them, they've been cussed and
discussed thoroughly. Read the archives.
5. Re: Feature creep
Matt Lewis wrote:
> > The feature list for eu 4 has crept from the standard libs (great work),
> > all the way to enums and (horror) optional then do s.
>
> Yeah, I think Aku jumped the gun a bit on this one. It's a significant
> change, and wasn't around on the forum for even a day before it was
> committed.
I saw so many committed changes before they were agreed on the forum.
Examples include the continue, enum and ifdef keyword.
So I just followed the pattern.
6. Re: Feature creep
ChrisBurch3 wrote:
>
> Hi
>
> There are so many changes going on at once, without solid feature
> testing (no disrespect Jeremy, but unit tests will only give you back what
> you want, and not always how they would react in real life (for this read
> all over the place coders like me))
>
> Assume I am Mr Bog Standard Joe Coder. I don't care about all the internal
> shenannigans, I just want a robust, fast reasonably feature rich language,
> that could evolve at a reasonable pace, without breaking vast tracts of
> previous
> code and be well supported by all the authors.
>
> Where's the release for general programmers? Mr Coder wants a precompiled
> binary to run on Windows and Linux to just get going and testing (before you
>
> say there you go, you do it, that would just create so many problems for other
> poeple that its really not worth it). Mr Coder doesn't necessarily want to
> compile the language to get it to work, on either platform. Also Mr Coder
> wants to be able to test the new Eu, without de installing or breaking a
> previous
> setup until he gets confidence in the new install.
I am not following what you are speaking of above. Eu4 will be available for
download just as any others once it hits alpha and on. It will run side by side
against any other Eu install (as I do now).
>
> The feature list for eu 4 has crept from the standard libs (great work), all
>
> the way to enums and (horror) optional then do s.
>
> Shouldn't the evolution be defined first, that evolution achieved, then
> released as a release. The way things are going, the language will have
> morphed into C, D or Q before Mr Coder gets to do anything useful.
>
A while ago, I called for a roadmap, created a roadmap wiki page and asked
people to please help define where 4.0 is going. No one responded, no one made
any suggestion what-so-ever. There were a few comments on on the roadmap page
about "I like that" but nothing more.
When I first started developing on Eu, I asked, "Where's the plan? Where's the
roadmap?" The answer was, we just work and it get's released when it get's
released. I said, Hm? Really? back then.
> Also, there's a lot of voting going on in the list - why not just use
> one of the free poll sites to ask a question and see what the majority
> want, or, once there is a stable release, then add new features, and see
> if poeple wish to retain it?
I thought of this, but whenever I have directed people *outside* of EUforum, the
response was nil.
> Yet another argument for forums, as opposed to the list (though the threads
> go a little way to help - will be really useful once organised by date of the
> last post). Most forums have an inbuilt poll.
>
> So, Jeremy, since you are without doubt at the helm of Euphoria 4.0 now, I
> charge
> you to fix the feature list, achieve the list, and release for beta and
> stability testing.
>
This is a step I feared greatly to take. Not because of responsibility, not
because of authority, but I am the new kid on the developer block. Who am I to
jump in like a mighty giant and start telling developers who have been working on
improving Euphoria for a few years now, this is what is going to happen and this
is how it is going to happen. I'm the boss, your the slave.
But it needs some type of direction.
Now, let me explain myself a bit on the new features...
Right now further standard library development is in a holding pattern due to
conflicts amongst the developers on how to resolve some namespace issues. We were
wanting to create a few options and present it to the list but we feel as though
we do not understand each others side well enough yet for even us to understand
what the options are. This is an ongoing discussion that seems to have slowed.
During this time, I have no ability to even execute on a decision that we make
in namespaces because I have a limited knowledge of the translator and IL code.
So, I began looking at code, started looking at proposals and feature requests.
With my minimal knowledge of the backend, I then decided what would be easiest to
implement and begin to give me experience in the backend. The request on SF.net
and EuWiki for continue was the answer.
While in a holding pattern, I took the time to learn. I studied, tried, failed.
Studied more, tried and failed again. I then studied again and again and again,
and came up with a working solution. It however, was not optimal, so I scratched
that and studied some more. Finally, I understood what was going on and how to
implement continue. I did so then I asked the forum about it. I did this in the
reverse order I normally work for one reason... I didn't know if I could do it. I
did not want to pose a feature to the forum and have them accept it with great
favor and then say, um, sorry guys, I can't do it.
So, in my learning, I learned how other things worked. I then looked for more
feature requests. Two of them that have been requested and implemented many times
in the archive w/pre-processors or other means, were a debug block and
conditional includes.
I sat down and thought, what would be the best way to do this? I then thought
let's learn from others. I looked at some pre-processors. I looked at other
languages pre-processors I then started thinking of the best way to make that
work in Euphoria. I did not want a pre-processor, as that would cause code
slowdown in an interpreted language. That is not what we want. I am not using
Euphoria because it's slow 
So, I came up with the idea for the ifdef with
some help of those here on the forum. I implemented it and then posted here about
my results. This time I talked about it before implementing because I was pretty
sure I could do it. Once implemented, I posted here. It met with great favor.
There was talk about possible different keywords, but keyword changing is easy,
the functionality was the hard part, so I committed. We can change syntax, we are
not at an alpha level.
So, I then went for one more, because I was still not at the point of being able
to help any with namespaces. Looking again at Euphoria code and asking what could
be done here to make Euphoria easier yet to use w/o causing performance degration
or added complexity? Maybe even what could make it perform better. The enum idea
came to my head. All the while, we are still in a holding pattern getting no
closer to 4.0 due to namespace issues. I often would change the structure while
refactoring my code and have to go back and add new items, change a bunch of
numbers, etc... So, I worked on enum, again to ensure I could do it. I then
posted to the list and again, it was met with great favor.
Now, we are here today. I felt good about making such changes, because, after
all, we are making a major version jump. A version jump to 4.0. This is the time
to take care of *very long* standing requests that are beneficial. There are many
requests I skiped on by because of one reason or another (mass changes, no
apparent benefit, highly controversial, etc...). I asked questions about some
features in SF area. I closed some features that have already been implemented,
etc...
So, that's my story and that's how we are where we are today.
--
Jeremy Cowgar
http://jeremy.cowgar.com
7. Re: Feature creep
As much as I welcome the new additions to Euphoria, I think the time is fast
approaching when we must call a halt to new features (for the current release).
In the past I was concerned that Euphoria might never progress. Now we are in
danger of the opposite.
We must consider whether some of the changes are really beneficial (optional
"do" and "then"). New features must be thoroughly tested and fixed. Some of the
releases since Euphoria gone open source have been lacking here.
Larry Miller
8. Re: Feature creep
yuku wrote:
>
> Matt Lewis wrote:
> > > The feature list for eu 4 has crept from the standard libs (great work),
> > > all the way to enums and (horror) optional then do s.
> >
> > Yeah, I think Aku jumped the gun a bit on this one. It's a significant
> > change, and wasn't around on the forum for even a day before it was
> > committed.
>
> I saw so many committed changes before they were agreed on the forum.
> Examples include the continue, enum and ifdef keyword.
> So I just followed the pattern.
They were met with great favor, not with concerns, votes against, legitimate
examples of confusion.
--
Jeremy Cowgar
http://jeremy.cowgar.com
9. Re: Feature creep
I think you're doing a fine job, Jeremy.
I didn't comment on the roadmap because it was good. Now, we've discussed other
possibilities here. Not all of them need to be included in 4.0 instead of in the
future, but I don't know if 4.0 ready for feature-freeze yet, either.
--
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.
10. Re: Feature creep
Jeremy Cowgar wrote:
>
> A while ago, I called for a roadmap, created a roadmap wiki page and asked
> people
> to please help define where 4.0 is going. No one responded, no one made any
> suggestion what-so-ever. There were a few comments on on the roadmap page
> about
> "I like that" but nothing more.
This is why I think public development of Euphoria is a joke. MOST of the
people using Euphoria love it, and they don't care to get involved in its
development because they trust those who are developing it, or they're too
busy doing actual work with the current implementation of Euphoria.
Therefore, I propose we form a Euphoria Developers Group. Anybody who is
interested in developing Euphoria can join. This group will no doubt be
small, and that will allow Euphoria to get on and remain on the cutting
edge of giving end users what they want and need to get their programs
created quickly. We will move development-related discussion from this
EuForum to another forum elsewhere (SF.net, etc.).
> This is a step I feared greatly to take. Not because of responsibility, not
> because of authority, but I am the new kid on the developer block. Who am I
> to jump in like a mighty giant and start telling developers who have been
> working
> on improving Euphoria for a few years now, this is what is going to happen and
> this is how it is going to happen. I'm the boss, your the slave.
Because you (we) are the one[s] who is/are vocal and working.
The squeaky wheel will get the grease. If you want to squeak, join the
Euphoria Developers Group. If you trust the EDG, then you don't have to
join.
But if you are part of that group, you will be expected to at least give your
input. You won't have to necessarily commit changes, etc. We have Jeremy
and Matt for that. ;)
So far with development of 4.0, the only thing I was cautious about was
making 'then' and 'do' optional. I would always use those terms simply
for maintenance purposes, so my only concern was what if I began using
a library that did not use 'then' and 'do?' Could that lead to problems
in my own code?
So, somebody set up a Euphoria Developers forum and those who care about
Euphoria development can join.
11. Re: Feature creep
c.k.lester wrote:
>
> Jeremy Cowgar wrote:
> >
> > A while ago, I called for a roadmap, created a roadmap wiki page and asked
> > people
> > to please help define where 4.0 is going. No one responded, no one made any
> > suggestion what-so-ever. There were a few comments on on the roadmap page
> > about
> > "I like that" but nothing more.
>
> This is why I think public development of Euphoria is a joke. MOST of the
> people using Euphoria love it, and they don't care to get involved in its
> development because they trust those who are developing it, or they're too
> busy doing actual work with the current implementation of Euphoria.
>
> Therefore, I propose we form a Euphoria Developers Group. Anybody who is
> interested in developing Euphoria can join. This group will no doubt be
> small, and that will allow Euphoria to get on and remain on the cutting
> edge of giving end users what they want and need to get their programs
> created quickly. We will move development-related discussion from this
> EuForum to another forum elsewhere (SF.net, etc.).
>
> > This is a step I feared greatly to take. Not because of responsibility, not
> > because of authority, but I am the new kid on the developer block. Who am I
> > to jump in like a mighty giant and start telling developers who have been
> > working
> > on improving Euphoria for a few years now, this is what is going to happen
> > and
> > this is how it is going to happen. I'm the boss, your the slave.
>
> Because you (we) are the one[s] who is/are vocal and working.
>
> The squeaky wheel will get the grease. If you want to squeak, join the
> Euphoria Developers Group. If you trust the EDG, then you don't have to
> join.
>
> But if you are part of that group, you will be expected to at least give your
> input. You won't have to necessarily commit changes, etc. We have Jeremy
> and Matt for that. ;)
>
> So far with development of 4.0, the only thing I was cautious about was
> making 'then' and 'do' optional. I would always use those terms simply
> for maintenance purposes, so my only concern was what if I began using
> a library that did not use 'then' and 'do?' Could that lead to problems
> in my own code?
>
> 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.
The reason I don't get involved in the WIKI roadmap is because I feel like
you Jeremy, but you've got the ability / time / dedication whatever to
get up there and do it. As I said before, I may not agree with everything
that you do, but I support you 100% for getting on and doing it. Don't get
disheartened - this is the biggest kick up the bum that Eu's had for
a long time. Keep kicking.
Chris
12. Re: Feature creep
c.k.lester wrote:
>
> Jeremy Cowgar wrote:
> >
> > A while ago, I called for a roadmap, created a roadmap wiki page and asked
> > people
> > to please help define where 4.0 is going. No one responded, no one made any
> > suggestion what-so-ever. There were a few comments on on the roadmap page
> > about
> > "I like that" but nothing more.
>
> This is why I think public development of Euphoria is a joke. MOST of the
> people using Euphoria love it, and they don't care to get involved in its
> development because they trust those who are developing it, or they're too
> busy doing actual work with the current implementation of Euphoria.
>
> Therefore, I propose we form a Euphoria Developers Group. Anybody who is
> interested in developing Euphoria can join.
There is such a group already, those who have ability to commit to the SVN
repository because they asked for it and were let in. Perhaps should it include
some people without an access, but at least this core exists already.
> This group will no doubt be
> small, and that will allow Euphoria to get on and remain on the cutting
> edge of giving end users what they want and need to get their programs
> created quickly. We will move development-related discussion from this
> EuForum to another forum elsewhere (SF.net, etc.).
>
This has been highly controversial.
Some "basic users" have already been complaining about "high brow" tech
discussions here. Splitting he forum would indeed relieve them from such reading.
However, it could foster a two tier model, producers on one side, consumers on
another, with ability for anyone not to care about what the other group says.
Either this would happen, and would be detrimental, or most everyone will
continue reading and posting on both forums anyway. This is why I see an unified
list as a lesser evil.
> > This is a step I feared greatly to take. Not because of responsibility, not
> > because of authority, but I am the new kid on the developer block. Who am I
> > to jump in like a mighty giant and start telling developers who have been
> > working
> > on improving Euphoria for a few years now, this is what is going to happen
> > and
> > this is how it is going to happen. I'm the boss, your the slave.
>
> Because you (we) are the one[s] who is/are vocal and working.
>
> The squeaky wheel will get the grease. If you want to squeak, join the
> Euphoria Developers Group. If you trust the EDG, then you don't have to
> join.
>
> But if you are part of that group, you will be expected to at least give your
> input. You won't have to necessarily commit changes, etc. We have Jeremy
> and Matt for that. ;)
>
Consider time availability here.
Like 2-3 years ago, I happened to be able to start working oin the interpreter
and making a few changes I considered beneficial. I currently don't. Who know
when I get another window of opportunity.
I have been doing some stuff, true, mostly related to win32lib. I saw the iron
curtain falling down around Euphoria, that's why I am still here, even though I
was planning to just leave them alone as other languages allow me more
comfortable development. And this is why I'm working on making my earlier sets.e
part of the std lib. Reformatting takes time, but it's moving forward. I'll
commit in a few days, this month anyway.
So yes, input is to be expected from anyone in the EDG. And usually some output
too. But I'd suggest considering some sort of long term average in order to
assess whether someone contributes.
> So far with development of 4.0, the only thing I was cautious about was
> making 'then' and 'do' optional. I would always use those terms simply
> for maintenance purposes, so my only concern was what if I began using
> a library that did not use 'then' and 'do?' Could that lead to problems
> in my own code?
>
Zero. The parser stops reading a logical expression as soon as it finds any
token which would not make sense in a conditional expression at the point it is.
It will keep doing that.
Someone said it would weaken the block structure (how? "if" opens a block, not
"then"), and at the same time rejected a nice way to make it even more visible in
code - proper indentation is a good policy, but no one is compelled to comply. I
must say that I don't quite understand the discrepancy.
CChris
> So, somebody set up a Euphoria Developers forum and those who care about
> Euphoria development can join.
13. Re: Feature creep
CChris wrote:
> c.k.lester wrote:
> > Therefore, I propose we form a Euphoria Developers Group. Anybody who is
> > interested in developing Euphoria can join.
> There is such a group already, those who have ability to commit to the SVN
> repository
> because they asked for it and were let in.
True, but we need to move development discussions to some other forum
besides this one (EuForum). When I ask EuForum if they agree or disagree
with some change to the interpreter, and I get 2-3 responses, I'm not
so enthusiastic about querying the population anymore. They apparently
1. don't care about it, or
2. agree with it, or
3. don't disagree enough to speak up.
> > This group will no doubt be
> > small, and that will allow Euphoria to get on and remain on the cutting
> > edge of giving end users what they want and need to get their programs
> > created quickly. We will move development-related discussion from this
> > EuForum to another forum elsewhere (SF.net, etc.).
> >
>
> This has been highly controversial.
No more controversial than when one person made all the decisions. :)
> However, it could foster a two tier model, producers on one side, consumers
> on another, with ability for anyone not to care about what the other group
> says.
This is probably not true because all the producers will themselves be
consumers!
> Either this would happen, and would be detrimental, or most everyone will
> continue
> reading and posting on both forums anyway. This is why I see an unified list
> as a lesser evil.
The population of developers is very tiny. I would say, at the most, there
are maybe 5-10 active developers, and that's being optimistic.
> So yes, input is to be expected from anyone in the EDG. And usually some
> output
> too. But I'd suggest considering some sort of long term average in order to
> assess whether someone contributes.
Well, of course.
14. Re: Feature creep
CChris wrote:
>
> c.k.lester wrote:
>
> > So far with development of 4.0, the only thing I was cautious about was
> > making 'then' and 'do' optional. I would always use those terms simply
> > for maintenance purposes, so my only concern was what if I began using
> > a library that did not use 'then' and 'do?' Could that lead to problems
> > in my own code?
>
> Zero. The parser stops reading a logical expression as soon as it finds any
> token which would not make sense in a conditional expression at the point it
> is. It will keep doing that.
You didn't answer his question. Of course the parser could be capable of
doing that. But that's only one part of the equation. The programmer must
also be considered. We've already had one person tell us about how this
would absolutely cause him problems.
> Someone said it would weaken the block structure (how? "if" opens a block,
> not "then"), and at the same time rejected a nice way to make it even more
> visible in code - proper indentation is a good policy, but no one is
> compelled to comply. I must say that I don't quite understand the
> discrepancy.
Yes, I said it. We must have different definitions of block. I (nor did
Jason) reject proper indentation. I guess we assumed (I certainly did) that
since the topic was modifying the interpreter, so were you. Even so, it's
not uncommon to write multi-line conditionals. I do sometimes miss putting
an "and" or an "or" between lines (just like Salix's example).
As to the block issue, consider the following:
-- Current syntax:
if foo then
puts(1,"foo")
end if
-- Optional then syntax:
if foo
puts(1,"foo")
end if
In both cases, the block of code within the if statement is puts(1,"foo").
In the current example, the block is defined by "then" and "end if". In the
optional example, the block is defined by the end of the logical expression
("foo") and "end if".
In neither case would I consider "foo" to be part of the block. Nor does
any other language I'm aware of. In fact, many require you to put the
condition inside parenthesis, which euphoria does not.
15. Re: Feature creep
Matt Lewis wrote:
>
> CChris wrote:
> >
> > c.k.lester wrote:
> >
> > > So far with development of 4.0, the only thing I was cautious about was
> > > making 'then' and 'do' optional. I would always use those terms simply
> > > for maintenance purposes, so my only concern was what if I began using
> > > a library that did not use 'then' and 'do?' Could that lead to problems
> > > in my own code?
> >
> > Zero. The parser stops reading a logical expression as soon as it finds any
> > token which would not make sense in a conditional expression at the point it
> > is. It will keep doing that.
>
> You didn't answer his question. Of course the parser could be capable of
> doing that. But that's only one part of the equation. The programmer must
> also be considered. We've already had one person tell us about how this
> would absolutely cause him problems.
>
> > Someone said it would weaken the block structure (how? "if" opens a block,
> > not "then"), and at the same time rejected a nice way to make it even more
> > visible in code - proper indentation is a good policy, but no one is
> > compelled to comply. I must say that I don't quite understand the
> > discrepancy.
>
> Yes, I said it. We must have different definitions of block. I (nor did
> Jason) reject proper indentation. I guess we assumed (I certainly did) that
> since the topic was modifying the interpreter, so were you. Even so, it's
> not uncommon to write multi-line conditionals. I do sometimes miss putting
> an "and" or an "or" between lines (just like Salix's example).
>
What would be the need to indent them?
After all, the interpreter knows indentation doesn't count inside a header.
> As to the block issue, consider the following:
> }}}
<eucode>
> -- Current syntax:
> if foo then
> puts(1,"foo")
> end if
>
> -- Optional then syntax:
> if foo
> puts(1,"foo")
> end if
> </eucode>
{{{
> In both cases, the block of code within the if statement is puts(1,"foo").
> In the current example, the block is defined by "then" and "end if". In the
> optional example, the block is defined by the end of the logical expression
> ("foo") and "end if".
>
Keep then and friends optional, I see nothing wrong with them apart from having
to type them and clutter the screen.
> In neither case would I consider "foo" to be part of the block. Nor does
> any other language I'm aware of. In fact, many require you to put the
> condition inside parenthesis, which euphoria does not.
But they spare you the "end <block>".
CChris
16. Re: Feature creep
- Posted by Jeremy Cowgar <jeremy at ?owga?.com>
May 15, 2008
-
Last edited May 16, 2008
ChrisBurch3 wrote:
>
> Hi
>
> There are so many changes going on at once, without solid feature
> testing (no disrespect Jeremy, but unit tests will only give you back what
> you want, and not always how they would react in real life (for this read
> all over the place coders like me))
>
I agree, however, unit testing catches bugs, especially during development. It
also ensures bugs will not re-appear and when an application is under heavy
development, it stops bugs. For instance, a change was committed to Euphoria when
the function changed was tested with a "test" program. The test program passed
with flying colors. However, unit tests failed big time. The change was not
counting on the fact that many other functions relied upon that one changed
function.
I also am head of IT and oversee maintenance of medical software with many units
that are tested on a routine basis. Unit testing there has caught so much, I
would not dream of ever releasing anything from it w/o unit testing.
Unit testing does not catch everything, but it sure catches a lot, if you spend
the time to write correct tests. Euphoria's unit testing is still in need of a
good round of unit test additions. Currently it is only testing for good input,
good output. Proper testing needs good and bad input. Way too often unit tests I
see written are exactly that, because they are the easiest to write. Once I
figure out the best way to run unit tests that crash Euphoria, then I will start
testing bad input as well.
Basically, I maintain, if your unit tests do not catch bugs that happen in real
life, then your unit tests are not testing properly. Now, the problem is, who can
think of every possible situation that can occur in real life? None, but we sure
can think of a lot of them. I know this is true and it's easy to prove. Wait for
a bug to happen in real life. Then look at your unit tests. Did you check for
that type of error? I'm sure the answer is no.
Many functions can only be twisted so much, for instance:
function add(integer a, integer b)
First, we know that Euphoria is working (because it has other unit tests). So,
we know doing: add("John", "Doe") is not going to work. We know add(10.5, 2.43)
is not going to work, etc... So, what are the possible values that could be
passed? Granted this is an easy function to unit test, but I would venture to
say, that you can easily test this function and no amount of real world use is
going to extend past your testing. Now, did you spend 3 seconds writing a unit
test? Sure, the testing of that function is useless and even this function will
fail. But, it's easy to write conclusive tests for that function, as it is for
many, many functions. Other functions are more difficult but still doable.
--
Jeremy Cowgar
http://jeremy.cowgar.com
17. Re: Feature creep
- Posted by Derek Parnell <ddparnell at bi?po?d.com>
May 15, 2008
-
Last edited May 16, 2008
Jeremy Cowgar wrote:
> unit testing catches bugs, especially during development.
It sure does. Unit tests, along with other forms of automated testing must be
used.
The design of test cases and unit tests is a bit of a black art and some people
do it better than others. But not doing it at all is a poor decision.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
18. Re: Feature creep
- Posted by ChrisBurch3 <crylex at ?mail.co?>
May 15, 2008
-
Last edited May 16, 2008
Jeremy Cowgar wrote:
>
> ChrisBurch3 wrote:
> >
> > Hi
> >
> > There are so many changes going on at once, without solid feature
> > testing (no disrespect Jeremy, but unit tests will only give you back what
> > you want, and not always how they would react in real life (for this read
> > all over the place coders like me))
> >
>
> I agree, however, unit testing catches bugs, especially during development.
> It also ensures bugs will not re-appear and when an application is under
> heavy
> development, it stops bugs. For instance, a change was committed to Euphoria
> when the function changed was tested with a "test" program. The test program
> passed with flying colors. However, unit tests failed big time. The change was
> not counting on the fact that many other functions relied upon that one
> changed
> function.
>
> I also am head of IT and oversee maintenance of medical software with many
> units
> that are tested on a routine basis. Unit testing there has caught so much, I
> would not dream of ever releasing anything from it w/o unit testing.
>
> Unit testing does not catch everything, but it sure catches a lot, if you
> spend
> the time to write correct tests. Euphoria's unit testing is still in need of
> a good round of unit test additions. Currently it is only testing for good
> input,
> good output. Proper testing needs good and bad input. Way too often unit tests
> I see written are exactly that, because they are the easiest to write. Once
> I figure out the best way to run unit tests that crash Euphoria, then I will
> start testing bad input as well.
>
> Basically, I maintain, if your unit tests do not catch bugs that happen in
> real
> life, then your unit tests are not testing properly. Now, the problem is, who
> can think of every possible situation that can occur in real life? None, but
> we sure can think of a lot of them. I know this is true and it's easy to
> prove.
> Wait for a bug to happen in real life. Then look at your unit tests. Did you
> check for that type of error? I'm sure the answer is no.
>
> Many functions can only be twisted so much, for instance:
>
> }}}
<eucode>
> function add(integer a, integer b)
> </eucode>
{{{
>
> First, we know that Euphoria is working (because it has other unit tests). So,
> we know doing: add("John", "Doe") is not going to work. We know add(10.5,
> 2.43)
> is not going to work, etc... So, what are the possible values that could be
> passed? Granted this is an easy function to unit test, but I would venture to
> say, that you can easily test this function and no amount of real world use
> is going to extend past your testing. Now, did you spend 3 seconds writing a
> unit test? Sure, the testing of that function is useless and even this
> function
> will fail. But, it's easy to write conclusive tests for that function, as it
> is for many, many functions. Other functions are more difficult but still
> doable.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Phew, thats me told!
Chris
(PS, I also am the head of IT - by default! Does anybody know what the
universal solution to "its not working" is?)
19. Re: Feature creep
- Posted by Matt Lewis <matthewwalkerlewis at ?m?il.com>
May 15, 2008
-
Last edited May 16, 2008
ChrisBurch3 wrote:
>
> (PS, I also am the head of IT - by default! Does anybody know what the
> universal solution to "its not working" is?)
Reboot!
20. Re: Feature creep
- Posted by Mike777 <anon4321 at g?ail.com>
May 15, 2008
-
Last edited May 16, 2008
Matt Lewis wrote:
>
> ChrisBurch3 wrote:
> >
> > (PS, I also am the head of IT - by default! Does anybody know what the
> > universal solution to "its not working" is?)
>
> Reboot!
I am ashamed to admit that my wife fell victim to the solution being: "Reformat
your hard drive." When she called me from the repair shop she was so proud!
Mike
21. Re: Feature creep
ChrisBurch3 wrote:
> (PS, I also am the head of IT - by default! Does anybody know what the
> universal solution to "its not working" is?)
Yes... "You're doing it wrong."
http://www.doingitwrong.com/
--
Jeremy Cowgar
http://jeremy.cowgar.com
22. Re: Feature creep
Matt Lewis wrote:
>
> ChrisBurch3 wrote:
> >
> > (PS, I also am the head of IT - by default! Does anybody know what the
> > universal solution to "its not working" is?)
>
> Reboot!
Get a bigger hammer.
--
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.
23. Re: Feature creep
ChrisBurch3 wrote:
> (Does anybody know what the
> universal solution to "its not working" is?)
Hand it to the marketing department.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
24. Re: Feature creep
Jeremy Cowgar wrote:
> So, that's my story and that's how we are where we are today.
And more power to you. I have always followed the Euphoria list and it used to
be easy to keep up with the 10-20 messages per week at times when someone wanted
help with win32lib or something.
Since you've initiated this development phase I think there's been an average of
about a page of posts per day. All this discussion is good, and so are the
changes to the language.
This puts Euphoria on a development curve now equivalent to Python, Perl, or PHP
and it may become as useful, adopted, and general purpose as those languages
because of these changes.
Gary
25. Re: Feature creep
c.k.lester wrote:
>
> CChris wrote:
> > c.k.lester wrote:
> > > Therefore, I propose we form a Euphoria Developers Group. Anybody who is
> > > interested in developing Euphoria can join.
> > There is such a group already, those who have ability to commit to the SVN
> > repository
> > because they asked for it and were let in.
>
> True, but we need to move development discussions to some other forum
> besides this one (EuForum). When I ask EuForum if they agree or disagree
> with some change to the interpreter, and I get 2-3 responses, I'm not
> so enthusiastic about querying the population anymore. They apparently
>
> 1. don't care about it, or
> 2. agree with it, or
> 3. don't disagree enough to speak up.
>
<snip>
4. or, don't yet really understand a proposal well enough to comment,
and will wait for more discussion as a basis for understanding the
proposal.
Dan
26. Re: Feature creep
Dan Moyer wrote:
>
> 4. or, don't yet really understand a proposal well enough to comment,
> and will wait for more discussion as a basis for understanding the
> proposal.
I'll try to be more descriptive and give better examples of new proposals. If
something is not understood, speak up and those who wrote the proposal should go
into more detail.
--
Jeremy Cowgar
http://jeremy.cowgar.com
27. Re: Feature creep
Dan Moyer wrote:
> c.k.lester wrote:
> > They apparently
> >
> > 1. don't care about it, or
> > 2. agree with it, or
> > 3. don't disagree enough to speak up.
> >
>
> 4. or, don't yet really understand a proposal well enough to comment,
> and will wait for more discussion as a basis for understanding the
> proposal.
If they don't understand something, they better speak up and ask a question
instead of holding up development... IMHO. :)
