OpenEuphoria

2. Re: Expanding Euphoria

• Posted by Kasey <kaeyb at GEOCITIES.COM> Apr 26, 1998
• 526 views

MAP wrote:
>
> Okay as I see it, Euphorians seem to be split into two
> camps of beliefs when it comes to many of the discussions
> concerning expanding the language. Some think that
> Euphoria should remain as it is, and that we should all
> invent our own methods to code around any problems
> that arise. The others believe that a few modifications
> could greatly improve Euphoria, and I fall into this group.
> Also, forgive me for making a generalization here, but the
> division seems to fall along the same lines as those who
> view Euphoria as a simple scripting language and those
> who think it has the potential to be a pretty powerful
> replacement to other languages, even for serious projects.
> Perhaps because I'm relatively a late comer to Euphoria I
> missed some of the discussions that brought about the
> "don't touch the language" sentiment.

hmm I'm not shure about how you mean the second line there.
I'm for minimal change Because I see excessive quick fix and
please the masses changes(that you also disparage later) as
dangers to Euphoria bein the Serious language (not scripting
languge) it is.

>
> I've heard often that Robert doesn't want to change the
> language any more than is necessary, and I fully agree
> with that. It's because of this that Euphoria is what it is...
> a coherant language. Too many languages have expanded
> themselves in an awkward manner, throwing in features
> upon features to solve small problems incrementally,
> rather than finding solutions that make sense for the
> language as a whole. The result is an unwieldy language
> with, more often than not, a whole host of
> counter-intuitive rules that the programmer has to deal
> with, causing the resulting program to read more like a
> collection of hacks than the pure algorithms that convey
> what the program is there to do.

yes precisely(and other me-to-isms)!!



> At the other extreme, where some would have Euphoria
> stay, oddly enough lies the same problem still. The lack of
> a few well chosen features. This leads programmers to
> have to code their own solutions to implement them. This
> is fine for small programs, but certainly not ideal for more
> ambitious ones. I feel that structures are a prime example
> of this. I've seen some very inventive methods of doing
> these in Euphoria, yet none of them have the pure look
> and feel of real structures. They still distort the view of
> what is going on in the program, and that is the definition
> of a hack. They force the programmer to adopt more a
> complex view of the program than simply dealing with what
> he or she is there to do.

strange thats how I tend to view most 'structures' (and worse yet
unions). as a confusing atempt to combine a whole bunch of different
type of data into one variable type. way to easy to loose track of
what the program is doing when you see

somthing.or.other

and have to plow back a mile into the code and go through three or four
different variable declarations to figure out what kind of data it is.
 much easier to look at the top of the current function and see

integer other
and know what your dealing with and what the valid values for other is.




> Yes I do realize that programming isn't, and probably never
> will be, about the "purist" ideaology that the academics love
> to theorize about in the classroom environments. Real world
> programming involves getting your hands dirty occasionally
> and facing complex real-world problems that break some
> of the rules for the sake of having a more efficient program,
> or doing things that the language simply doesn't do... that's
> why programmers make the money they do. Yet, in areas
> where Euphoria could implement these purist constructs
> without sacrificing efficiency and ease of use is where I feel
> it should continue to try to grow. The result is an ever more
> powerful language in the end. And one where novice and
> seasoned programmer alike speak the same language.
>
> Well, If you've read this far I've probably bored you stiff
> by now, so I'll try to close up pretty quickly:) I'm simply
> saying that I'd like to see Euphoria continue to mature in
> those areas that can make the language easier to use. The
> language as it is, afterall is about being an "End User" friendly.
> And in many cases, features that promote this wind up as
> powerful tools in the hands of not-so-novice programmers
> as well.
>
> Thanks,
> Christopher D. Hickman


Nope not bored, just wanted to but in and point out that whats more
natural
and logical to some is a confusing nightmare to others, lots of things
that
C and C++ do that so many learned on are not the only way nor the only
style
of how a language has to do things, I first began coding in versions of
8 bit
line numbered basic and very simple assymbly. and others in other styles
of
languages yet (there even some who think cobal and early pascal are the
$#!t)
        I like Euphoria because it's simple and straitforward like the early
languages I started on, yet eleminates most of gripes, and ads some of
the few
truly worthwile (IMHO) ideas from c and other newer language while
leaving thier
gabage (again imho) behind.
        now this realy IS way to long so I'll stop my turn on this soapbox (hey
how did that get there!:).

                        thanks
                        Kasey

p.s. (and befor we go to far, it's RDS's language, not ours)