RE: Eu's poor design
Hello Andreas,
Although I have decided against Euphoria (currently) as a viable
option for professional development, I have some remarks to make
here.....
Andreas Rumpf wrote:
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
I do agree that it is not there yet, but for different reasons.
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
OK, but.....
> So for real applications I would use global variables all over the place
>
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
If that is a great aprovement over "call by reference" then why
do you need "call by reference. Your stament is confusing.
And the lack of such an option doesn't mean you can't write
serious or professional applications with it.
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly.
Maybe, but.....
> Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
Where is it stated that Euphoria is a functional language.
And if it is not a functional language (which I think it isn't)
then why would Rob have to "understand functional programming
properly" ?? I have no idea why you are stating this.
Besides (and again) this has nothing to do with the usability of
a language for serious tasks. Most used languages are NOT
functional languages. C and C++, Python, Perl, Java, etc. are
NOT functional languages. Prolog, Haskell, Erlang, Clean and the
likes are functional languages but apart from Erlang, most are
used in research and not in enterprise applications.
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time.
This has been discussed before. Every good programmers editor
handles this for you. Btw, if you are on windows I recommend
you take a look at PSPad. I use it currently for my Euphoria
coding and it's the closest to a real IDE.
> Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
>
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
Why would # be better. Just because other languages use it ??
There are other languages that use -- also. Besides, tmo -- gives
much better readability as it stands out much better. Take a look
at any big chunk of PERL code and you know what I mean.
But more important, what does this have to do with using a language
for serious tasks. I've never heard of any case where the token
used for comments had any influence on the resulting quality of
the application.
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
I think it's stated clearly in the Euphoria docs that they are
available for those that want to use them. I also recall that it
is adviced in the docs to STAY AWAY from those statements as much
as possible.
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
Yes, and that way you are forced to actually *learn* the language.
Oh, and using PSPad, I just add function names to the language
definition for the highlighter and it shows me when I'm forgetting
the correct case.
But again this does NOT impact the quality of the programs that
can be written with the language.
> I used to use hashing a lot. Guess what, in Euphoria most hash functions
>
> can't be implemented (or only with poor performance!), because integers
> don't wrap around but are converted to floating point when they get to
> big!
Wrapping integers can be a big PITA in several other applications,
especially business oriented calculations.
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
Euphoria as a language is very well suited for serious large
projects. The points you make here are of non importance when
a company (like my own) is deciding on a development platform.
There are other more important issues that prevent the use of
Eu in serious (commercial) projects and it's mainly about the
lack of stable libraries for business applications. Stuff like
GUI handling and database access is available but far from the
level of stability and functionality that I need to deliver for
contract work for my clients. But the points you mention are of
no influence on the functionality and stability of a business
application.
Hans Peter Willems
|
Not Categorized, Please Help
|
|
