RE: pass by reference
- Posted by bensler at mail.com
Feb 23, 2002
No offense to you Everett, but I'm tired of lobbying.
Euphoria *has the potential to be* the best language I have found.
However, it still feels like basic to me. It's not going anywhere very
fast. Rob hasn't expressed much interest in expanding the language. I
didn't get into programming to discuss compiler language development,
and I didn't pick up euphoria so I could write libraries which most
people consider essential.
Sure, there is the RDS archives, which is packed full of great stuff,
but I don't have or want to spend the time to explore each lib and
program to see if it has the routines I'm looking for anymore. The least
that RDS could do, if it's not going to add to the language, is
offically support essential and proven libraries.
Which OOP library should I use if I want to use classes? Where's the
string library? Why isn't asm.e shipped with euphoria? Where's
peek/poke2? Where is the standard c_struct library? Why hasn't RDS added
link_dll(), link_func(), and link_proc() to DLL.E?
I've been using euphoria for about 2 years now, so I know the answer
to most of these questions, but even with what I know, I am constantly
finding useful libraries that I didn't before, and spent days writing
for myself. Not too many people are so dedicated.
Stamping is one way, but it doesn't seem to be utilized very
effectively. There should be a list of recommended libraries, sorted by
category and demand.
Also, we should be able to filter the archives by stamped files, and
sort by money donated(popularity).
Rob,
I know you are only one person, and it's very difficult, if not near
impossible to foster a project of this magnitude on your own, but that's
why I think you need to reevaluate your vision of euphoria, as well as
consider staffing a development team.
Don't have the money to employ anyone? Consider offering royalties from
future sales. It's a good incentive for calculated development, and will
encourage the developers to try harder to do better as well.
I'm sure there are people on this list who would help for free, if only
to see euphoria succeed and floruish.
I too think that moderation and mediation are essential to develop the
language to it's fullest, but there comes a time when you need to
compromise. Reducing the price of your product should be a huge
indication of your progress.
I'm not even concerned if ANY of my suggestions make it into the
language or your marketing strategies, but you need to do SOMETHING. In
the very least, you need to outline your plan for euphoria's future, so
people know what to expect and can make suggestions based on what your
stated priorities are. There are a lot of extremely talented people in
this community making excellent suggestions, and they seem to be not
only unnoticed, but ignored.
I will continue to use Euphoria, and hope for it's success, but at
this rate, like Irv, I will most likely migrate to a more productive
language. The only real reasons I am still here, is because would like
to see euphoria do well, and because I love a challenge. Probably more
the latter, because as selfish as it may sound, I have nothing to gain
by promoting and lobbying for euphoria. I'm sure I will be more than
challenged by C/C++.
This sounds an awful lot like a rant. To a degree it is. But moreover,
I think I speak for alot of people. People who are on this list, people
who have already left the euphoria community, and people who have yet to
discover euphoria.
Chris
Everett Williams wrote:
> Chris,
>
> Only one small point. There is no error recovery in Eu,
> because there is no trapping. All code in Euphoria is
> defensive. One must write checking code for every possible
> error( a thing that one quickly realizes is not possible
> in static data handling and flat unreasonable when handling
> dynamic data ). Without some form of error trapping, we
> are reduced to after-the-fact debugging of each error. If
> we knew how to or could practically check all errors before
> they happened, we would probably have a program so large that
> it would not be practical to run or maybe even program. We
> would also be prescient, and I can think of lots of better
> uses for that talent than programming...take me to the race
> track and let me start buying lotto tickets. A language
> without some form of error trapping makes even debugging a
> very difficult task. With error trapping, I can make a test
> run, logging each error that I find. Then I can examine that
> log and deal with a whole group of errors at once rather
> than have to debug and restart after each error. The other
> problem with such sequential bug chasing is that each fix
> has the possibility of creating or enhancing or hiding other
> errors, further complicating the process.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
> bensler at mail.com wrote:
>
> >
> > <SNIP>
> >
> >>for testing purposes (only)
> >>
> >
> > Currently, yes, that's all that typechecks are good for.
> >
> > <SNIP>
> >
> >>>As a customer who purchases software, I would be appalled to run a
> >>>program that I paid money for, to have it crash with some error message
> >>>that doesn't help me at all. Reminds me of Microsoft :P
> >>>
> >
> > This was a fairly inaccurate statement. As is, a program can have
> > extensive error checking AND recovery if wanted. It's just alot of code.
> >
> > With typechecks that modify, one could typically reduce the error
> > checking/recovery code by half if not more. This makes the code more
> > readable, leading to less errors, leading to faster development time.
> > And makes reading 6 month old code alot easier. Getting the code written
> >
> > faster also usually means more time for testing.
> > Writing error checking routines is also boring. When I'm bored, I'm less
> >
> > productive.
> > Error recovery is even more tedious.
> >
> >
> >>Are you happier if a program you purchased crashes and burns, or if it
> >>does not perform as advertised/is not fit for task?
> >>
> >>If I spend say 2 hours typing in stuff & the program crashes and
> >>burns, losing all my stuff, then I am NOT HAPPY.
> >>
> >>If I spend say 2 hours typing in stuff & the program either pops up
> >>some drivel warning or simply wipes all the stuff I was doing, then
> >>
> > I
> >
> >>am not just "NOT HAPPY", I am seething with rage at the useless <SNIP>
> >>
> >
> > If someone writes an error recovery routine that doesn't fully recover
> > from the error, that's the programmers fault, not the language.
> >
> > Obviously, someone shouldn't write a recovery routine that resets a
> > spreadsheet database to DEAFULT. That's just STUPID, and that programmer
> >
> > should be shot.
> >
> >
> >>If the type check fails so you save loads & loads of stuff for
> >>possible recovery, then good on ya, but if you're gonna write code
> >>that says 'This should never be 9. I don't care how, why or at all, so
> >>I'll just set it back to a nice safe 0", then **** you.
> >>
> >>
> >>>It makes alot more sense to at least ATTEMPT to rectify the problem
> >>>before resorting to the BLACK screen of death.
> >>>
> >>As above, I fail to see how hiding the cause of the problem can
> >>possibly help. If you suspect there is going to be a problem modifying
> >>variable x then why not make it a private variable in a new include
> >>file with all the routines, checks etc to modify it?
> >>
> >
> > YOU just answered your own question. A new include file, ALL the
> > routines/checks, etc..
> >
<snip>
|
Not Categorized, Please Help
|
|
