1. RE: Eu's poor design
Hello Andreas,
Although I have decided against Euphoria (currently) as a viable
option for professional development, I have some remarks to make
here.....
Andreas Rumpf wrote:
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
I do agree that it is not there yet, but for different reasons.
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
OK, but.....
> So for real applications I would use global variables all over the place
>
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
If that is a great aprovement over "call by reference" then why
do you need "call by reference. Your stament is confusing.
And the lack of such an option doesn't mean you can't write
serious or professional applications with it.
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly.
Maybe, but.....
> Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
Where is it stated that Euphoria is a functional language.
And if it is not a functional language (which I think it isn't)
then why would Rob have to "understand functional programming
properly" ?? I have no idea why you are stating this.
Besides (and again) this has nothing to do with the usability of
a language for serious tasks. Most used languages are NOT
functional languages. C and C++, Python, Perl, Java, etc. are
NOT functional languages. Prolog, Haskell, Erlang, Clean and the
likes are functional languages but apart from Erlang, most are
used in research and not in enterprise applications.
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time.
This has been discussed before. Every good programmers editor
handles this for you. Btw, if you are on windows I recommend
you take a look at PSPad. I use it currently for my Euphoria
coding and it's the closest to a real IDE.
> Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
>
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
Why would # be better. Just because other languages use it ??
There are other languages that use -- also. Besides, tmo -- gives
much better readability as it stands out much better. Take a look
at any big chunk of PERL code and you know what I mean.
But more important, what does this have to do with using a language
for serious tasks. I've never heard of any case where the token
used for comments had any influence on the resulting quality of
the application.
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
I think it's stated clearly in the Euphoria docs that they are
available for those that want to use them. I also recall that it
is adviced in the docs to STAY AWAY from those statements as much
as possible.
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
Yes, and that way you are forced to actually *learn* the language.
Oh, and using PSPad, I just add function names to the language
definition for the highlighter and it shows me when I'm forgetting
the correct case.
But again this does NOT impact the quality of the programs that
can be written with the language.
> I used to use hashing a lot. Guess what, in Euphoria most hash functions
>
> can't be implemented (or only with poor performance!), because integers
> don't wrap around but are converted to floating point when they get to
> big!
Wrapping integers can be a big PITA in several other applications,
especially business oriented calculations.
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
Euphoria as a language is very well suited for serious large
projects. The points you make here are of non importance when
a company (like my own) is deciding on a development platform.
There are other more important issues that prevent the use of
Eu in serious (commercial) projects and it's mainly about the
lack of stable libraries for business applications. Stuff like
GUI handling and database access is available but far from the
level of stability and functionality that I need to deliver for
contract work for my clients. But the points you mention are of
no influence on the functionality and stability of a business
application.
Hans Peter Willems
2. RE: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- Peter Willems <peter at integratedmoves.com> wrote:
> There are other more important issues that
> prevent the use of
> Eu in serious (commercial) projects and it's
> mainly about the
> lack of stable libraries for business
> applications. Stuff like
> GUI handling and database access is available but
> far from the
> level of stability and functionality that I need
> to deliver for
> contract work for my clients.
Windows is also far from the level of stability and
functionality that I need for my clients -
but I haven't let that stop me :)
Irv
3. RE: Eu's poor design
- Posted by euman at bellsouth.net
Aug 16, 2003
On 16 Aug 2003 at 7:12, eugtk at yahoo.com wrote:
> Windows is also far from the level of stability and
> functionality that I need for my clients -
> but I haven't let that stop me :)
>
> Irv
Someone mentioned owning a software company earlier.
They stated that they would use Java from now on. Does
this person know that 95%+ users/companies use MS Win
and have they heard that MS pulled their VM that would
support Java based Web apps. Hint to this person, 5yrs from
now everyone will lease their application online instead of
owning CD's or downloading actual programs. I see a time when
the O/S is the only piece of software on your machine and
if Mr Bill G has his way as Im sure he will, this will happen.
Look at McAfee and Norton with their Virus scanning ActiveX
and tell me this isnt already starting to take place.
Companies are tired of loosing money to Hacks/Cracks and Cerialz.
You might want to think about this internet lease option and forget
about a language that Microsoft is trying very hard to bury.
Hehehe Irv here we go again with this....
Windows XP Pro SP2 is far more stable (for me) than is RHL9
Euman
4. RE: Eu's poor design
eugtk at yahoo.com wrote:
> --- Peter Willems <peter at integratedmoves.com> wrote:
>
> > There are other more important issues that
> > prevent the use of
> > Eu in serious (commercial) projects and it's
> > mainly about the
> > lack of stable libraries for business
> > applications. Stuff like
> > GUI handling and database access is available but
> > far from the
> > level of stability and functionality that I need
> > to deliver for
> > contract work for my clients.
>
> Windows is also far from the level of stability and
> functionality that I need for my clients -
> but I haven't let that stop me :)
Yep, you are right there. But my clients are running Windows
because they choose to and if their are stability issues, they
wont shove it my way. But when I do a bid for contracting work,
my clients expect me to deliver a stable product and if that
product doesn't perform in itself they will hold my company
liable.
As a sidemark, we have a related policy in my company about how
we develop software: we do not use any components outside of the
development platform that need to be registered to the operating
system or are a part of that operating system. So we don't use the
windows registry (we have developed our own database for that),
we don't use ActiveX, OCX, and other OS-dependant components and
we dont put stuff into the windows OS directory (not even an INI-
file). In that way we make sure that the stability of the OS has
no effect on the stability of our application and the other way
around that our application will not and can not interfere with
the stability of the OS. This has worked VERY good for us 
Hans Peter Willems
5. RE: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- euman at bellsouth.net wrote:
Someone mentioned owning a software company earlier.
...
Hint to this person,
5yrs from
now everyone will lease their application online
instead of
owning CD's or downloading actual programs. I see a
time when
the O/S is the only piece of software on your
machine and
if Mr Bill G has his way as Im sure he will, this
will happen.
He won't. For one very simple reason:
Running business apps that reside on a computer
owned by Bill means giving Bill access to your
customer
database, their credit card numbers, your accounts
payable, accounts receivable, etc. etc.
Just what sane business person is going to send
this vital information to a company which has proven
time and again that they can't be trusted? Not even to
obey federal laws, much less keep their contractual
"promises".
(Like, for example, the inevitable "guarantee" that
all this critical data will be "encrypted" so that "no
one at Microsoft can see it".
Yea, right!
Irv
--
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. RE: Eu's poor design
Andreas Rumpf wrote:
>
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
Hmmm... I won't reiterate what others have already pointed out in their
replies, but let's just say your comments are ill-informed enough and
short-sighted enough for me to think that is you rather than Euphoria
that is rather useless for programming real applications. You obviously
have not taken a very close look at Euphoria.
If you want to say that Euphoria is not perfect, then I'll agree. (What
language is perfect?) If you want to say that Euphoria isn't fast
enough for every type of application, then I'll agree (but for most
applications it is very fast). If you want to say that Euphoria isn't
well suited YET to complex GUI programs under Windows, I'll agree. (But
we're getting there.)
I think if you work with Euphoria for a long time (as I have now) you
begin to see a few things that maybe strike you as ad-hocism and could
have been thought out better, and it certainly could use a few new
features. But it has a great core, wonderfully executed for what it is.
The Euphoria interpreter is one of the most stable pieces of software
I've ever worked with.
7. RE: Eu's poor design
eugtk at yahoo.com wrote:
>
>
> --- Andreas Rumpf <pfropfen at gmx.net> wrote:
>
> > Lets face it, at its current state, Euphoria is
> > rather useless for
> > programming real applications, for several reasons:
>
> Clearly, it's been useless for you. I don't see your
> name in
> a search of the user-contributions page. There are
> lots
> of others there, however.
>
> Just one example: take a look at Judith's IDE. That,
> with the Win32Lib, is easier to use, and more stable,
> than my $100 copy of Delphi. I'd say that Delphi is
> a real application - so I guess Judith's is also.
Though I don't know Judith's IDE, I doubt it is better than Delphi.
My Delphi works just fine (it is stable).
>
> > It lacks:
> > - Call by reference (the most important feature I
> > want to add!):
>
> Last time this subject came up, I took a look (with
> grep) thru the million or so lines of code I have
> written in the past 20 years - in only half a dozen
> places have I used call-by-reference. And in those,
> only one would I call "essential" - meaning that
> without it, the code would have been really ugly.
I don't believe you. That would mean you have written
millions of lines in Eu (because all the other languages
have it). I doubt it.
> Would I like to have cbr? Sure.
> Is it essential? No way.
Of course it is. Why do the other languages have it?
> It ranks just above goto on my wish list (sorry, Kat)
I agree that goto is usefull...
> As for case sensitivity -
> What you learned in QBasic doesn't apply to the real
> world. (Hint: there's a reason why those 'other'
> languages are also case sensitive.)
I don't know QBasic very well. I can program in C, Pascal, Ada,
Euphoria, Java and in ML. (I study computer science.) I still prefer
case insensitive languages. The world doesn't run out of identifiers.
> Besides, anyone who can't remember how he spelled a
> variable is going to find the more complex programming
> tasks even more frustrating.
I know how I write my variables! But I don't know how YOU (if you wrote
a library for me to use) wrote them!
8. RE: Eu's poor design
euman at bellsouth.net wrote:
>
>
> On 16 Aug 2003 at 7:12, eugtk at yahoo.com wrote:
>
> > Windows is also far from the level of stability and
> > functionality that I need for my clients -
> > but I haven't let that stop me :)
> >
> > Irv
>
> Someone mentioned owning a software company earlier.
> They stated that they would use Java from now on.
That would be me 
> Does
> this person know that 95%+ users/companies use MS Win
> and have they heard that MS pulled their VM that would
> support Java based Web apps.
First of all, many companies are looking to break free from the
MS lockin. So I expect that in a few years MS won't be running
on 95% anymore. Besides, it's not important how many machines
run windows world-wide, it's more important how many of *our*
clients will be running windows.
> Hint to this person, 5yrs from
> now everyone will lease their application online instead of
> owning CD's or downloading actual programs.
I don't think that application service providers will actually
be the "next" big thing. I still haven't seen any real movements
in that area. Besides that, it is only viable for common use,
global apps. I haven't seen SAP AG announcing their ERP products
becomming available for online hosting.
What I do believe is that enterprise solutions (our playing turf)
will incorporate TCP/IP based services more transparantly over
time.
You want a glimpse of the future, take a look at Python's Zope
technology.
> I see a time when
> the O/S is the only piece of software on your machine and
> if Mr Bill G has his way as Im sure he will, this will happen.
Ah.... Mr Bill's way.... well, my clients hope they can decide
for themselves and I'm sure they will.
> Look at McAfee and Norton with their Virus scanning ActiveX
> and tell me this isnt already starting to take place.
Agreed, but as I said above, those services are usable in such
a configuration. Try launching an office suite that is hosted
somewhere.... let's say a few times a day. I don't think I have
to add anything.
Especially services that you only need in certain situations and
then need to be as up to date as possible (like anti virus stuff)
are great for external hosting.
> Companies are tired of loosing money to Hacks/Cracks and Cerialz.
> You might want to think about this internet lease option and forget
> about a language that Microsoft is trying very hard to bury.
Do you really think that MS can burry Java ????
Maybe you don't know that IBM, Oracle, Sun (duh), etc. are all
using Java as their core technology for database management
layers. Also, the major support from other database vendors is not
for native support of MS platforms, but indeed for Java and Python.
Those are completely different signals of how the future would
look.
> Hehehe Irv here we go again with this....
> Windows XP Pro SP2 is far more stable (for me) than is RHL9
As you say: for you
You forgot to add: YMMV
Hans Peter Willems
9. RE: Eu's poor design
Andreas Rumpf wrote:
> eugtk at yahoo.com wrote:
> >
> > --- Andreas Rumpf <pfropfen at gmx.net> wrote:
> >
> > > Lets face it, at its current state, Euphoria is
> > > rather useless for
> > > programming real applications, for several reasons:
> >
> > Clearly, it's been useless for you. I don't see your
> > name in
> > a search of the user-contributions page. There are
> > lots
> > of others there, however.
> >
> > Just one example: take a look at Judith's IDE. That,
> > with the Win32Lib, is easier to use, and more stable,
> > than my $100 copy of Delphi. I'd say that Delphi is
> > a real application - so I guess Judith's is also.
> Though I don't know Judith's IDE, I doubt it is better than Delphi.
> My Delphi works just fine (it is stable).
I do agree here that I wouldn't rank Judith's IDE in the same
reigns as Delphi.... yet. But it does show what can be done with
Euphoria and the win32lib and is therefor quite impresive tmo.
> > > It lacks:
> > > - Call by reference (the most important feature I
> > > want to add!):
> >
> > Last time this subject came up, I took a look (with
> > grep) thru the million or so lines of code I have
> > written in the past 20 years - in only half a dozen
> > places have I used call-by-reference. And in those,
> > only one would I call "essential" - meaning that
> > without it, the code would have been really ugly.
> I don't believe you. That would mean you have written
> millions of lines in Eu (because all the other languages
> have it). I doubt it.
Errmmm.... I must side with Irv here. I have written millions
of lines of code without the need for call-by-reference.
> > Would I like to have cbr? Sure.
> > Is it essential? No way.
> Of course it is. Why do the other languages have it?
So if other languages have certain things, then this automatically
means that it is essential ?? If so, all existing languages would
already have merged into one *all encompasing* language.
Well, THAT didn't happen so there must be a reason that certain
things are omitted in certain languages then. And I will tell you
the little secret right away: in most cases it is about
optimization. The major reason to leave certain things out is to
gain speed by doing it in a different way. Maybe you should read up
on the principle of Reduced Instruction Sets.
> > It ranks just above goto on my wish list (sorry, Kat)
> I agree that goto is usefull...
I won't go there... again
> > As for case sensitivity -
> > What you learned in QBasic doesn't apply to the real
> > world. (Hint: there's a reason why those 'other'
> > languages are also case sensitive.)
> I don't know QBasic very well. I can program in C, Pascal, Ada,
> Euphoria, Java and in ML.
And how many real-world projects did you do or participate with
these languages ?
> (I study computer science.)
That explains a lot.
> I still prefer
> case insensitive languages. The world doesn't run out of identifiers.
I prefer languages that enforce certain rules for readability
and structured programming.
> > Besides, anyone who can't remember how he spelled a
> > variable is going to find the more complex programming
> > tasks even more frustrating.
> I know how I write my variables! But I don't know how YOU (if you wrote
> a library for me to use) wrote them!
There is a simple solution for that: Documentation !
Take a look at the recent discussion here about doc-generators..
... wait a minute, you mentione Java in your list of languages:
maybe you don't know what JavaDoc is
Oh, and from another message: PITA means "Pain In The Ass".
Hans Peter Willems
10. RE: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- Peter Willems <peter at integratedmoves.com> wrote:
> I do agree here that I wouldn't rank Judith's IDE
> in the same
> reigns as Delphi.... yet. But it does show what
> can be done with
> Euphoria and the win32lib and is therefor quite
> impresive tmo.
Of course, Delphi has MUCH more functionality than Eu,
however, about 2 years ago, when I had to write a
little
specialized AR program for someone, I was able to use
Eu and an early version of the IDE without a problem.
Knowing that Delphi would be a more appropriate
language for this, I gave it a try. There were
numerous crashes and lockups - the last one deleting
all my source code. This may have affected my view of
Delphi slightly.
I delivered the Eu version, no problems in the past 2
years. My only worry is what I will do when the client
decides that he needs a multi-user version.
> And how many real-world projects did you do or
> participate with
> these languages ?
>
> > (I study computer science.)
>
> That explains a lot.
Ha! Indeed it does.
Irv
11. RE: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- Andreas Rumpf <pfropfen at gmx.net> wrote:
> I know how I write my variables! But I don't know
> how YOU (if you wrote
> a library for me to use) wrote them!
Use the source, Luke.
Irv
12. RE: Eu's poor design
Peter Willems wrote:
>
>
> Andreas Rumpf wrote:
>
> > eugtk at yahoo.com wrote:
> > >
> > > --- Andreas Rumpf <pfropfen at gmx.net> wrote:
> > >
> > > > Lets face it, at its current state, Euphoria is
> > > > rather useless for
> > > > programming real applications, for several reasons:
> > >
> > > Clearly, it's been useless for you. I don't see your
> > > name in
> > > a search of the user-contributions page. There are
> > > lots
> > > of others there, however.
> > >
> > > Just one example: take a look at Judith's IDE. That,
> > > with the Win32Lib, is easier to use, and more stable,
> > > than my $100 copy of Delphi. I'd say that Delphi is
> > > a real application - so I guess Judith's is also.
> > Though I don't know Judith's IDE, I doubt it is better than Delphi.
> > My Delphi works just fine (it is stable).
>
> I do agree here that I wouldn't rank Judith's IDE in the same
> reigns as Delphi.... yet.
And it will never reach Delphi. It compiles faster than Rob's Eu to
NATIVE optimized code!
But it does show what can be done with
> Euphoria and the win32lib and is therefor quite impresive tmo.
Yeah, you can do at lot with peek()/poke() and calling C functions...
You can also do much more in assembler and asm is not really impressive.
>
> > > > It lacks:
> > > > - Call by reference (the most important feature I
> > > > want to add!):
> > >
> > > Last time this subject came up, I took a look (with
> > > grep) thru the million or so lines of code I have
> > > written in the past 20 years - in only half a dozen
> > > places have I used call-by-reference. And in those,
> > > only one would I call "essential" - meaning that
> > > without it, the code would have been really ugly.
> > I don't believe you. That would mean you have written
> > millions of lines in Eu (because all the other languages
> > have it). I doubt it.
>
> Errmmm.... I must side with Irv here. I have written millions
> of lines of code without the need for call-by-reference.
Well, so I could say: I've written thousands of lines of code and I
didn't need any for-loops. While-loops always did the job. And I could
say "Gotos always did the job". That's no argument! Look at the library
(I think it was called "tables.e" or something like that) and how it was
a pain for the author to make the interface without cbr! (I still have
the code somewhere...)
> > > Would I like to have cbr? Sure.
> > > Is it essential? No way.
> > Of course it is. Why do the other languages have it?
>
> So if other languages have certain things, then this automatically
> means that it is essential ?? If so, all existing languages would
> already have merged into one *all encompasing* language.
No, you're wrong. That sentence isn't logical. Some features are
essential, some not. That's why there are different languages. But, call
by ref is essential. (At least as essential as for-loops!)
> Well, THAT didn't happen so there must be a reason that certain
> things are omitted in certain languages then. And I will tell you
> the little secret right away: in most cases it is about
> optimization.
Hah! Call by ref would be much more efficient!
seq = some_func()
error = seq[1]
value = seq[2]
instead of: some_func(value, error)
The Eu interpreter will certainly not optimize this one! It is much to
difficult to implement in an optimizer!
The major reason to leave certain things out is to
> gain speed by doing it in a different way. Maybe you should read up
> on the principle of Reduced Instruction Sets.
I know the principle of RISC. But Eu is a HIGH level language.
>
> > > It ranks just above goto on my wish list (sorry, Kat)
> > I agree that goto is usefull...
>
> I won't go there... again
>
> > > As for case sensitivity -
> > > What you learned in QBasic doesn't apply to the real
> > > world. (Hint: there's a reason why those 'other'
> > > languages are also case sensitive.)
> > I don't know QBasic very well. I can program in C, Pascal, Ada,
> > Euphoria, Java and in ML.
>
> And how many real-world projects did you do or participate with
> these languages ?
I wrote two quite big (10.000 loc) projects in Pascal, I am writing an
Eu translator in C (4.000 loc), I was forced to do plenty of small tasks
with Java/ML (they really suck) at university. And I played a bit with
Ada
>
> > (I study computer science.)
>
> That explains a lot.
>
> > I still prefer
> > case insensitive languages. The world doesn't run out of identifiers.
>
> I prefer languages that enforce certain rules for readability
> and structured programming.
Hah, look at C. It has case sensitiveness and does not lead to readable
code.
>
> > > Besides, anyone who can't remember how he spelled a
> > > variable is going to find the more complex programming
> > > tasks even more frustrating.
> > I know how I write my variables! But I don't know how YOU (if you wrote
> > a library for me to use) wrote them!
>
> There is a simple solution for that: Documentation !
> Take a look at the recent discussion here about doc-generators..
> ... wait a minute, you mentione Java in your list of languages:
> maybe you don't know what JavaDoc is
I know what JavaDoc is. You can always look something up, but you will
be lucky if you don't have to...
>
> Oh, and from another message: PITA means "Pain In The Ass".
>
> Hans Peter Willems
>
13. RE: Eu's poor design
Juergen Luethje wrote:
>
>
> Andreas Rumpf wrote:
>
> > Peter Willems wrote:
>
> [Call by Reference]
>
> >> And the lack of such an option doesn't mean you can't write
> >> serious or professional applications with it.
> > Well, agreed, you CAN, but you probably won't.
>
> Regardless whether you can imagine that or not --
> it already _has_ been done.
Well once there was written plenty of asm, and believe it or not, it
_has_ been done and it worked. So what? Should we program in asm any
longer? Certainly not. So where is your point? I already said that it
can be done without cbr, it is just much harder.
14. RE: Eu's poor design
Andreas Rumpf wrote:
<snip>
> > I do agree here that I wouldn't rank Judith's IDE in the same
> > reigns as Delphi.... yet.
> And it will never reach Delphi.
Now that's a very short sighted statement. Why would it not ?
Did you ever worked with Delphi 1.x ??
> It compiles faster than Rob's Eu to
> NATIVE optimized code!
It's also being developed by a team of dedicated programmers
(read: full time) that have worked on it for many years.
> But it does show what can be done with
> > Euphoria and the win32lib and is therefor quite impresive tmo.
> Yeah, you can do at lot with peek()/poke() and calling C functions...
> You can also do much more in assembler and asm is not really impressive.
You are really missing the point here. First of all, the IDE
is written mainly in pure Euphoria code. Second, there is only
one person working on it (although the project has shiftes
from one maintainer to another in the past I believe).
It has nothing to do wit assembler being impressive or not,
we are discussing Euphoria and that language IS impressive in
how much can be done with relatively little code.
> > Errmmm.... I must side with Irv here. I have written millions
> > of lines of code without the need for call-by-reference.
> Well, so I could say: I've written thousands of lines of code and I
> didn't need any for-loops. While-loops always did the job. And I could
> say "Gotos always did the job". That's no argument!
Again you seem to have no idea what we where talking about here
in the first place. We where discussing the usability of Euphoria
in *real world* applications. The millions loc that I've written
are in commercial contract projects and in THAT respect your
arguments do not hold any ground.
<snip>
> > So if other languages have certain things, then this automatically
> > means that it is essential ?? If so, all existing languages would
> > already have merged into one *all encompasing* language.
> No, you're wrong. That sentence isn't logical. Some features are
> essential, some not. That's why there are different languages.
So you actually seem to agree with me at the same time that you say
I'm wrong. There ARE different languages ! And call-by-reference
is NOT in all of them.
> But, call
> by ref is essential. (At least as essential as for-loops!)
What is REALLY essential in a language to be able to write
programs in it ?? I would recommend you take a look at languages
like Brainfuck and Befunge; it might change your perspective at
least a little bit.
<snip>
> > And how many real-world projects did you do or participate with
> > these languages ?
> I wrote two quite big (10.000 loc) projects in Pascal, I am writing an
> Eu translator in C (4.000 loc), I was forced to do plenty of small tasks
>
> with Java/ML (they really suck) at university. And I played a bit with
> Ada
So you never faced the issue where you are required to use a
specific language (that might not have c-b-r) for a contract
job where you MUST release the product within a certain timeframe,
no matter what.... This is a common situation in commercial
contract work. And it will show you that you can do the job without
call-by-reference (or goto for that matter).
> > I prefer languages that enforce certain rules for readability
> > and structured programming.
> Hah, look at C. It has case sensitiveness and does not lead to readable
> code.
But that has nothing to do with what I replied. The fact that
C has case-sensitiveness has noting to do with the ability of
the language to produce *ugly* code.
I'll leave it with this. You are a student and you obviously
need some real-world experience to season your beliefs a bit.
Wait until you are under a serious time constraint for delivering
a project to a big client (as in "one that can enforce your
liability") and you are required to code your way out of a
design problem. If your language does not have call-by-reference,
you will see that you still get the job done
Hans Peter Willems
15. RE: Eu's poor design
eugtk at yahoo.com wrote:
>
>
> --- Juergen Luethje <j.lue at gmx.de> wrote:
>
> > Andreas Rumpf wrote:
> > > Juergen Luethje wrote:
> > >> Andreas Rumpf wrote:
>
> > >> [Call by Reference]
>
> OK, we've had our fun with our computer science
> expert - who might just need to hit the books a bit
> more.
Are you another guy who has looked at 500.000 loc of your code and found
out that call by reference (or "pass by reference" where is the
difference, arrogant boy?) isn't needed (or at least not practical)?
That's so ridiculous. I don't believe you.
> 1. What you have been complaining about is NOT
> "Call by Reference" - it is Pass by Reference. Look it
> up.
Our great business man used "call by reference" too, so I guess it is
correct.
> 2. If you think case sensitivity is a problem, then
> you
> clearly have never written a large program. If you
> had,
> you would know that it's an aid, not a hindrance.
I've written large programs. And lack of "call by reference" is a
hindrance, believe it or not.
> 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.
You're right here.
> Irv
>
>
16. RE: Eu's poor design
My first language was Pascal/Delphi which has both. (I admit, "pass by
reference" (I can learn!) is preferred in Pascal.)
Apart from that, now another reason (of course for YOU these are only MY
shortcomings why Euphoria isn't as useful as it could be:
Have you ever tried to implement a binary tree in Euphoria?
I first tried it this way:
constant
LEFT = 1,
RIGHT = 2,
DATA = 3
sequence root -- a tree is {lefttree, righttree, data}
root = {}
function put(sequence root, object data)
-- overwrites exisiting data in the tree
-- this is just a little example. Note that you can't implement
-- insert/delete (iterative) either
integer cmp_result
sequence node
node = root
while not equal(node, {}) do
cmp_result = compare(node[DATA], data)
if cmp_result = -1 then
node = node[LEFT]
elsif cmp_result = 1 then
node = node[RIGHT]
else -- overwrite data
node[DATA] = data -- creates a copy of the node 
-- we can't modify the tree!!!
end if
end while
return root
end function
How make it iterative? I think the only way to do it iterative (more
efficient if you don't have tail-recursion-optimizations, which Eu
probably doesn't have) is like this:
sequence tree -- here all the nodes are stored!
-- a node is now { index to left subtree, index to right subtree,
-- data }
-- index = 0 if there is no subtree
-- so put becomes:
integer root
root = 0
function put(integer root, object data)
-- overwrites exisiting data in the tree
integer cmp_result
integer node
node = root
while node != 0 do
cmp_result = compare(tree[node][DATA], data)
if cmp_result = -1 then
node = tree[node][LEFT]
elsif cmp_result = 1 then
node = tree[node][RIGHT]
else -- overwrite data
tree[node][DATA] = data -- creates a copy of the sequence
-- which stores all our nodes
end if
end while
return tree
end function
This works, but it is more difficult. Note also, that inserting requires
the tree to append a new node which has a worst efficiency of O(N), so
forget about inserting with O(log N)! (Though I must admit that in
practice it will probably work fine...)
17. RE: Eu's poor design
Andreas Rumpf wrote:
>
>
> My first language was Pascal/Delphi which has both. (I admit, "pass by
> reference" (I can learn!) is preferred in Pascal.)
>
> Apart from that, now another reason (of course for YOU these are only MY
>
> shortcomings why Euphoria isn't as useful as it could be:
> Have you ever tried to implement a binary tree in Euphoria?
I don't understand your "put" function. It seems like the only thing it
will do is try to overwrite new data that is identical to the old data,
unless I'm missing something.
In any case, the short answer to making trees is to use recursion. I
use trees heavily in Euphoria. The ease of making trees in Euphoria of
any shape and size is one reason I like Euphoria. Making almost any
type of data structure is trivial. Making non-recursive "flat" trees
where each node has an explicit index to the next node will gain you a
bit of speed if your trees are huge with lots of floating-point values.
That is a little trickier since you need to maintain your own stack to
build them (making a stack in Eu is easy), and I've done that as well.
These are not major obstacles.
Strong-typing as pointed out by Irv can be a problem, and the type &
error system in Euphoria is where the next improvements in the language
need to be. But as another in a growing list of "million-liners", I
have never found myself beating my head against the wall because I
didn't have pass by reference. (And I don't care if you don't believe
me -- doesn't make it untrue.)
18. RE: Eu's poor design
Andy Serpa wrote:
>
>
> I don't understand your "put" function. It seems like the only thing it
>
> will do is try to overwrite new data that is identical to the old data,
> unless I'm missing something.
Hm, I should stop coding in a "reply to EUForum" window. You are
correct. I just wanted to give a small example -- well it was too small
and therefore wrong. But the point is there: You can't modify the tree
iteratively.
>
> In any case, the short answer to making trees is to use recursion.
In C/Pascal/etc. I have a choice, but not in Eu, pity.
> use trees heavily in Euphoria. The ease of making trees in Euphoria of
> any shape and size is one reason I like Euphoria. Making almost any
> type of data structure is trivial. Making non-recursive "flat" trees
> where each node has an explicit index to the next node will gain you a
> bit of speed if your trees are huge with lots of floating-point values.
I don't see what this has to do with floating-point values.
> That is a little trickier since you need to maintain your own stack to
> build them (making a stack in Eu is easy), and I've done that as well.
> These are not major obstacles.
>
> Strong-typing as pointed out by Irv can be a problem, and the type &
> error system in Euphoria is where the next improvements in the language
> need to be. But as another in a growing list of "million-liners", I
> have never found myself beating my head against the wall because I
> didn't have pass by reference. (And I don't care if you don't believe
> me -- doesn't make it untrue.)
>
I am tired of argumenting about this.
Still nobody showed me how to do
seq[1][2][3] = some_func(seq[1][2][3])
easier in Eu. Still nobody showed me an elegant tables.e implementation
without pbr.
19. RE: Eu's poor design
> (making a stack in Eu is easy)
Let's see the stack in Eu:
sequence stack
stack = {}
function push(sequence stack, object item)
return stack = append(stack, item)
end function
function pop(sequence stack) -- returns stack without top
return stack[1..length(stack)-1]
end function
function topOfStack(sequence stack)
return stack[length(stack)]
end function
Yes, quite easy. But what if I want to make it easier and more
efficient? (Using push()/pop() that modify the stack directly!) Guess
what, it can't be done in Eu.
Again, in Pascal/C/etc. I have choice how to implement certain things!
You can't even write a swap() routine, because of lack of pbr!
20. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> > I am tired of argumenting about this.
>
> Ok.
>
> > Still nobody showed me how to do
> > seq[1][2][3] = some_func(seq[1][2][3])
> > easier in Eu.
>
> x = some_func(x)
Yes, but you left out some assignments:
x = seq[1][2][3]
x = some_func(x)
seq[1][2][3] = x
-- This isn't easier.
>
> > Still nobody showed me an elegant tables.e implementation
> > without pbr.
>
> What does tables.e do again?
Give me some time, I look for the code...
>
> jbrown
>
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
>
> --
> /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
> \ / campain against | Linux User:190064
> X HTML in e-mail and | Linux Machine:84163
> /*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
>
>
21. RE: Eu's poor design
> I am tired of argumenting about this.
Then you shouldn't have brought it up. You say things like, "Have you
ever tried to make a binary tree in Euphoria?" as if it were hard to do.
It is incredibly easy to do in Euphoria.
> Still nobody showed me how to do
> seq[1][2][3] = some_func(seq[1][2][3])
> easier in Eu. Still nobody showed me an elegant tables.e implementation
> without pbr.
>
I believe you are letting your thinking be too much influenced by the
languages you are used to. You don't have pbr, so you think, "My god,
how in the world can I solve this problem in Euphoria?" I am learning
Haskell, but am used to Euphoria, so I have similar thoughts along the
way. That doesn't mean there is anything wrong with Haskell, however,
which is even higher-level than Euphoria. It just means I need to
adjust my thinking a bit.
I suggest this for reading:
http://www.haskell.org/complex/why_does_haskell_matter.html
Scroll to the bottom and read the "Epilogue". It seems to me you are
exhibiting this syndrome...
22. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 07:47:01PM +0000, Andreas Rumpf wrote:
> >
> >
> > jbrown105 at speedymail.org wrote:
> > >
> > >
> > > On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> > > > I am tired of argumenting about this.
> > >
> > > Ok.
> > >
> > > > Still nobody showed me how to do
> > > > seq[1][2][3] = some_func(seq[1][2][3])
> > > > easier in Eu.
> > >
> > > x = some_func(x)
> > Yes, but you left out some assignments:
> > x = seq[1][2][3]
> > x = some_func(x)
> > seq[1][2][3] = x
> > -- This isn't easier.
>
> Ok, tell me this.
>
> Why do you have the 'seq[1][2][3]' in the first place? Why not just use
> x throughout?
Because often you need sequences in sequences! And seq[1][2] is the way
to address the inner sequence.
23. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 07:41:01PM +0000, Andreas Rumpf wrote:
> >
> >
> > > (making a stack in Eu is easy)
> > Let's see the stack in Eu:
> >
> > sequence stack
> > stack = {}
> >
> > function push(sequence stack, object item)
> > return stack = append(stack, item)
>
> this is wrong, btw. should be:
>
> stack = append(stack, item)
> return stack
Yes, as I said I should stop coding in topica windows.
>
> > end function
> >
> > function pop(sequence stack) -- returns stack without top
>
> No, the pop removes the top of the stack, and then returns the part it
> removed.
Not necessarily.
>
> > return stack[1..length(stack)-1]
> > end function
> >
> > function topOfStack(sequence stack)
> > return stack[length(stack)]
> > end function
> >
> > Yes, quite easy. But what if I want to make it easier and more
> > efficient? (Using push()/pop() that modify the stack directly!) Guess
> > what, it can't be done in Eu.
>
> Wrong.
>
> sequence stack
> stack = {}
>
> procedure push(object item)
> stack = append(stack, item)
> end procedure
> function pop()
> object item
> item = stack[length(stack)]
> stack = stack[1..length(stack)-1]
> return item
> end function
>
> or with your version of pop() and topOfStack() (which is wrong btw)
>
> function pop()
> return stack[1..length(stack)-1]
> end function
> function topOfStack()
> return stack[length(stack)]
> end function
So, you used a global variable... (And proved one of my earlier
posts...) What if I want to have 2 different stacks? - Use a sequence of
stacks and pass the routines the index of the stack to work with. This
is a solution. But it simulates pbr! So why not have it directly?
> > Again, in Pascal/C/etc. I have choice how to implement certain things!
> > You can't even write a swap() routine, because of lack of pbr!
>
> Well C has no pbr. It has simulated pbr via pointers.
Ok, forget about C. What about Basic/Ada/C++?
>
> Yes, the inability to have a swap() routine is annoying. Very much so.
> Of course this could also be solved via macros ...
>
> object tmp
> macro swap(a,b) tmp = a a = b b = tmp
> ...
> swap(var_one, var_two)
>
> but only because the macro is rewritten as
>
> tmp = var_one var_one = var_two var_two = tmp
>
> so even the macro simulates pass-by-reference!
Let's implement a macro facility instead of pbr! (Irony)
24. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 08:12:51PM +0000, Andreas Rumpf wrote:
> >
> >
> > jbrown105 at speedymail.org wrote:
> > >
> > >
> > > On Sun, Aug 17, 2003 at 07:47:01PM +0000, Andreas Rumpf wrote:
> > > >
> > > >
> > > > jbrown105 at speedymail.org wrote:
> > > > >
> > > > >
> > > > > On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> > > > > > I am tired of argumenting about this.
> > > > >
> > > > > Ok.
> > > > >
> > > > > > Still nobody showed me how to do
> > > > > > seq[1][2][3] = some_func(seq[1][2][3])
> > > > > > easier in Eu.
> > > > >
> > > > > x = some_func(x)
> > > > Yes, but you left out some assignments:
> > > > x = seq[1][2][3]
> > > > x = some_func(x)
> > > > seq[1][2][3] = x
> > > > -- This isn't easier.
> > >
> > > Ok, tell me this.
> > >
> > > Why do you have the 'seq[1][2][3]' in the first place? Why not just use
> > > x throughout?
> > Because often you need sequences in sequences! And seq[1][2] is the way
> > to address the inner sequence.
>
> In that case, my way is easier!
>
> x = seq[1][2][3]
> x = some_func(x)
> x = some_other_func(x)
> for i = 1 to length(x) do
> x[i] = ....some stuff here....
> end for
> seq[1][2][3] = x
>
> jbrown
Yes, that's the way to go in Euphoria. But I think, the
seq[1][2][3] = x
command is often forgotten. And if you look at Rob's hash.e and
translate it to a program that uses pbr (assuming Eu would have it)you
will find out that pbr is less error-prone, easier to understand and
more efficient.
25. RE: Eu's poor design
Andy Serpa wrote:
>
>
> > I am tired of argumenting about this.
>
> Then you shouldn't have brought it up. You say things like, "Have you
> ever tried to make a binary tree in Euphoria?" as if it were hard to do.
>
> It is incredibly easy to do in Euphoria.
>
It is difficult to do iterative.
>
> > Still nobody showed me how to do
> > seq[1][2][3] = some_func(seq[1][2][3])
> > easier in Eu. Still nobody showed me an elegant tables.e implementation
> > without pbr.
> >
>
> I believe you are letting your thinking be too much influenced by the
> languages you are used to. You don't have pbr, so you think, "My god,
> how in the world can I solve this problem in Euphoria?"
Oh boy, I know how to solve it in Euphoria. It is just that the solution
is neither elegant or efficient.
> I am learning
> Haskell, but am used to Euphoria, so I have similar thoughts along the
> way. That doesn't mean there is anything wrong with Haskell, however,
> which is even higher-level than Euphoria. It just means I need to
> adjust my thinking a bit.
>
> I suggest this for reading:
>
> http://www.haskell.org/complex/why_does_haskell_matter.html
>
> Scroll to the bottom and read the "Epilogue". It seems to me you are
> exhibiting this syndrome...
>
Thank you for analysing my psyche. (As I said earlier I know functional
programming. But Eu isn't functional (it has side-effects!).)
26. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 08:37:53PM +0000, Andreas Rumpf wrote:
> > > In that case, my way is easier!
> > >
> > > x = seq[1][2][3]
> > > x = some_func(x)
> > > x = some_other_func(x)
> > > for i = 1 to length(x) do
> > > x[i] = ....some stuff here....
> > > end for
> > > seq[1][2][3] = x
> > >
> > > jbrown
> >
> > Yes, that's the way to go in Euphoria. But I think, the
> > seq[1][2][3] = x
> > command is often forgotten.
>
> Perhaps. An understandable mistake from a newbie programmer, to be sure.
>
> It would be better to do this:
>
> alias x as seq[1][2][3]
> x = some_func(x)
> x = some_other_func(x)
> for i = 1 to length(x) do
> x[i] = ....some stuff here....
> end for
> --no need for a 'seq[1][2][3] = x' as the alias automaticly causes the
> original
> --slice to be updated.
>
> This alias technique can be considered close to pbr, tho depending on
> its
> implementation it might be considered closer to that of a "#define" or a
> macro
> (but as I have already shown the 2 arent really that far apart anyways).
>
> > And if you look at Rob's hash.e and
> > translate it to a program that uses pbr (assuming Eu would have it)you
> > will find out that pbr is less error-prone, easier to understand and
> > more efficient.
> >
>
> Concurred. I'm not against PBR in the language. What I am saying is that
> the
> lack of PBR is not a difficult workaround (worst case senario: you have
> to use
> a global sequence and sequence indexes to simulate pbr).
>
> jbrown
Agreed. (And I like your alias idea.)
27. RE: Eu's poor design
But think about it: Some languages are too complex because they offer
features that would better have been implemented via a library.
Euphoria's the other way round. It is too simple, so a lot of features
have been implemented via strange libraries (a library for pass by
reference is ridiculous). Look at those funny call_func()/call_proc()
functions patching over a serious problem: The lack of function
pointers! And the lack of forward references!
28. RE: Eu's poor design
Andreas Rumpf wrote:
>
>
> Andy Serpa wrote:
> >
> >
> > > I am tired of argumenting about this.
> >
> > Then you shouldn't have brought it up. You say things like, "Have you
> > ever tried to make a binary tree in Euphoria?" as if it were hard to do.
> >
> >
> > It is incredibly easy to do in Euphoria.
> >
> It is difficult to do iterative.
> >
I do not know what you mean by iterative in this context. I don't see
how making trees could be easier than making them in Eu.
> > > Still nobody showed me how to do
> > > seq[1][2][3] = some_func(seq[1][2][3])
> > > easier in Eu. Still nobody showed me an elegant tables.e implementation
> > > without pbr.
> > >
> >
> > I believe you are letting your thinking be too much influenced by the
> > languages you are used to. You don't have pbr, so you think, "My god,
> > how in the world can I solve this problem in Euphoria?"
> Oh boy, I know how to solve it in Euphoria. It is just that the solution
>
> is neither elegant or efficient.
>
I don't think you know the best way to do it Euphoria, because you are
forcing un-Euphorian concepts onto it.
>
> > I am learning
> > Haskell, but am used to Euphoria, so I have similar thoughts along the
> > way. That doesn't mean there is anything wrong with Haskell, however,
> > which is even higher-level than Euphoria. It just means I need to
> > adjust my thinking a bit.
> >
> > I suggest this for reading:
> >
> > http://www.haskell.org/complex/why_does_haskell_matter.html
> >
> > Scroll to the bottom and read the "Epilogue". It seems to me you are
> > exhibiting this syndrome...
> >
> Thank you for analysing my psyche. (As I said earlier I know functional
> programming. But Eu isn't functional (it has side-effects!).)
>
I didn't say it was functional (it does have a few functional elements,
though). You missed the point.
29. RE: Eu's poor design
> > > It is incredibly easy to do in Euphoria.
> > >
> > It is difficult to do iterative.
> > >
>
> I do not know what you mean by iterative in this context. I don't see
> how making trees could be easier than making them in Eu.
Iterative means by loops and not by using recursion.
>
>
> > > > Still nobody showed me how to do
> > > > seq[1][2][3] = some_func(seq[1][2][3])
> > > > easier in Eu. Still nobody showed me an elegant tables.e implementation
> > > > without pbr.
> > > >
> > >
> > > I believe you are letting your thinking be too much influenced by the
> > > languages you are used to. You don't have pbr, so you think, "My god,
> > > how in the world can I solve this problem in Euphoria?"
> > Oh boy, I know how to solve it in Euphoria. It is just that the solution
> >
> >
> > is neither elegant or efficient.
> >
>
> I don't think you know the best way to do it Euphoria, because you are
> forcing un-Euphorian concepts onto it.
Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
concept? I don't think so.
>
> >
> > > I am learning
> > > Haskell, but am used to Euphoria, so I have similar thoughts along the
> > > way. That doesn't mean there is anything wrong with Haskell, however,
> > > which is even higher-level than Euphoria. It just means I need to
> > > adjust my thinking a bit.
> > >
> > > I suggest this for reading:
> > >
> > > http://www.haskell.org/complex/why_does_haskell_matter.html
> > >
> > > Scroll to the bottom and read the "Epilogue". It seems to me you are
> > > exhibiting this syndrome...
> > >
> > Thank you for analysing my psyche. (As I said earlier I know functional
> > programming. But Eu isn't functional (it has side-effects!).)
> >
>
> I didn't say it was functional (it does have a few functional elements,
> though).
Yeah, one or two.
> You missed the point.
No. As I said, Eu has side-effects. Pbr would not break Eu's concepts.
30. RE: Eu's poor design
jbrown105 at speedymail.org wrote:
>
>
> On Sun, Aug 17, 2003 at 09:16:00PM +0000, Andreas Rumpf wrote:
> >
> >
> > But think about it: Some languages are too complex because they offer
> > features that would better have been implemented via a library.
> > Euphoria's the other way round. It is too simple, so a lot of features
> > have been implemented via strange libraries (a library for pass by
> > reference is ridiculous). Look at those funny call_func()/call_proc()
> > functions patching over a serious problem: The lack of function
> > pointers! And the lack of forward references!
> >
>
> Guess this means you are against a variable_id()/set_var()/get_var()
> concept
> for pbr eh?
Yes.
>
> Also, I wonder what you would think about the OE planned implementation
> of
> OOP. The idea, is to support fully the OO syntax (so
> foo.method(bar.member)
> works) but to have the OO engine in a library. The parser would simply
> convert foo.method(..) into call_method(foo, method, ...) (which is what
> most Eu OO librarys look like btw). So, the syntax would be builtin but
> the actual code which did OO would be external. Your thougths?
Well, a parser knowing an external library is a strange concept. Eu is a
procedural language. If I wanted to use OO then I would use Eiffel, for
example.
>
> jbrown
>
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
>
> --
> /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
> \ / campain against | Linux User:190064
> X HTML in e-mail and | Linux Machine:84163
> /*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
>
>
31. RE: Eu's poor design
> >
> > I do not know what you mean by iterative in this context. I don't see
> > how making trees could be easier than making them in Eu.
> Iterative means by loops and not by using recursion.
>
What is not elegant about recursion? I would say that is more elegant
that loops. Recursion is the natural way to make a tree. The code will
certainly be smaller with recursion.
But you can do it either way with Euphoria.
> Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
> concept? I don't think so.
>
I'm not against pbr. But not having it is no big deal. I would like
variable_id(), however, but not for pbr reasons.
>
> > You missed the point.
> No. As I said, Eu has side-effects. Pbr would not break Eu's concepts.
>
No, it wouldn't, and if it was added I wouldn't complain. But I doubt I
would use it much.
Nevertheless, you missed the original point, again. (About your psyche,
not about functional programming and whether or not Eu has
side-effects.)
32. RE: Eu's poor design
Pete Lomax wrote:
>
>
> On Sun, 17 Aug 2003 19:53:25 +0000, Andy Serpa <ac at onehorseshy.com>
> wrote:
>
> >I suggest this for reading:
> >
> >http://www.haskell.org/complex/why_does_haskell_matter.html
> >
> Thanks for the link, you reacquainted me with Simon L Peyton Jones, I
> first purchased one of his books back in 1987...
>
> I think it's quite amusing to note that Haskell (which I hope most
> people will agree is a fairly advanced language) does not have pass by
> reference!
>
By the way, I have successfully been able to make functions in Haskell,
compile them into a .dll, and call them from Euphoria if anyone is
interested (just passing atoms back and forth so far -- haven't gotten
into how you would do arrays or reference direct memory). The optimized
code from the Haskell GHC compiler is very fast.
33. RE: Eu's poor design
- Posted by rforno at tutopia.com
Aug 18, 2003
Regarding your proposal about integers wrapping around, I'm definitely
against it. This is just a drawback of C, C++ and Java.
Regards.
----- Original Message -----
From: Andreas Rumpf <pfropfen at gmx.net>
Subject: Eu's poor design
>
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
>
> So for real applications I would use global variables all over the place
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
>
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly. Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
>
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time. Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
>
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
>
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
>
> I used to use hashing a lot. Guess what, in Euphoria most hash functions
> can't be implemented (or only with poor performance!), because integers
> don't wrap around but are converted to floating point when they get to
> big!
>
>
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
34. RE: Eu's poor design
Derek Parnell wrote:
>
>
> On Sun, 17 Aug 2003 22:32:45 +0000 (08/18/03 08:32:45)
> , Andreas Rumpf <pfropfen at gmx.net> wrote:
> [snip]
>
> >> I don't think you know the best way to do it Euphoria, because you are
> >> forcing un-Euphorian concepts onto it.
> > Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
> > concept? I don't think so.
>
> PBR is not a Euphoria concept because Euphoria tries to minimise side-
> effects.
Yes, but this design is not practical. It forces the programmer to use
global variables all over the place which have their own problems (think
of gargabe collection...)
So it seems to me, Eu is a language that wants to be functional but
isn't.
I don't see why using global variables is a better solution.
> In Euphoria, a routine is a code construct that is used to do a
> unit of work, possibly utilizing the data passed to it. If the routine
> returns any data, that returned data is independant of the data passed
> to
> it.
>
> By having this restriction, the interpreter can make some optimisations
> (assumptions) about the variables in scope. If PBR were allowed, then
> the
> interpreter must not assume that the routine has left its variables
> untouched. Which means that subsequent references to the variables must
> be
> re-read by the interpreter IN CASE they have been modified.
Hm. The compiler knows when a parameter is passed in by reference. So we
can optimize all variables which aren't passed by reference (at least).
>
> integer a,b
> a = 1
> b = someFunc(a)
> someProc(&a, &b) -- I'm using the '&' to indicate PBR
> -- At this point, 'a', or 'b' or both may or may not have been changed.
> -- The interpreter cannot cache the value of 'a' or 'b' but is forced
> -- to fetch them again.
> if b = a then
> ...
> end if
>
> PBR always increases the probability of side-effects. To counteract
> those,
> extra code is required, adding to the maintenance effort and further
> increasing the probability of bugs.
I've never had a bug because of pbr. (I've had lots of bugs via pointers
& lack of garbage collection!)
>
> So, why does PBR exist as a concept and why do we need it?
>
> PBR came about as a practical solution to a physical problem. Before we
> had
> compilers, parameters were passed to routines by placing their values
> into
> a CPU register. The routine would also pass back values in CPU
> registers.
> This gave rise to 'calling conventions' - a protocol about which
> registers
> to use for what. It soon transpired that some data was too big to place
> into registers. Sometimes multiple registers were used, and other times
> the
> data was placed into RAM and a register was loaded with the RAM address
> of
> the data value. In other words, a reference to the parameter was passed
> instead of the parameter itself.
>
> Later, when compilers were devised and espectially the concept of a
> stack
> frame reference, passing large data values by value was made easier. But
>
> all that copying to RAM and back could slow things down. So, in general,
>
> when it came to passing a large dataitem, coders would tend to pass its
> RAM
> address (because that was small). This was also helpful for dataitems of
>
> arbitary sizes, as the address length is always the same size,
> regardless
> of the actual dataitem's size.
>
> So, in general, PBR is used to avoid copying large dataitems, and/or to
> make using arbitary sized dataitems easier. Another use is when the
> decision to update a dataitem is not known by the routine until runtime.
> A
> fourth reason is because its easier to code it that way.
>
> In Euphoria, large dataitems are repesented by sequences. When Euphoria
> passes a sequence to a routine, it actually does pass a reference to the
>
> sequence - there is no big copying going on. The first time that the
> sequence is updated by the routine, a copy is made of the sequence. This
>
> means that routines that do not update sequences are not penalized by
> receiving sequences.
>
> Now comes the Euphoria philosophy - who owns the data; the caller or the
>
> callee? Euphoria believes that the caller owns the data. That it is the
> caller who is responsible for a dataitem being consistent and correct.
> As
> such, it assumes that the callee knows nothing about the dataitem other
> than its current contents. Thus if the callee needs to change the data,
> it
> must tell the caller what the new values should be. It is then the
> caller
> that decides how to apply these changes.
>
> PBR would break this philosophy.
>
> However, what we find over and over again in Euphoria programs is a
> coding
> idiom along the lines of ...
>
> x = func(x, ...)
>
> There maybe a case for adding some syntactic sugar to Euphoria that
> makes
> coding this commonly used idiom easier.
>
> func( &x, ... )
>
> for example. This idiom is particularly irksome when 'x' is really a
> rather
> long name reference. If this syntax were allowed in Euphoria, then
>
> append( &stack_space[lThisStack], pData )
>
> would be interpreted as if I had actually written ...
>
> stack_space[lThisStack] = append( stack_space[lThisStack], pData )
>
>
> Back to the PBR usages...
>
> Again, sequences nicely implement arbitary-length dataitems. Passing
> these
> to 'read-only' routines incurs no penalty in terms of copying data. And
> again, the data ownership philosophy would apply to changing the
> dataitems.
>
> When it comes to the run-time decisions about whether or not elements
> need
> updating, Euphoria's data ownership philosophy means that the caller may
>
> know that a dataitem might need updating but not what nor how the new
> values are to be derived. So it would need to pass the dataitem to the
> routine that does know how to determine if updating is required, etc...
<snip>
35. RE: Eu's poor design
Derek Parnell wrote:
>
>
> On Sun, 17 Aug 2003 22:38:39 +0000 (08/18/03 08:38:39)
> , Andreas Rumpf <pfropfen at gmx.net> wrote:
>
> >
> > jbrown105 at speedymail.org wrote:
> >>
> >>
> >> On Sun, Aug 17, 2003 at 09:16:00PM +0000, Andreas Rumpf wrote:
> >>> > > But think about it: Some languages are too complex because they
> >> offer > features that would better have been implemented via a library.
> >> > Euphoria's the other way round. It is too simple, so a lot of features
> >> > have been implemented via strange libraries (a library for pass by >
> >> reference is ridiculous). Look at those funny call_func()/call_proc() >
> >> functions patching over a serious problem: The lack of function >
> >> pointers! And the lack of forward references!
>
> But routine_id() is Euphoria's implementation of function pointers. You
> may
> not like the syntax, but the concept is still there.
>
> Forward referencing is not allowed because the designers of Euphoria
> believe that it is a 'wrong thing' to implement - like goto and pass-by-
>
> reference. It is a philosophical position. The designer of any language
> is
> allowed to implement their biases and pedalogical ideas. Your job, if
> you
> don't like it, is to *prove and thus demonstrate* that change can bring
> about improvement.
I showed you. I can also show you 'forward', if you like:
forward function b()
function a()
return b() + 1
end function
function b()
return a() + 2
end function
>
> >>
> >> Guess this means you are against a variable_id()/set_var()/get_var()
> >> concept
> >> for pbr eh?
> > Yes.
>
> It's only syntax.
Perhaps it's only syntax what makes programming languages useful.
>
> >>
> >> Also, I wonder what you would think about the OE planned implementation
> >> of
> >> OOP. The idea, is to support fully the OO syntax (so
> >> foo.method(bar.member)
> >> works) but to have the OO engine in a library. The parser would simply
> >> convert foo.method(..) into call_method(foo, method, ...) (which is what
> >> most Eu OO librarys look like btw). So, the syntax would be builtin but
> >> the actual code which did OO would be external. Your thougths?
> >
> > Well, a parser knowing an external library is a strange concept.
>
> That is not what was said. What was said was a statement in the form
> ...
>
> foo.method(...)
>
> would be interpreted as syntactical shorthand for ...
>
> OO:call_method(foo,"method", { ... } )
>
> This allows the implementation of OO to be customized. The coder is not
> limited to whatever was supplied with their copy of OpenEU.
>
> The OpenEU parser does NOT know the external library. All it knows is
> the
> shorthand syntax - not it semantics.
>
> > Eu is a procedural language. If I wanted to use OO then I would use
> > Eiffel, for example.
>
> And by this reasoning, if we wanted PBR we'd use COBOL etc... and if we
> wanted to use GOTO we'd use Assember etc...., and if we wanted forward
> references we'd use VB etc...
Yes, but pbr is a procedural concept just like 'forward'.
36. RE: Eu's poor design
Derek Parnell wrote:
>
>
> On Mon, 18 Aug 2003 06:54:02 +0000 (08/18/03 16:54:02)
> , Andreas Rumpf <pfropfen at gmx.net> wrote:
>
> >
> > Derek Parnell wrote:
> >>
> >>
> >> On Sun, 17 Aug 2003 22:32:45 +0000 (08/18/03 08:32:45)
> >> , Andreas Rumpf <pfropfen at gmx.net> wrote:
> >> [snip]
> >>
> >> >> I don't think you know the best way to do it Euphoria, because you
> >> are >> forcing un-Euphorian concepts onto it.
> >> > Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian >
> >> concept? I don't think so.
> >>
> >> PBR is not a Euphoria concept because Euphoria tries to minimise side-
> >> effects.
> > Yes, but this design is not practical. It forces the programmer to use
> > global variables all over the place which have their own problems (think
> >
> > of gargabe collection...)
>
> I agree with the idea that using global variables is minefield - bugs
> just
> waiting to happen. However, the lack of PBR does NOT force globals
If you want easy coding, you are forced to use globals in Eu. Think
about the stack example.
Remember
> that shared variables can be restricted in scope to a source file. Thus
> a
> source file that implements stacks can use shared variables that are not
>
> global.
Yes, I can't see the globals outside the library, but they are there and
won't be garbage-collected.
>
> > So it seems to me, Eu is a language that wants to be functional but
> > isn't.
>
> Can't see this myself. I don't believe the designers of Euphoria wanted
> it
> to be a functional language.
By the way, there is only one designer - Rob.
>
> > I don't see why using global variables is a better solution.
>
> Neither do I. And I can also see that globals are not the only solution.
>
> I'll send you an implementation of stacks, if you like that demonstrates
> my
> assertion.
I guess, I already know your implementation: You use a global sequence
which contains all the stacks and use an index to access a particular
one. We had this.
>
> >> In Euphoria, a routine is a code construct that is used to do a unit of
> >> work, possibly utilizing the data passed to it. If the routine returns
> >> any data, that returned data is independant of the data passed to it.
> >>
> >> By having this restriction, the interpreter can make some optimisations
> >> (assumptions) about the variables in scope. If PBR were allowed, then
> >> the interpreter must not assume that the routine has left its variables
> >> untouched. Which means that subsequent references to the variables must
> >> be re-read by the interpreter IN CASE they have been modified.
> > Hm. The compiler knows when a parameter is passed in by reference. So we
> >
> > can optimize all variables which aren't passed by reference (at least).
>
> Which is the same as saying that we can optimise all variables if none
> are
> ever passed by reference.
NO! That way I have to update the values myself and efficiency is WORSE.
37. RE: Eu's poor design
Pete Lomax wrote:
>
>
> On Mon, 18 Aug 2003 07:22:33 +0000, Andreas Rumpf <pfropfen at gmx.net>
> wrote:
>
> >I showed you. I can also show you 'forward', if you like:
> >
> >forward function b()
> >
> >function a()
> > return b() + 1
> >end function
> >
> >function b()
> > return a() + 2
> >end function
> >
> LOL show that to your tutor, I dare you.
> Whatever, it is not hard:
>
> integer brid
And again, Eu's type system is confusing! brid is not an integer really,
it is a pointer to a function!
>
> function a()
> return call_func(brid,{})+1
> end function
>
> function b()
> return a()+2
> end function
> brid=routine_id("b")
No, it's not hard, but as I said, it isn't elegant nor efficient either.
38. RE: Eu's poor design
I don't know what you mean by 'iterative' or 'tail-recursion-optimizations',
but your methodology certainly isn't the only (or best) way to implement a
tree in Eu. A much quicker way is to use parallel sequences:
sequence left, right, data
Then, you can append in chunks, so you're not always appending just one
element. You can always tune this to the particular algorithm. Anyway, if
you look at Mic's lzss library in the archives, you'll see a pretty fast
tree implementation (ported from C). It's not real clear what you wanted to
do here with put(), since it doesn't really do anything.
My experience is that you need to stop thinking like other languages when
using sequences, since they're more powerful than the native data structures
available in most other languages, and their strong points and weaknesses
aren't always as obvious as they at first appear. I've had many Eureka
moments where I was able to drastically improve an algorithm because I
wasn't approaching the task in the best way.
Matt Lewis
> From: Andreas Rumpf [mailto:pfropfen at gmx.net]
>
> How make it iterative? I think the only way to do it iterative (more
> efficient if you don't have tail-recursion-optimizations, which Eu
> probably doesn't have) is like this:
>
> sequence tree -- here all the nodes are stored!
> -- a node is now { index to left subtree, index to right subtree,
> -- data }
> -- index = 0 if there is no subtree
>
> -- so put becomes:
> integer root
> root = 0
>
> function put(integer root, object data)
> -- overwrites exisiting data in the tree
> integer cmp_result
> integer node
> node = root
> while node != 0 do
> cmp_result = compare(tree[node][DATA], data)
> if cmp_result = -1 then
> node = tree[node][LEFT]
> elsif cmp_result = 1 then
> node = tree[node][RIGHT]
> else -- overwrite data
> tree[node][DATA] = data -- creates a copy of the sequence
> -- which stores all our nodes
> end if
> end while
> return tree
> end function
>
> This works, but it is more difficult. Note also, that
> inserting requires
> the tree to append a new node which has a worst efficiency of
> O(N), so
> forget about inserting with O(log N)! (Though I must admit that in
> practice it will probably work fine...)
39. RE: Eu's poor design
> From: Andy Serpa [mailto:ac at onehorseshy.com]
> I believe you are letting your thinking be too much influenced
> by the languages you are used to. You don't have pbr, so you
> think, "My god, how in the world can I solve this problem in
> Euphoria?" I am learning Haskell, but am used to Euphoria, so
> I have similar thoughts along the way. That doesn't mean there
> is anything wrong with Haskell, however, which is even higher-
> level than Euphoria. It just means I need to adjust my thinking
> a bit.
>
> I suggest this for reading:
>
> http://www.haskell.org/complex/why_does_haskell_matter.html
>
> Scroll to the bottom and read the "Epilogue". It seems to me you
> are exhibiting this syndrome...
A neat read. I don't think he got it, though the point should have been
clear from reading the rest of the article. I thought it interesting that
this is exactly the point that was made by the base-12 guy we talked about a
few weeks back.
Matt Lewis
40. RE: Eu's poor design
> From: Andreas Rumpf [mailto:pfropfen at gmx.net]
> Derek Parnell wrote:
> > I'll send you an implementation of stacks, if you like that
> > demonstrates my assertion.
>
> I guess, I already know your implementation: You use a global
> sequence which contains all the stacks and use an index to
> access a particular one. We had this.
OK, first, he's not going to use a 'global' variable. He'll use a 'local'
variable. That's contained within a file's scope, so no globals are
required. Perhaps it's better to think about this as 'static'. Either way.
It seems that what you'd like to do is store the stack itself outside of the
stack code's source file, and pass it by reference. You could still do
somehting like this, albeit without the pass by reference (think
append/prepend). It wouldn't be very elegant, but that's what you get for
forcing a design. But what's the point/difference/advantage?
Matt Lewis
41. RE: Eu's poor design
Matt Lewis wrote:
>
>
> > From: Andreas Rumpf [mailto:pfropfen at gmx.net]
>
> > Derek Parnell wrote:
>
> > > I'll send you an implementation of stacks, if you like that
> > > demonstrates my assertion.
> >
> > I guess, I already know your implementation: You use a global
> > sequence which contains all the stacks and use an index to
> > access a particular one. We had this.
>
> OK, first, he's not going to use a 'global' variable. He'll use a
> 'local'
> variable. That's contained within a file's scope, so no globals are
> required. Perhaps it's better to think about this as 'static'. Either
> way.
Ok, let's call it 'static'. It doesn't matter.
> It seems that what you'd like to do is store the stack itself outside of
> the
> stack code's source file, and pass it by reference. You could still do
> somehting like this, albeit without the pass by reference (think
> append/prepend). It wouldn't be very elegant, but that's what you get
> for
> forcing a design.
Forcing a design? What's wrong with doing it efficiently?
Please read the last posts.
42. RE: Eu's poor design
> From: Andreas Rumpf [mailto:pfropfen at gmx.net]
> Matt Lewis wrote:
> > It seems that what you'd like to do is store the stack
> > itself outside of the stack code's source file, and
> > pass it by reference. You could still do somehting
> > like this, albeit without the pass by reference (think
> > append/prepend). It wouldn't be very elegant, but that's
> > what you get for forcing a design.
>
> Forcing a design? What's wrong with doing it efficiently?
> Please read the last posts.
I don't see what efficiency is really gained by storing
the data locally and passing by reference versus storing
the data where it will be manipulated and passing an
index. Either way, you're passing a 'pointer' of sorts.
You've just decided that one 'pointer' is good, and
another is bad, and I don't understand the reasons
behind the judgment.
Matt Lewis
43. RE: Eu's poor design
Matt Lewis wrote:
>
>
> > From: Andreas Rumpf [mailto:pfropfen at gmx.net]
>
> > Matt Lewis wrote:
>
> > > It seems that what you'd like to do is store the stack
> > > itself outside of the stack code's source file, and
> > > pass it by reference. You could still do somehting
> > > like this, albeit without the pass by reference (think
> > > append/prepend). It wouldn't be very elegant, but that's
> > > what you get for forcing a design.
> >
> > Forcing a design? What's wrong with doing it efficiently?
> > Please read the last posts.
>
> I don't see what efficiency is really gained by storing
> the data locally and passing by reference versus storing
> the data where it will be manipulated and passing an
> index. Either way, you're passing a 'pointer' of sorts.
The local one is garbage-collected.
> You've just decided that one 'pointer' is good, and
> another is bad, and I don't understand the reasons
> behind the judgment.
That's not my decision! It's Eu's decision! Because the 'other' pointer
method is not available in Eu!
>
> Matt Lewis
>
