Re: Euphoria in the past, present and future (was: New Euphoria Users Websit
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
|
Not Categorized, Please Help
|
|
