Re: Is Euphoria's beauty enduring or fleeting?
Gordon Webster wrote:
>
> I agree with the point that Jason made about Euphoria code being beautiful.
>
> I rediscovered some of my Euphoria code in a dusty directory after more than
> a year and I was amazed at how clean, clear and legible it was. Even at first
> glance, I could pretty much read it as if it were a text specification for
> the code rather than code itself. Try doing that with C or C++!
I myself had the same had the same thing happen to me. Before Euphoria I
programmed primarily in C, Bash, Perl, BASIC, and Matlab. I didn't comment my
code much back then and going back to any of that code after a week or two would
be torture. With comments it was a little better but you don't comment the little
one-time scripts you write to search and move files around and such. Euphoria's
syntax is so neat that you actively have to try, it seems, to write obfuscated
code. In Perl, it's the opposite.
<snip>
> When they finally did, it was too little, too late and Leica are now in
> virtual receivership because the photography world embraced the new
> technology and embraced the companies who could provide it.
>
> I would hate to see Euphoria, a superb tool for crafting computer programs,
> follow the same path through rigidity or a reluctance to evolve.
>
> Thanks for bearing with me.
>
> We now return to your normally scheduled programming ...
I think everyone here would agree with you. Rob's reluctance to include every
feature under the sun is certainly justified (we don't want another Perl) but he
sometimes takes it too far. Unless Euphoria's completely open-source it won't get
taken seriously in the scripting/*nix community and it lacks the features that
professional software developers require. Due to it's nice, readable syntax it
would go better in the professional software development langauge catagory than
the scripting language catagory but the include file issues (files in different
directories are considered the same, no local includes, can't include a file
twice under different names) severly hinder it's adoption. Another issue is
threads and thread-safety. I personally have never used/needed "threads" in
anything other than my operating systems class but other people do use them a lot
and while giving Euphoria users access to syntax to use threads is a horrible
idea (at least for now) since it'll just add complexity and extra commands to the
langauge but making the interpreter thread-safe (so it can be used with thread
libraries) would be very beneficient.
However, as a counterargument to my statement, why isn't Eiffel bigger than C++?
C++ is, for the most part, THE language for professional software. Sure, some
people use VB, Java, Delphi, C, or Objective-C but most of them use C++. C++ is
ugly, convoluted, inconsistent, hard to debug, and very powerful. Eiffel is what
I would imagine an object-oriented Euphoria designed specifically for robust
software design could look like, it's clean, easy to read, and as powerful as
C++. So why isn't Eiffel bigger than C++? People constantly debate this but many
say that the lack of a good open-source Eiffel compiler (although SmartEiffel is
around know) and it's restricted syntax are the two biggest point against it.
Also, C++ has been around longer (though not by much) and builds on an even older
language everyone knows (C) where Eiffel looks almost completely new. Almost
anyone can read an un-commented Eiffel class and get a basic understanding of
what it does but if you asked a professional programmer that uses VB or Delphi to
look at a commented C++ class they might not have a clue what it does. So,
perhaps maybe other things are needed to hit the "mainstream" in regards to
programming languages.
|
Not Categorized, Please Help
|
|
