1. RE: Eu's poor design(Irv)

eugtk at yahoo.com wrote:
> 
> 
> 3. You totally missed the fact that Euphoria does
> indeed have a major design flaw.  One which causes 
> problems both for beginners and for experienced Eu
> programmers, and which may limit Euphoria's future 
> growth.  An analysis of this would make a good 
> term paper. 
> 
> Irv
> 
> 

Hi Irv,

What what might that be?

Take care for now,
Al

new topic     » topic index » view message » categorize

2. RE: Eu's poor design(Irv)

Al Getz wrote:
> 
> 
> eugtk at yahoo.com wrote:
> > 
> > 
> > 3. You totally missed the fact that Euphoria does
> > indeed have a major design flaw.  One which causes 
> > problems both for beginners and for experienced Eu
> > programmers, and which may limit Euphoria's future 
> > growth.  An analysis of this would make a good 
> > term paper. 
> > 
> > Irv
> > 
> > 
> Hi Irv,
> 
> What what might that be?
> 
> Take care for now,
> Al
> 

Hi Irv

Ditto ;)

Marc

new topic     » goto parent     » topic index » view message » categorize

3. RE: Eu's poor design(Irv)

--- Al Getz <Xaxo at aol.com> wrote:
 
> eugtk at yahoo.com wrote:
> > 
> > 
> > 3. You totally missed the fact that Euphoria does
> > indeed have a major design flaw.  One which causes
> > problems both for beginners and for experienced Eu
> > programmers, and which may limit Euphoria's future
> > growth.  An analysis of this would make a good 
> > term paper. 
> > 
> > Irv
> > 
> > 
> Hi Irv,
> 
> What what might that be?

Euphoria is a strongly-typed language which just can't

seem to keep track of what those types are supposed to
be, or how to use them.

In most "high level" languages, after you define a
variable 
as a certain type, you can just "print" that variable
without concern about the type. Not with Eu. You, 
the programmer, have to choose the correct print
function from a number of supplied functions
to properly display each type of variable. This is a
job 
for the computer language, not the programmer. 
For examples, see almost any language other than 
asm or C. 

In Eu, you can define a variable as an integer, and 
Eu won't let you assign a float to it. That's good.
However, as soon as you try to create an array of 2 or
more integers, all bets are off.  You can assign
anything, 
including floats or strings, to those "integer" array
positions. Are "arrays of integers" a useless concept?
I don't think so.

Speaking of arrays, it's pretty well accepted that 
arrays of characters (AKA "strings") are also useful 
in computer programming. So how do you tell Eu to
create a variable that *must* be a string? Not one
that could be a string, or might just as easily be an
array of coordinates, or a list of pointers to C
routines ? 

Structured data; believe it or not, a lot of 
programmers like to structure their data in some
meaningful form. Let's say, for example, I want to
keep 
track of my customers and how much they owe me.
( just an example, no one would really want to do
that, 
would they? )

"Joe", 12.99
"Sue", 4.50
"Jack", 9.94

Can you do this in Eu? Sure, except that if you
actually 
try to keep the names and the amounts together as a 
package, you find that there's nothing stopping you, 
or an inept employee, from changing the data to : 

"Joe","applesauce"
24, 4.50
NULL, 9.94

Sure, you can write routines to check each item as
it's 
entered - but isn't that what a so-called "high-level"

language is supposed to do for us?

Even user-defined types don't help here, for at least
two reasons: 

1. Your routine has to check _every_ single item in
your 
"structure" whenever any _one_ item in that structure 
receives an assignment. In real life, this could mean 
dozens or hundreds of checks. Writing and debugging 
those routines is a chore, and everytime the structure

changes even slightly, the UDT routines have to be
re-written. 

2. What's worse, even after you have written that
complex type-checking routine, once you detect an
invalid assignment, there's nothing you can do about
it 
except to crash! Wasn't it QBasic that had a 
"redo-from-start" error message that at least let 
you try again, rather than losing your work?

So, what we have is a strongly-typed and
error-resistant language, as long as we're writing
very simple code dealing with numbers (no strings or
arrays, plz)
integer a, b, c
atom x

Once you move beyond those simple "atomic" variables,
Eu becomes a totally untyped and pretty error-prone
language. This is the source of a lot of confusion for
beginners, and a continuing headache for everyone. 

I believe that the fact that you can't declare, and Eu
can't keep track of the type(s) of entities within
sequences is what's kept Eu from having real
structures, as well as a number of other
often-requested features. Even if he wanted to, Rob
probably couldn't add things like typed arrays,
structures, OOP, without re-inventing the core of the
language.

Maybe he'll prove me wrong, but I doubt it.

All that said, Eu is still a pretty good language. 
Just not nearly as good as it could have been.

Regards,
Irv

new topic     » goto parent     » topic index » view message » categorize

4. RE: Eu's poor design(Irv)

Thanks for clarifying about the design flaw.

For me, I've found Euphoria has become my choice for making quick "hack" pr=
ograms to accomplish something specific.  I've been using it a bit over a y=
ear now but just recently I've begun to get a lot more into it.

There are definite obstacles when using it to implement a large, commercial=

quality application.  While not insurmountable as if you're resourceful you=
 can always find a work-around, they're an issue.

Having to make sure your sequences are storing the type of data you want I'=
ve found as well can be a headache.  You do need to check everything a user=
 inputs carefully.  I usually use an extra variable for that and make sure =
it's right before I add it to the sequence it's intended for.  Of course, n=
ot only is that extra code but it doesn't address all of the possible probl=
ems as Irv pointed out.

Also, I'm not entirely sure it would be the ideal choice for a beginner unl=
ess an experienced teacher is involved.  I'm able to fall back on my experi=
ence with other languages to figure things out when I need to.  If I didn't=
 have that experience to fall back on I would definitely want more document=
ation and reference material available than exists for Euphoria.

Still, all in all I really love Euphoria and I hope it continues evolving a=
nd becoming an even better product than it is currently.  I also wanted to =
take a minute to thank all of the people involved with Win32Lib and IDE dev=
elopment.  They're fantastic free contributions that have greatly enhanced =
the usefuless of the language for Windows development.

-Deric Wechter
eugtk at yahoo.com wrote:

>
>
>--- Al Getz <Xaxo at aol.com> wrote:
>=20
>> eugtk at yahoo.com wrote:
>> >=20
>> >=20
>> > 3. You totally missed the fact that Euphoria does
>> > indeed have a major design flaw. =A0One which causes
>> > problems both for beginners and for experienced Eu
>> > programmers, and which may limit Euphoria's future
>> > growth. =A0An analysis of this would make a good=20
>> > term paper.=20
>> >=20
>> > Irv
>> >=20
>> >=20
>> Hi Irv,
>>=20
>> What what might that be?
>
>Euphoria is a strongly-typed language which just can't
>
>seem to keep track of what those types are supposed to
>be, or how to use them.
>
>In most "high level" languages, after you define a
>variable=20
>as a certain type, you can just "print" that variable
>without concern about the type. Not with Eu. You,=20
>the programmer, have to choose the correct print
>function from a number of supplied functions
>to properly display each type of variable. This is a
>job=20
>for the computer language, not the programmer.=20
>For examples, see almost any language other than=20
>asm or C.=20
>
>In Eu, you can define a variable as an integer, and=20
>Eu won't let you assign a float to it. That's good.
>However, as soon as you try to create an array of 2 or
>more integers, all bets are off. =A0You can assign
>anything,=20
>including floats or strings, to those "integer" array
>positions. Are "arrays of integers" a useless concept?
>I don't think so.
>
>Speaking of arrays, it's pretty well accepted that=20
>arrays of characters (AKA "strings") are also useful=20
>in computer programming. So how do you tell Eu to
>create a variable that *must* be a string? Not one
>that could be a string, or might just as easily be an
>array of coordinates, or a list of pointers to C
>routines ?=20
>
>Structured data; believe it or not, a lot of=20
>programmers like to structure their data in some
>meaningful form. Let's say, for example, I want to
>keep=20
>track of my customers and how much they owe me.
>( just an example, no one would really want to do
>that,=20
>would they? )
>
>"Joe", 12.99
>"Sue", 4.50
>"Jack", 9.94
>
>Can you do this in Eu? Sure, except that if you
>actually=20
>try to keep the names and the amounts together as a=20
>package, you find that there's nothing stopping you,=20
>or an inept employee, from changing the data to :=20
>
>"Joe","applesauce"
>24, 4.50
>NULL, 9.94
>
>Sure, you can write routines to check each item as
>it's=20
>entered - but isn't that what a so-called "high-level"
>
>language is supposed to do for us?
>
>Even user-defined types don't help here, for at least
>two reasons:=20
>
>1. Your routine has to check _every_ single item in
>your=20
>"structure" whenever any _one_ item in that structure=20
>receives an assignment. In real life, this could mean=20
>dozens or hundreds of checks. Writing and debugging=20
>those routines is a chore, and everytime the structure
>
>changes even slightly, the UDT routines have to be
>re-written.=20
>
>2. What's worse, even after you have written that
>complex type-checking routine, once you detect an
<snip>

>
>
y!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=3D393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=3D380455

new topic     » goto parent     » topic index » view message » categorize

5. RE: Eu's poor design(Irv)

--- Deric Wechter <dericwechter at netscape.net> wrote:

> Thanks for clarifying about the design flaw.
> 
> For me, I've found Euphoria has become my choice for
> making quick "hack" programs to accomplish 
> something specific.  I've been using it a bit over a
year > now but just recently I've begun to get a lot
more into 
> it.

... snip...

> Still, all in all I really love Euphoria and I hope
> it continues evolving and becoming an even better 
> product than it is currently. 

Indeed, that's why I post messages about things that
need improving, instead of just going away, as many
have done. I think it makes Rob angry to read these,
but, 
hey, Euphoria is a programming language, a product 
Rob sells, not one of his children. No point in being
sensitive about criticism, especially when that
criticism is meant to be constructive.

>  I also wanted to  take a minute to thank all of the
people involved
> with Win32Lib and IDE development.  They're
fantastic free contributions that
> have greatly enhanced  the usefuless of the language
for Windows development.

It would no doubt be a dead language without Dave
Cuny,  Derek, Judith, and all the others who made it
work on Windows. Just another reason we should try 
to make Eu wildly popular, so those people could share

in the profits:)

Regards,
Irv

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu