1. RE: Eu's poor design
- Posted by Peter Willems <peter at integratedmoves.com> Aug 16, 2003
- 519 views
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
- 484 views
--- 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
- 469 views
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
- Posted by Peter Willems <peter at integratedmoves.com> Aug 16, 2003
- 491 views
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
- 493 views
--- 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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 16, 2003
- 488 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 16, 2003
- 474 views
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
- Posted by Peter Willems <peter at integratedmoves.com> Aug 16, 2003
- 483 views
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
- Posted by Peter Willems <peter at integratedmoves.com> Aug 16, 2003
- 478 views
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
- 477 views
--- 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
- 475 views
--- 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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 478 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 478 views
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
- Posted by Peter Willems <peter at integratedmoves.com> Aug 17, 2003
- 477 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 488 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 476 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 17, 2003
- 472 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 460 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 452 views
> (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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 466 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 17, 2003
- 477 views
> 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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 468 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 468 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 462 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 478 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 462 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 479 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 17, 2003
- 464 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 468 views
> > > 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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 17, 2003
- 467 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 17, 2003
- 474 views
> > > > 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
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 18, 2003
- 476 views
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
- 492 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 475 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 476 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 494 views
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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 477 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 18, 2003
- 487 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 18, 2003
- 467 views
> 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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 18, 2003
- 467 views
> 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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 484 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 18, 2003
- 488 views
> 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
- Posted by Andreas Rumpf <pfropfen at gmx.net> Aug 18, 2003
- 460 views
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 >