1. Euphoria in the past, present and future (was: New Euphoria Users Websit
- Posted by Ray Smith <smithr at ix.net.au> Nov 14, 2002
- 438 views
- Last edited Nov 15, 2002
jbrown105 at speedymail.org wrote: [big snip] > (I do want a bloated Eu with many features, at the same time I want a > slim > version as well. i.e., I want both! Hence my viewpoint and decisions on > my > current projects.) When I first started looking at Euphoria 3 or 4 years ago my requirements for a language where very similar to what Euphoria offered. (small, fast and uncomplicated). Now I find my requirements have changed to be a language that allows me to: * create programs easily (in a variety of areas), * to have a large number of “good” libraries available, * produce programs that are easy to maintain and enhance, * be cross platform, * be free and even better open source, * be object oriented * have a large user base (which helps with many of the above points) As you can see I'm not even consedering speed and size anymore. I'm now interested in how easily I can create and maintain applications. Which brings me to my point: are the goals of the Euphoria language still valid in this day and age? Is being small and fast as big as an issue as it once was? I'm sure I have read on the list before how the Euphoria source code is created in such a way where speed is the most important thing. These days many believe “readability” of source code is more important so that bug fixes and enhancements can be made more easily. Is this why Euphoria is so static? Because the source code is designed for speed and size and not readability and maintainability? I'd be interested to hear what offers think Ray Smith http://rays-web.com
2. Re: Euphoria in the past, present and future (was: New Euphoria Users Websit
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 15, 2002
- 450 views
Hi Ray, I've been saying this for years now. The purpose of a Programming Language is to make life easier for the CODER, not the user of the application nor the creator of the language implementation. Most applications can be created in any language. The better applications tend to be created through a combination of development skills and programming language "ease-of-use". The current incarnation of Euphoria is deeply, though not entirely, effected by the implementor's philosophy about Programming. The first programming languages were very crude - primarily entering binary numbers directly into RAM. Very quickly people got tired of this and started thinking of better and easier ways of doing essentially the same thing - getting numbers into RAM. Autocoder - Assembler - Fortran,COBOL,PL/I, Algol - Pascal,Basic,C,SNOBOL,Lisp - ... and the list goes on. Euphoria is SO close to being a truely fantastic language it hurts to see it stagnate like it does. There are only a handful of basic changes required to make it really useful and easy to code in. But these changes seem to contrary to the RDS Programming Idealogy thus they are unlikely to ever be implmented by RDS. Karl's BACH is a good first step into helping free the language. If I had more time I'd try and create a new Euphoria interpreter/compiler that would be both compatible with 2.3 and try to address the needs that coders have been declaring through this and other forums. I too believe that speed and size are secondary to lowering the cost of creating and maintaining code. * * * * * Please Note: This is only one opinion and is thus highly likely to be wrong. You are encouraged to form your own opinions. 15/11/2002 9:21:07 AM, Ray Smith <smithr at ix.net.au> wrote: > > >jbrown105 at speedymail.org wrote: > >[big snip] > >> (I do want a bloated Eu with many features, at the same time I want a >> slim >> version as well. i.e., I want both! Hence my viewpoint and decisions on >> my >> current projects.) > >When I first started looking at Euphoria 3 or 4 years ago my >requirements for a language where very similar to what Euphoria >offered. (small, fast and uncomplicated). > >Now I find my requirements have changed to be a language that >allows me to: >* create programs easily (in a variety of areas), >* to have a large number of ?good? libraries available, >* produce programs that are easy to maintain and enhance, >* be cross platform, >* be free and even better open source, >* be object oriented >* have a large user base (which helps with many of the above points) > >As you can see I'm not even consedering speed and size anymore. >I'm now interested in how easily I can create and maintain applications. > >Which brings me to my point: > >are the goals of the Euphoria language still valid in this day and age? > >Is being small and fast as big as an issue as it once was? > >I'm sure I have read on the list before how the Euphoria source code >is created in such a way where speed is the most important thing. >These days many believe ?readability? of source code is more >important so that bug fixes and enhancements can be made more >easily. Is this why Euphoria is so static? Because the source code >is designed for speed and size and not readability and maintainability? > > >I'd be interested to hear what offers think > >Ray Smith >http://rays-web.com > > > > --------- Cheers, Derek Parnell ICQ# 7647806
3. Re: Euphoria in the past, present and future (was: New Euphoria Users Websit
- Posted by Kat <kat at kogeijin.com> Nov 14, 2002
- 440 views
On 14 Nov 2002, at 22:21, Ray Smith wrote: > > > jbrown105 at speedymail.org wrote: > > [big snip] > > > (I do want a bloated Eu with many features, at the same time I want a > > slim > > version as well. i.e., I want both! Hence my viewpoint and decisions on > > my > > current projects.) > > When I first started looking at Euphoria 3 or 4 years ago my > requirements for a language where very similar to what Euphoria > offered. (small, fast and uncomplicated). Back in 1996, when i was running into massive brick walls with Turbo Pascal, i was looking for something on par with it in size too, and speed. I had a 586-133 with 32megs of ram and a 540meg harddrive which was full. That's not the case now. I don't want to see Eu oriented only for people with 7 year old hardware. (But keep supporting win95!!, can't get parts for the hardware, but the software keeps running ok) > Now I find my requirements have changed to be a language that > allows me to: > * create programs easily (in a variety of areas), > * to have a large number of “good” libraries available, > * produce programs that are easy to maintain and enhance, > * be cross platform, > * be free and even better open source, > * be object oriented > * have a large user base (which helps with many of the above points) > > As you can see I'm not even consedering speed and size anymore. > I'm now interested in how easily I can create and maintain applications. Ditto. Got to say "yes, i can do that", not "i think i can, if i learn a new OS and new programming language *again*". I haveto be thinking of one language, not mixing several languages to get functionality. Kat
4. Re: Euphoria in the past, present and future (was: New Euphoria Users Websit
- Posted by irv at take.maxleft.com Nov 15, 2002
- 431 views
On Thursday 14 November 2002 05:21 pm, Ray wrote: > I'm sure I have read on the list before how the Euphoria source code > is created in such a way where speed is the most important thing. > These days many believe “readability” of source code is more > important so that bug fixes and enhancements can be made more > easily. Is this why Euphoria is so static? Because the source code > is designed for speed and size and not readability and maintainability? > > I'd be interested to hear what offers think Karl and Matthew should be able to comment on this. I've wondered about it myself, but haven't bought the source code because I doubt I would be able to use it. I only know enough about C to hate it. I have seen programming projects which became so convoluted and fragile that no one dared to change *anything*, for fear the entire thing would collapse like a house of cards. Could that be the case? I have also known people who would *never* acknowlege a good idea just because they didn't think of it first. I have a friend who sells plumbing supplies. He's a good businessman. One day, I asked him what he would do if every third customer who walked into his store ordered a hot dog. "Buy a grill" was his immediate answer. Did I mention that he's a good businessman? Regards, Irv
5. Re: Euphoria in the past, present and future (was: New Euphoria Users Websit
- Posted by irv at take.maxleft.com Nov 15, 2002
- 438 views
On Thursday 14 November 2002 05:21 pm, Ray wrote: > When I first started looking at Euphoria 3 or 4 years ago my > requirements for a language where very similar to what Euphoria > offered. (small, fast and uncomplicated). I look at new languages at every opportunity. Originally I tried things which were reviewed favorably in the magazines (if I could afford them), now I try anything I can download from the web. More than once, I have paid lots of money for huge, unusable software, Many times, I have tried small, cheap or free languages which were so limited they really weren't useful for any practical (meaning 'paying') work. Can we say 'QBasic'? So I've always tried to stick with 'middle of the road' languages. Back in 1985, that was Turbo Pascal. Under $100. Perfectly adequate for several years, as long as Borland sold updated versions. Eventually, however, hardware advances and people's expectations outpaced development, making it outdated and useless. Euphoria is another 'middle of the road' language which seems unable to keep up with changing technology and needs. In my part of the world, slow-moving things which stay in the middle of the road are known as 'possums'. 99 times out of 100, they are very flat and quite dead. Regards, Irv