Re: Is Euphoria's beauty enduring or fleeting?
- Posted by D. Newhall <derek_newhall at yahoo.com> Jul 15, 2005
- 477 views
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.