OpenEuphoria

2. Re: Fair Criticism

• Posted by Derek Parnell <ddparnell at bigpond.com> Aug 10, 2001
• 531 views

----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Fair Criticism


>
> I rarely see mention of Euphoria in any newsgroups, and when I do,
> more often than not it is negative. Below is one. While you
> might argue with points one and two, point 3 is right on the money.
>
> -- quote:
>
>   1) I'd never even heard of it before, and I'm a language slut.  This
> suggests to me that the user community is very small, and when the
> author gets tired of it the language will die.

I worry about this a bit too. Robert seems afraid to have it (too) popular.
It seems that RDS wants to remain a small-time outfit.

>   2) It's commercial and proprietary (it's cheap, but it still costs),
> which IMO are acceptable for applications but extraordinarily bad ideas
> for basic infrastructure like a programming language.

This doesn't make a lot of sense. Most successful development environments
are expensive for the "full" version but offer cheap or free cut-down
versions. Also, the language specification is freely available so what's
stopping anybody from creating new compilers and interpreters.

>   3) It's not object-oriented, and doesn't even have structs.  This is
> the real show-stopper.  Without this capability, it's going to be a
> nightmare to write code using complex data structures.  The example in
> the manual of using sequences as structs is just evil incarnate:
> ]A Structure:
> ]        employee = {
> ]                    {"John","Smith"},
> ]                    45000,
> ]                    27,
> ]                    185.5
> ]                   }
> ]To access "fields" or elements within a structure it is good
> ] programming style to make up a set of constants that name the various
> ] fields. This will make your program easier to read. For the example
> ] above you might have:
> ]        constant NAME = 1
> ]        constant FIRST_NAME = 1, LAST_NAME = 2
> ]        constant SALARY = 2
> ]        constant AGE = 3
> ]        constant WEIGHT = 4
> ]You could then access the person's name with employee[NAME], or if you
> ] wanted the last name you could say employee[NAME][LAST_NAME].
>
>   The mind recoils in horror!
> -- end quote
>
> Anyone who has written a substantial program in Euphoria surely will have
to
> agree that
> this arrangement is complex, error-prone, and belies any claim of
> "simplicity" that might
> be made about the language.

I agree with you Irv. The current workaround, using sequences to emulate
structures, is just that - a workaround and not a resolution of this issue.

> Is this going to be fixed in 2.3?

Don't hold your breath. I suspect that RDS can only cope with one major
language enhancement per release. May we should start the campaign for
structures for 2.4.

-----
Derek

4. Re: Fair Criticism

• Posted by president at insight-concepts.com Aug 10, 2001
• 560 views

6. Re: Fair Criticism

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 11, 2001
• 521 views

8. Re: Fair Criticism

• Posted by gertie at ad-tek.net Aug 11, 2001
• 520 views

On 10 Aug 2001, at 18:17, Robert Craig wrote:

> > 
> > I'd never even heard of it before, and I'm a language slut.  This
> > suggests to me that the user community is very small, and when the
> > author gets tired of it the language will die.
> 
> The user community has been growing steadily for years.
> This mailing list has gone from 250 to 360 in the past 6 months.
> I started designing Euphoria 12 years ago, and I'm working on it
> full-time. The source will soon be (mostly) available.
> 
> > It's commercial and proprietary (it's cheap, but it still costs),
> > which IMO are acceptable for applications but extraordinarily bad ideas
> > for basic infrastructure like a programming language.
> 
> Microsoft seems to be doing pretty well peddling C++, Visual Basic,
> various operating systems, and other "basic infrastructure".
> 
> If a programmer can improve his productivity by 10%,
> why on earth would he not spend $39, or even $3900 in doing so?

Well, for some people who make $39 a month, $3900 would seem like a lot of
money,
it sure seems like a lot to me.

> > It's not object-oriented, and doesn't even have structs.  This is
> > the real show-stopper.  Without this capability, it's going to be a
> > nightmare to write code using complex data structures. 
> 
> My worst nightmares by far have occurred while programming
> complex, dynamic, flexible data structures in C/C++, mallocing and
> freeing every step of the way with tremendous opportunities 
> for hideous bugs. In Euphoria it's a breeze.

I *much* prefer the Eu way of free-form structures. This leaves it up to me what
i want
to put in "fields". In Pascal, i used a lot of variant fields, and was
constrained by the
rule of only one variant and it had to be at the end of a pre-declared fixed
record. What
would make arrays/records as complex as C++ or pascal, but far more versatile,
will
be if/when Rob (or someone) adds the runtime var naming, like mirc.
 
Kat

10. Re: Fair Criticism

• Posted by Irv Mullins <irvm at ellijay.com> Aug 11, 2001
• 527 views

Kat wrote:

> I *much* prefer the Eu way of free-form structures. This leaves it up to
me what i want
> to put in "fields". In Pascal, i used a lot of variant fields, and was
constrained by the
> rule of only one variant and it had to be at the end of a pre-declared
fixed record. What
> would make arrays/records as complex as C++ or pascal, but far more
versatile, will
> be if/when Rob (or someone) adds the runtime var naming, like mirc.

No one, including Rob, seems to be able to grasp the fact that fixed-length
"structures".
have never been the issue here. All people want is a simple, maintainable,
and readable,
way to reference parts of a standard Euphoria nested sequence..

 The fact that Rob had trouble with C structures is irrelevant to Euphoria,
except in that
it must have tainted his view of how useful structures can be. The fact that
Pascal's
structures and variant fields were useful to you, (and me, and lots of other
programmers) despite their limitations, should be only more reason to
include something similar in Euphoria, where you can have infinitely variant
fields without the constraints you mentioned above.

It would be nice, after that, if the elements of a structure could retain
their types, but I believe, given the nature of Euphoria, that would be
impossible. So perhaps "structure" would be
an overly ambitious name. Call 'em "indexed lists" or, "named nested
sequences" or whatever,
just as long as the names of the fields are somehow associated with the
sequence itself,
so that we have meaningful and non-colliding names for more than one
sequence  in a given
program.

You know very well that a Pascal program which has both a customer structure
and a product
structure will never get confused when you refer to customer.name or
product.name.
And that you can go into the customer structure later and add a .phone field
without
having to renumber all the following fields in that structure. In most other
languages
this is a standard, in fact an  *expected*  feature. One which simplifies,
not complicates,
the language. One which reduces, not increases, errors.

Regards,
Irv

12. Re: Fair Criticism

• Posted by gertie at ad-tek.net Aug 11, 2001
• 537 views

On 11 Aug 2001, at 16:30, Irv Mullins wrote:

> 
> Kat wrote:
> 
> > I *much* prefer the Eu way of free-form structures. This leaves it up to
> me what i want
> > to put in "fields". In Pascal, i used a lot of variant fields, and was
> constrained by the
> > rule of only one variant and it had to be at the end of a pre-declared
> fixed record. What
> > would make arrays/records as complex as C++ or pascal, but far more
> versatile, will
> > be if/when Rob (or someone) adds the runtime var naming, like mirc.
> 
> No one, including Rob, seems to be able to grasp the fact that fixed-length
> "structures".
> have never been the issue here. All people want is a simple, maintainable,
> and readable,
> way to reference parts of a standard Euphoria nested sequence..
> 
>  The fact that Rob had trouble with C structures is irrelevant to Euphoria,
> except in that
> it must have tainted his view of how useful structures can be. The fact that
> Pascal's
> structures and variant fields were useful to you, (and me, and lots of other
> programmers) despite their limitations, should be only more reason to
> include something similar in Euphoria, where you can have infinitely variant
> fields without the constraints you mentioned above.
> 
> It would be nice, after that, if the elements of a structure could retain
> their types, but I believe, given the nature of Euphoria, that would be
> impossible. So perhaps "structure" would be
> an overly ambitious name. Call 'em "indexed lists" or, "named nested
> sequences" or whatever,
> just as long as the names of the fields are somehow associated with the
> sequence itself,
> so that we have meaningful and non-colliding names for more than one
> sequence  in a given
> program.
> 
> You know very well that a Pascal program which has both a customer structure
> and a product
> structure will never get confused when you refer to customer.name or
> product.name.
> And that you can go into the customer structure later and add a .phone field
> without
> having to renumber all the following fields in that structure. In most other
> languages
> this is a standard, in fact an  *expected*  feature. One which simplifies,
> not complicates,
> the language. One which reduces, not increases, errors.

And makes local names easier, like the following mirc one-liner, which wipes the
contents of all the vars i am about to use:
 unset %reading_*
even tho i mirc does not support structures, the naming conventions lend
themselves
to the use of totally free-form "structures". Even tho the names are all one
dimension,
doing this:
if ( %opdeop. [ $+ [ %net ] $+ . $+ [ # ] ] == yes ) etc
in Eu would be fantastic for the Eu database, making it possible to access 
fields/rows/columns (data.{%net,channel}.indexnumber) by names that the 
programmer had not even thought about. 

Kat

14. Re: Fair Criticism

• Posted by David Cuny <dcuny at LANSET.COM> Aug 12, 2001
• 527 views

Chris wrote:

> Unless Euphoria is promoted,

I'm not sure if I understand what you wrote. Do you mean:

   Euphoria isn't being promoted?

If that's the case, it's simply not true. Robert spends plenty of time
promoting Euphoria. Perhaps you instead meant:

   You could do a better job promoting Euphoria.

Which is simply insulting.


> and members begin to write more programs,

Again, I'm confused by this. Did you really mean:

   Members aren't writing enough programs.

Which simply isn't true, or:

   Members aren't writing good programs.

Which, again, is simply insulting.


> Euphoria well never reach the status we all would
> like to see, unless more contributions are made.

Huh? What is this 'status' that we desperately wish Euphoria to attain?

-- David Cuny

16. Re: Fair Criticism

• Posted by rforno at tutopia.com Aug 12, 2001
• 518 views

Maybe I am an old fashioned programmer, but I feel at ease with Euphoria.
Its debugging facilities are only surpased by APL of all languages I know.
Not long ago I started to program in an OO language (Java). While many
people think this kind of language is "the future", I don't agree. I find
Java cumbersome, difficult to program and debug, really a pain in the neck.
----- Original Message -----
From: <gertie at ad-tek.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Fair Criticism


>
> On 10 Aug 2001, at 18:17, Robert Craig wrote:
>
> > >
> > > I'd never even heard of it before, and I'm a language slut.  This
> > > suggests to me that the user community is very small, and when the
> > > author gets tired of it the language will die.
> >
> > The user community has been growing steadily for years.
> > This mailing list has gone from 250 to 360 in the past 6 months.
> > I started designing Euphoria 12 years ago, and I'm working on it
> > full-time. The source will soon be (mostly) available.
> >
> > > It's commercial and proprietary (it's cheap, but it still costs),
> > > which IMO are acceptable for applications but extraordinarily bad
ideas
> > > for basic infrastructure like a programming language.
> >
> > Microsoft seems to be doing pretty well peddling C++, Visual Basic,
> > various operating systems, and other "basic infrastructure".
> >
> > If a programmer can improve his productivity by 10%,
> > why on earth would he not spend $39, or even $3900 in doing so?
>
> Well, for some people who make $39 a month, $3900 would seem like a lot of
money,
> it sure seems like a lot to me.
>
> > > It's not object-oriented, and doesn't even have structs.  This is
> > > the real show-stopper.  Without this capability, it's going to be a
> > > nightmare to write code using complex data structures.
> >
> > My worst nightmares by far have occurred while programming
> > complex, dynamic, flexible data structures in C/C++, mallocing and
> > freeing every step of the way with tremendous opportunities
> > for hideous bugs. In Euphoria it's a breeze.
>
> I *much* prefer the Eu way of free-form structures. This leaves it up to
me what i want
> to put in "fields". In Pascal, i used a lot of variant fields, and was
constrained by the
> rule of only one variant and it had to be at the end of a pre-declared
fixed record. What
> would make arrays/records as complex as C++ or pascal, but far more
versatile, will
> be if/when Rob (or someone) adds the runtime var naming, like mirc.
>
> Kat
>
>
>
>
>

18. Re: Fair Criticism

• Posted by Chris Bensler <bensler at telus.net> Aug 12, 2001
• 562 views

<SNIP>
As for my comment about members writing more programs, how is that
insulting? I never said the programs in the archive aren't any good,
I said there should be more members contributing.
<SNIP>

Personally, I think it's a motivational factor. I think the micro-economy is
a  good idea, but it's not very effective.
Sure, there are those who have enough experience to write useful apps and
libraries, but most are just learning, and exploring the world of
programming still.
It's not worth my while to code for the archives. Most often than not (with
libraries anyways), I begin developing something. And before I finish,
Someone else has beaten me to it. So my time is wasted.
I do try to contribute when I think I've written something that might be
useful. But for me it's not very often.  
I find I usually end up writing my own libraries, if only because I find it
easier than trying to decipher someone elses code.
That, and the learning experience, as well as the fact that I will KNOW
exactly what the library/app does, and how it works.

I think maybe RDS should consider implementing a different mechanism for
promotion of archive contributions.
MTS suggested having a sort poll, where ppl could suggest an idea for needed
or useful  apps / libs. Then others could use their RDS bucks to vote for an
app that they think would be a worthy contribution to the site. This would
provide ppl with project ideas, as well as the added motivation of the
already existing fund for that project.
The main pitfall of that idea as well as the micro-economy is that most who
would be devloping the apps, would be the more experienced ppl who most
likely already have a registered copy of EU, if not the entire EU package.
Even without the micro-economy incentive. I still think it would be a good
idea, just have a voting poll. People could look to the list of prospective
projects for ideas and see which ones are most in demand.
I think we would see the alot more development of useful applications and
libraries.

About euphoria promotion. Just an observation.
While searching for coding languages, most every hit for euphoria,
emphasizes the use of euphoria for game programming.
Not much other than that. Unless you are simply browsing to find a new
language to try, in which case, you probably aren't looking for a commercial
development language.
That's great and all, it's what led me to find EU, but if it's ever to go
mainstream or even remotely be popular, EU will have to cater to developers,
not just hobbyists.
I don't think any developer is going to be searching the internet for a game
programming language.
RDS needs to make EU known.
Is there general language obfucated code contest? That might be a start.
RDS could also consider commissioning some people to develop a high end
commercial application using Eu and put it on the retail market. I think EU
is capable enough.
I think that is one of the most overwhelming factors of Eu's success.
Nobody else has done it. Why would others think that they can?


Chris

20. Re: Fair Criticism

• Posted by Irv Mullins <irvm at ellijay.com> Aug 12, 2001
• 534 views

From: Chris Bensler <bensler at telus.net>

> Is there general language obfucated code contest? That might be a start.

There is, but Euphoria isn't a good language for obfuscating code.
Besides, Perl programs win every time, without even trying to obfuscate.
Better would be for someone (several of us, actually) to submit Euphoria
versions of the Great Computer Shootout tests:

http://www.bagley.org/~doug/shootout/

> RDS could also consider commissioning some people to develop a high end
> commercial application using Eu and put it on the retail market. I think
EU
> is capable enough.
> I think that is one of the most overwhelming factors of Eu's success.
> Nobody else has done it. Why would others think that they can?

Good point. The application would have to be chosen carefully, however.
Something that didn't need threads, and that didn't need internet
connectivity,
and that didn't need to share data with other Windows programs, for example.

So what would that high-end commercial application be? Any suggestions?

Regards,
Irv

22. Re: Fair Criticism

• Posted by Chris Bensler <bensler at telus.net> Aug 12, 2001
• 514 views

What about type casting?
Of course it CAN be implemented, calling type checks all the time. But they
would soon drown out the productive code.
How about generating a structure skeleton when the structure contains other
structures?
Structures can be implemented, but it's certainly not appealing.

what's easier and more readable..
A) structure:
        structure Date
                integer Day,
                integer Month,
                integer Year
        end structure

        structure LastPurchase
                Date PurchaseDate,
                sequence Product,
                sequence StoreLocation
        end structure

        structure customer
                sequence FirstName,
                sequence Lastname,
                integer Age,
                integer Gender,
                LastPurchase Data,
        end structure

        Customer Account896
        Account896 ={"John","Doe",35,'m',{"october 22,
2000",{"Panasonic","VCR","67994-8769-338-33449"},{"Castlerock","New
England"}}}
        -- ERROR, typecheck failure, invalid structure
        -- Expected sequence of length(3) for PurchaseDate

or B)
        integer enum_count
        enum_count=0

        function enum()
            return enum_count+=1
        end function

        constant Day=enum(),
                      Month=enum(),
                      Year=enum()
        enum_count=0
        type Date(object D)
             if not sequence(Date) or length(Date)!=3 then return 0 end if
             if not integer(D[Day]) then return 0 end if
             if not integer(D[Month]) then return 0 end if
             if not integer(D[Year]) then return 0 end if
             return 1
        end type

        constant DatePurchased=enum(),
                      Product=enum(),
                      StoreLocation=enum()
        enum_count=0
        type LastPurchase(object L)
                if not sequence(L) or length(L)!=3 then return 0 end if
                if not Date(L[DatePurchased]) then return 0 end if
                if not sequence(L[Product]) or length(L[2])!=3 then return 0
end if
                for i = 1 to 3 do
                    if not sequence(L[2][i]) then return 0 end if
                end for
                if not sequence(L[StoreLocation]) or length(L[3])!=2 then
return 0 end if
                for i = 1 to 2 do
                    if not sequence(L[3][i]) then return 0 end if
                end for
                return 1
        end type

        constant FirstName=enum(),
                      LastName=enum(),
                      Age=enum(),
                      Gender=enum(),
                      Data=enum()
        enum_count=0
        type Customer(object C)
                if not sequence(C) or length(C)!=5 then return 0 end if
                if not sequence(C[FirstName]) then return 0 end if
                if not sequence(C[LastName]) then return 0 end if
                if not integer(C[Age]) then return 0 end if
                if not integer(C[Gender]) then return 0 end if
                if not LastPurchase(C[Data]) then return 0 end if
        end type
        Customer Account896
        Account896 ={"John","Doe",35,'m',{"october 22,
2000",{"Panasonic","VCR","67994-8769-338-33449"},{"Castlerock","New
England"}}}
        -- ERROR, typecheck failure, invalid structure
        -- Expected sequence of length(3) for PurchaseDate

PHEW!!!

Chris

----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, August 12, 2001 4:40 AM
Subject: Re: Fair Criticism


>
> >You know very well that a Pascal program which has both a customer
> >structure
> >and a product
> >structure will never get confused when you refer to customer.name or
> >product.name.
> >And that you can go into the customer structure later and add a .phone
> >field
> >without
> >having to renumber all the following fields in that structure. In most
> >other
> >languages
> >this is a standard, in fact an  *expected*  feature. One which
simplifies,
> >not complicates,
> >the language. One which reduces, not increases, errors.
>
>
>
> At this point it seems to me that you're not really programming in EU. You
> are
> thinking in another launguage and translating. Perhaps an OO style method
of
> referencing elements might make some people feel more comfortable ... even
> potential
> new users. Could be a good thing, but it does NOT add any functionallity.
It
> dosn't
> DO anything apart from better suit some people's programming styles. If
you
> declare
> constants dynamically (for elements of a structure) then use them, why do
> you need
> to renumber anything?
>
>
>
> type string(sequence s)
>     for x=1 to length(s) do
>         if sequence(s[x]) then
>             return 0
>         end if
>     end for
>     return 1
> end type
>
>
> type record(sequence s)
>     if not string(s[fFirstName]) then return 0 end if
>     if not string(s[fLastName]) then return 0 end if
>     if not string(s[fPhone]) then return 0 end if
>     if not pos_int(s[fShoesize]) then return 0 end if
>     -- ....  etc ..
>     return 1
> end type
>
>
>
> integer  fEnum_count
> fEnum_count=0
>
> function fEnum()
>     fEnum_count+=1
>     return fEnum_count
> end function
>
>
> constant
>          fFirstName      =fEnum(),
>          fLastName       =fEnum(),
>          fPhone          =fEnum(),
>
>          --........ add as many as u like here
>
>          fShoeSize       =fEnum(),
>          NUM_FIELDS      =fEnum_count(),
>
>
> .... i could go on but by now you should see where I'm coming from.
>
> If you add or remove something, nothing needs to be renumbered,
> it's all created dynamically and the actual order of fields is
> irrellivant. i dont see that much diffrence between record.fFirstName
> and record[fFirstName] The concept can be easily extended beyond this
> quick example to include complex data structures. If I were doing a
> customer structure and a product structure they would be seperate
> objects in seperate include files, including the routines and controls
> to access them.
>
> Immediately I hear you say that this is confusing and error prone and
> that you dont like the font color. To this I reply that every system is
> more confusing and error prone than the one you're used to, and that
> font color is just a matter of taste.
>
> This is the system I use, often without even bothering with the type
> statements, I'm used to it. I dont find it confusing. I find it VERY
> easy to debug if I make a mistake, or to alter at a later date.
>
> I think one point in favor of Rob adding dot notation or the like would
> be that it might make EU more attractive or friendly looking to potential
> new users. I reject the concept that because EU is not like
> Pascal it needs 'fixing'.
>
> Graeme.
>
>
>
>
>

24. Re: Fair Criticism

• Posted by Irv Mullins <irvm at ellijay.com> Aug 12, 2001
• 513 views

From: David Cuny <dcuny at LANSET.COM>

> Chris wrote:
>
> > Unless Euphoria is promoted,
>
> I'm not sure if I understand what you wrote. Do you mean:
>
>    Euphoria isn't being promoted?
>
> If that's the case, it's simply not true. Robert spends plenty of time
> promoting Euphoria. Perhaps you instead meant:
>
>    You could do a better job promoting Euphoria.
>
> Which is simply insulting.

I see no reason why that would be insulting. Rob, as far as I know, does not
have his
degree in marketing, nor has he shown any great natural talent in that area.
Nor have I.
So what? That's why there are ad agencies.  If someone who makes their
living
promoting products were to come to me and tell me I could do a better job at
promoting my business, I would certainly listen. Might even hire them, if
they could
convince me that the results would be worth the cost.

> > and members begin to write more programs,
>
> Again, I'm confused by this. Did you really mean:
>
>    Members aren't writing enough programs.
>
> Which simply isn't true, or:
>
>    Members aren't writing good programs.
>
> Which, again, is simply insulting.

Please re-read the original post:

"Since the beginning of this month, I know of 3 potential developers
that have been sitting quietly watching the forum and searching the
archive.
Each one of them has had the same concerns and questions:

1 Why are there few libraries and programs?
2 Why hasn't the author written more programs with his own language?
3 Am I insane for developing a program with a "hobbyist language"? "

So he's not insulting anyone. These are questions prospective users asked.
Quite reasonable questions for someone to ask, if they're thinking of using
some new product. Very much the same questions you see on the newsgroups
when someone mentions Euphoria.

My answers would be:

1. There *are* lots of programs. Not nearly as many as you will find for
Perl, C,
    Pascal, Delphi, or BASIC, but still lots. There are fewer lilbraries,
and documentation,
    as always, could be better.

2. Now that is a very good question. I can't answer that one.

3. Probably, but so what? Many people over the years have developed (and
even sold)
    programs in BASIC, which is the hobby language to beat all  hobby
languages.

> > Euphoria well never reach the status we all would
> > like to see, unless more contributions are made.
>
> Huh? What is this 'status' that we desperately wish Euphoria to attain?

I, for one, would like to be able to use Euphoria for more of the things
people pay me to
do. I would like to see lots of programmers using it, so there would be more
useful libraries.
I would like to see magazine articles about Euphoria. I would like it to be
at least as well-known as Python. If you are talking with a group of
programmers, and say you wrote
a program in Python, they generally don't laugh.  They may not like, use, or
understand
Python, but at least it is widely accepted as a 'usable language'.

Regards,
Irv

26. Re: Fair Criticism

• Posted by Irv Mullins <irvm at ellijay.com> Aug 12, 2001
• 527 views

----- Original Message -----
From: C. K. Lester <cklester at yahoo.com>
Subject: RE: Fair Criticism


>
> > There is, but Euphoria isn't a good language for obfuscating code.
> > Besides, Perl programs win every time, without even trying to obfuscate.
> > Better would be for someone (several of us, actually) to submit Euphoria
> > versions of the Great Computer Shootout tests:
> >
> > http://www.bagley.org/~doug/shootout/
>
> I think RDS should post code to this site and let us know about it.

Actually, upon reading the FAQ at that site, I think Euphoria isn't in the
running. First of all, Doug shows a strong preference for languages which
are  free (ok, pdEu is free) and which come with source code, (someday,
partly),
and have a "measurable user base".

But wait, there's more:

--quote
The language should have most of the following desireable features:

Ability to read/write 4K buffers, bypassing standard
     -- yes
Process control (i.e.
                -- no
Exceptions.                                                                 
                         -- no
Regular Expressions (preferably Perl
             -- no
Linux Kernel
         - - no
Internet
         -- no
Objects.                                                                    
                            -- no
Ability to print out its own version
        -- kinda
A module system, and separate compilation of modules (if compiled)      --
yes.

I may make some exceptions to the above, but only if I feel like it.
-- end quote

However, there's nothing stopping us from downloading his test suite,
writing
Euphoria versions, and running the tests ourselves. He encourages that.
If we were to be able to prove Euphoria to be outstandingly better than
most everything else, he might make that exception, and add Euphoria to the
list.

Regards,
Irv

28. Re: Fair Criticism

• Posted by president at insight-concepts.com Aug 12, 2001
• 535 views

30. Re: Fair Criticism

• Posted by president at insight-concepts.com Aug 12, 2001
• 519 views

32. Re: Fair Criticism

• Posted by David Cuny <dcuny at LANSET.COM> Aug 12, 2001
• 515 views

Chris wrote:

> Hold on David. I did not insult Robert or the Forum.

Perhaps you meant to write:

  I did not intend to insult Robert or the Forum.


> How is my comment about promoting Euphoria more
> or any less insulting, than when a  Euphoria member
> points out what Euphoria is not and what it will never be.


You may have *intended* to write that Euphoria is being properly promoted,
or effectively promoted. But you wrote - without qualification - that
Euphoria was *not* being promoted:

>> Unless Euphoria is promoted...


> If Robert decides to throw in the towel
> tomorrow, where will Euphoria be then?

Robert has already said that he's making the source available for people to
modify, change and market. I think it's fair to say that if Robert plans on
throwing in the towel, he'll lift the current restrictions of not allowing
shrouding, and so on.


> I never said the programs in the archive
> aren't any good, I said there should be
> more members contributing.

Why much Euphoria be 'appreciated' by such a wide audience?


> 1 Why are there few libraries and programs?

Do you mean 'so few libraries usable by your developers'?


> 2 Why hasn't the author written more programs
> with his own language?

Perhaps because he's a compiler writer, and not an application writer? Or
perhaps because he doesn't have time? How this is a gauge of Euphoria's
fitness is beyond me.


> 3 Am I insane for developing a program with a "hobbyist language"?

Euphoria is indeed a "hobbyist language". Why this is a bad thing is unclear
to me.

-- David Cuny

34. Re: Fair Criticism

• Posted by Dan Moyer <DANIELMOYER at prodigy.net> Aug 12, 2001
• 525 views

Chris,

David almost certainly meant:

Why must Euphoria be 'appreciated' by such a wide audience?

David wrote:
>Why much Euphoria be 'appreciated' by such a wide audience?

Chris responded:
Can someone help me with this one.^  I do not understand your
question.

Dan Moyer

36. Re: Fair Criticism

• Posted by Robert Craig <rds at RapidEuphoria.com> Aug 12, 2001
• 531 views

Irv Mullins writes:
> The fact that Rob had trouble with C structures 
> is irrelevant to Euphoria, except in that
> it must have tainted his view of how useful structures can be. 

I was actually referring to "data structures" in general in C, 
not "structures" per se. It's the mallocing and freeing that drives
me nuts. "structures" are a good feature of C, Pascal etc.,
but I think they'd be bad news for Euphoria.
If you look at the C source code for Euphoria (as you'll soon
be able to) you'll find lots of C structures, and even (horrors!) 
a few gotos.

I agree that the current way in Euphoria of simulating
structures is not as good as the real thing. It does
open up possibilities for errors.

However, think a bit further.
Suppose structures were added to Euphoria.
The elegant little language formerly based on just 2 data
types (atoms and sequences) would now be based
on 3 (atoms, sequences, and structures).

Oh, but isn't a structure just a form of sequence?
Well... can you slice a structure:  x[3..5]? If you can then
you are admitting that fields can also be 
referenced by number, which defeats your 
original intention. Can you concatenate two structures? x & y
What if x and y share some of the same field names?
Can you append something to a structure?
What do you get? And of course you can't subscript
a structure with a number. So structures would
not be a mere tweak of sequences. They would 
have to be treated as a distinct data type.

For structures to have any real usefulness 
you would have to allow sequences 
of structures, not just isolated individual
structures declared for a single variable.

So now the elements of a sequence can be
atoms, sequences or structures. And the fields
of a structure can be atoms, sequences and structures.
Fine. But then a host of complicated questions arise. 
Every library routine has to be reconsidered and the 
documentation and implementation have to be updated. 
For each argument of each routine we must ask 
"What if a structure is passed in here?" Does it
make any sense? Is it the same as passing a sequence?
Is it an error? Can we force it to make sense?

Then there's the implementation.
At every place in the interpreter or translator
where we deal with sequences (that's almost everywhere)
we must now augment the code to allow for 
the possibility of structures. That's extra if-statements
being executed everywhere, and a combinatorial growth
in cases, e.g. using + as one example: 
Now:
atom+atom, 
atom+sequence, 
sequence+atom,
sequence+sequence, 

New cases to code:
atom+structure, 
structure+atom,
structure+structure, 
structure+sequence
sequence+structure

Imagine the code bloat in the interpreter,
and the code bloat in the translated C code.

The possibilities for errors in the interpreter or translator
will dwarf whatever possibilities there are now when using 
simulated structures. But that's not the worst part.
The worst part is that Euphoria's simplicity will
have been compromised severely. People will have to
remember dumb things like "can you add two structures?",
"can you compare two structures with > what about = ?", 
"what are the scope rules for field names?" etc. etc.
In an effort to make one aspect of coding somewhat 
more robust, you will have seriously degraded the language 
as a whole, both the ease of understanding it, and the 
ease of implementing and maintaining it in the future.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

38. Re: Fair Criticism

• Posted by David Cuny <dcuny at LANSET.COM> Aug 12, 2001
• 522 views

Chris wrote:

> Perhaps you need to read what I write exactly,
> instead of assuming or being presumptuous.

I assumed that you meant that Euphoria was not being promoted. I guess it
was presumtious of me. In the past, people have made the assertion that
Euphoria is not being promoted. When you wrote:

>>> Unless Euphoria is promoted, and members begin to
>>> write more programs, ...

I had assumed that you were making a similar statement. Thank you for
correcting me.


> In my "opinion" Euphoria's
> promotion is null.

Yes, that clears things up. This is clearly different than Euphoria not
being promoted.


> And what gives you the qualifications to say
> Euphoria is being promoted properly or efficiently?

Perhaps you're a bit confused; when I wrote:

>> You may have *intended* to write that
>> Euphoria is [not] being properly promoted,
>> or effectively promoted.

I left the 'not' out. My mistake; the sentance makes no sense without it.


> If a developer does not promote his own language
> with example applications, and/or real world
> applications, how then can you convince a 3rd
> party that you have a great language.

Yes, I see your point. It's a pity there's no other resource they could go
to, such as an archive of submission by Euphoria coders. Maybe Robert will
consider adding one, after he starts promoting Euphoria.


> If you took offense to my comments, that is a
> personal issue you must deal with. My opinion is
> my opinion, as yours is yours.

Yes, I think we can agree that this "null promotion" is your opinion, and
not mine.


> All this energy you are excreting to make your
> point, why not direct it to a more constructive task,
> like coding a new library. :)

You are right, this excreting has gone on long enough. As you say, this
isn't a constructive use of time. I should be working on something you can
use in your products instead. Isn't this why we all decided to use Euphoria?

-- David Cuny

40. Re: Fair Criticism

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 12, 2001
• 528 views

Hi Travis,

OK, OK  but remember Derec's one favorite dictum, 
really great saying.

In latinic Russian this is " Tishe edesh',  dal'she budesh' "
simple, no ?  

Regards,
Igor Kachan
kinz at peterlink.ru
----------
> 
> Howdy y'all!
> 
> 8/12/2001 8:48:27 PM, Robert Craig <rds at RapidEuphoria.com> wrote:
> 
> >If you look at the C source code for Euphoria (as you'll soon
> >be able to) you'll find lots of C structures, and even (horrors!) 
> >a few gotos.
> 
> I believe it is entirely possible Kat has just found a mouse.  
> 
> Have a nice day!
> Run Mr. Craig.  Fast!
> 
> Travis Beaty
>

42. Re: Fair Criticism

• Posted by president at insight-concepts.com Aug 13, 2001
• 515 views

44. Re: Fair Criticism

• Posted by Chris Bensler <bensler at telus.net> Aug 13, 2001
• 541 views

what about nesting?
gotos aren't very useful without nesting.

Chris


Hello Kat,

> Îò: Kat <gertie at PELL.NET>
> Êîìó: EUforum <EUforum at topica.com>
> Òåìà: Re: Fair Criticism
> Äàòà: ïîíåäåëüíèê, Àâãóñò 13, 2001 08:36
>
>
> On 12 Aug 2001, at 21:06, Travis Beaty wrote:
>
> >
> > Howdy y'all!
> >
> > 8/12/2001 8:48:27 PM, Robert Craig <rds at RapidEuphoria.com> wrote:
> >
> > >If you look at the C source code for Euphoria (as you'll soon
> > >be able to) you'll find lots of C structures, and even (horrors!)
> > >a few gotos.
> >
> > I believe it is entirely possible Kat has just found a mouse.  
> >
> > Have a nice day!
> > Run Mr. Craig.  Fast!
>
> Kat, crouched............

..... attention .....

shhhhhh... see goto in Euphoria:

---file label1.e
puts(1, "label1 done\n")
---end of file

---proggy goto.ex
function goto(sequence Label)
 return system_exec("ex.exe " & Label, 2)
end function

include label1.e

for i=1 to 3 do
 if goto("label1.e") then exit end if
end for
---end of file


Same about gosub() and so on, idea is clear,
maybe, this *new* is just well forgotten
*old*, I don't know, but if you use your
RAMdrive for 'labels' and for a
*service copy* of ex.exe, this method must
be rapid too.

This is EUPHORIA language, not a pain
in the whole organism and constitution.



Regards,
Igor Kachan
kinz at peterlink.ru

46. Re: Fair Criticism

• Posted by Irv Mullins <irvm at ellijay.com> Aug 13, 2001
• 529 views

On Sunday 12 August 2001 21:48, Robert Craig wrote:

<snip the Kat bait>
>
> I agree that the current way in Euphoria of simulating
> structures is not as good as the real thing. It does
> open up possibilities for errors.

Then shouldn't it be fixed?

> However, think a bit further.
> Suppose structures were added to Euphoria.
> The elegant little language formerly based on just 2 data
> types (atoms and sequences) would now be based
> on 3 (atoms, sequences, and structures).

Horrors. Let's make it even more elegant, by removing the sequence.
And what about integers, aren't they a data type?  Get rid of them too.

> Oh, but isn't a structure just a form of sequence?
> Well... can you slice a structure:  x[3..5]? If you can then
> you are admitting that fields can also be
> referenced by number, which defeats your
> original intention. 

How does that defeat my original intention? Being able to refer 
to elements of a sequence by a meaningful name doesn't mean 
that they can't still be referenced by number. The third item in a list, 
whether it has a name or not, is still the third item in the list, isn't it?

Can you concatenate two structures? x & y

Why not? In most languages, a structure can be made up of other 
structures.

> What if x and y share some of the same field names?

They can in C, Pascal, every other language I can think of.... 
doesn't seem to cause any problem.

> Can you append something to a structure?
> What do you get? 

A structure with one additional field (element - whatever) which hasn't  
been given a name.  How is this different from appending something 
to a sequence, when you haven't created a constant to point there?

> And of course you can't subscript
> a structure with a number.

Sez who?  

> So structures would
> not be a mere tweak of sequences. They would
> have to be treated as a distinct data type.

If you want typechecking of the elements, yes.
Otherwise, nothing you have mentioned so far requires anything 
more than a little syntactic sugar.

> For structures to have any real usefulness
> you would have to allow sequences
> of structures, not just isolated individual
> structures declared for a single variable.
>
> So now the elements of a sequence can be
> atoms, sequences or structures. And the fields
> of a structure can be atoms, sequences and structures.
> Fine. But then a host of complicated questions arise.
> Every library routine has to be reconsidered and the
> documentation and implementation have to be updated.
> For each argument of each routine we must ask
> "What if a structure is passed in here?" Does it
> make any sense? Is it the same as passing a sequence?
> Is it an error? Can we force it to make sense?

> Then there's the implementation.
> At every place in the interpreter or translator
> where we deal with sequences (that's almost everywhere)
> we must now augment the code to allow for
> the possibility of structures. That's extra if-statements
> being executed everywhere, and a combinatorial growth
> in cases, e.g. using + as one example:
> Now:
> atom+atom,
> atom+sequence,
> sequence+atom,
> sequence+sequence,
>
> New cases to code:
> atom+structure,
> structure+atom,
> structure+structure,
> structure+sequence
> sequence+structure
>
> Imagine the code bloat in the interpreter,
> and the code bloat in the translated C code.

> The possibilities for errors in the interpreter or translator
> will dwarf whatever possibilities there are now when using
> simulated structures. But that's not the worst part.
> The worst part is that Euphoria's simplicity will
> have been compromised severely. People will have to
> remember dumb things like "can you add two structures?",

Can you add two sequences? The answer is "maybe".
Where's the difference?

> "can you compare two structures with > what about = ?",

I don't know - can you compare two sequences with =?

> "what are the scope rules for field names?" etc. etc.
> In an effort to make one aspect of coding somewhat
> more robust, you will have seriously degraded the language
> as a whole, both the ease of understanding it, and the
> ease of implementing and maintaining it in the future.

Ok, Rob, i can see that this would be too difficult.
Forget it, I won't mention the subject again.  

Regards,
Irv

TP, circa 1984,  38.6 k of bloat, with built in editor, BCD math and - 
oops, sorry, I promised not to mention "those things" anymore ;)