Re: About speed
ken mortenson wrote:
> Most speed issues can be addressed by more inline code. It's the last thing
> I would optimize for because generally it means making your code less
> readable. I haven't used or missed gotos in decades.
>
> I could recode the example with the additional constraint of no calls, but
> the result wouldn't be something I'd normally do.
I completely disagree. If I don't care about execution speed, then Euphoria
is probably not the language best suited for the project at hand.
Euphoria has had exactly two primary selling points since it's beginning:
1. It runs faster than any other interpreted language on the market (and
faster than most compiled languages), and
2. It has a minimal command set leading to a short learning curve.
Both points have been debated ad infinitum over the past decade and a half
as to their accuracy, but nevertheless, they have been the points which at
least drew people to investigate the language (that and the clever use of
search engine keywords). The second point is passe. The first point remains
valid.
I stick with Euphoria because it's faster to code in and faster to execute
than Java. Remove either of those, and Euphoria no longer has a niche to
play in. If you want Euphoria to look like Python, then save yourself the
effort and just use Python - it's already been developed. If you want it to
be Lua, then just use Lua - it too has already been done. If you want to
use Euphoria, then use it for what it is. Improve it slowly - it isn't
perfect, and never will be. But don't sacrifice what makes it unique in the
process.
|
Not Categorized, Please Help
|
|
