Re: Why some people have not upgraded
Vincent wrote:
>
> Robert Craig wrote:
>
> Hi Rob,
>
> > This never worked at all with translating or binding,
> > and didn't work that well with interpreting.
>
> Of course it didn't work with translating or binding, and it worked fine with
> interpreting. Now there is my library, but all the other ones are broken. My
> library isn't really dynamic though, it basically restarts the users' program
> with a dynamically updating include list.
Rob's rationale does make sense even if it's a bit disheartening. The
translator/binder and interpreter should act the same so there is no problem with
distributing programs. It'd be way to easy for a user to develop a large
application that uses dynamic includes extensively and then find out that their
program can't be made self-contained otherwise.
> > You can still do this. What are you talking about?
>
> The incompatability introduced with the '$' symbol. I didn't know how to put
> it into words on one line. This wasn't an issue for me, but pissed off a few
> people; Mario Steele was one of them, who now programs with Ruby.
Rob was completely right in changing this. The '$' symbol is a good and useful
optimization that I have now whole-heartedly embraced in my coding since it
allows me to code a lot faster plus make my code run a lot faster. Also, the
newer method makes the logic of the code more evident I think. I have only gotten
an error due to this once and it was trivially fixed.
> > I don't know what that is, but it doesn't sound very valuable.
>
> The include hack was one of the most useful bugs. It gave us ability to
> include
> files with the same name in different file paths. Now Euphoria always treats
> files with the same name as if they were identical regardless of their
> location.
> This would likely cause a big problem if Euphoria ever became popular and
> people
> started to write libraries with the same file names but had different content.
> We'd waste literally hours yearly renaming files just so they could work with
> others and our own. We'd have to do it over and over again with every update
> of the 3rd party libraries.
>
> This issue alone prevents Euphoria from nicely accommodating a large user base
> with 10,000 or 100,000's of contributed programs and libraries. The chances
> for identical file names is very high with that many contributions, especially
> since programmers often use simular naming schemes. This is one of the biggest
> barriers with Euphoria's language design.
>
> You could easily change this in the source, but you just don't want to for
> some
> ludicrous reason.
OK, this I agree with completely. There is no reason that different files should
be treated as the same. This prevents me from "modularizing" my code by placing
includes in different directories. If there were any popular libraries that
needed this and couldn't be fixed easily I could maybe see this "feature" being
kept but I have found absolutely no examples of this error ever occuring. I would
much rather prefer this one little thing incorporated in the next version of
Euphoria than multi-tasking in any form.
(snip)
> > You keep harping about this because you
> > are obsessed with speed, but most people will notice
> > little difference between a program that parses
> > in .1 seconds, versus one that parses in .8 seconds,
> > especially when Windows adds it's own variable start-up delay to
> > any program that you run, written in any language.
> > Over time, the percentage of people using ancient sub-1Ghz
> > machines will decline, and people will wonder what you are
> > going on about. It seemed to be mainly the IDE that people
> > complained about, but not many programs are over 100,000 lines
> > of source.
>
> It's *WAY* more than just the IDE. It's any medium to large size program. It's
> a difference between seconds and minutes on my old systems!! You think this
> isn't a big deal... think again! Euphoria is suppost to run fine on 386-486
> machines, but it doesn't. I can go eat lunch while waiting for a large/huge
> program to load with v2.5 on my 386, and if the program crashes I have to do
> it again! With my Pentium 4, it's a matter of milli-seconds and several
> seconds,
> but that is still significant when considering several seconds is barely
> acceptable
> with today's C/C++ optimizing compilers.
>
> Imagine if Euphoria ever become popular and people started writing million
> line
> programs and librarys, they would load slowly even on fast computers and
> impossibly
> slow on anything less.
>
> I understand your reasoning for the Euphoria based front-end and I really
> appriciate
> the PD-source, but I want more of those front-end optimizations not excuses.
> I tried improving it myself, but didn't have much luck. A mere additional 10
> to 20 percent parsing speed improvement would satisfy me.
Vincent, develop a few thousand line Perl application and you'll beg for
Euphoria's speed. Yes, there is a slowdown in the 2.5 interpreter and yes, it is
noticable but it's still faster than everything else I've used. Also, if this
allows Rob to make bug fixes and changes to the language easier than I have no
problem with it. However, I've used it for serious DOS programming on embedded
devices and have had no serious problems speed wise.
> > Execution could sometimes
> > be usefully performed before parsing was complete,
> > allowing it to happen slightly sooner, while not
> > catching syntax errors later in a program, and requiring
> > all front-end data structures to be kept in memory during
> > program execution.
>
> Other than the slow down it causes, I have nothing against the new parsing
> method
> and actually see benefits with it. It's just some others might not, thus I
> listed
> it.
Disregarding the slowdown I think that's a fairly stupid reason to include that
on this list. If a user is too ignorant to upgrade for this reason alone then I
wonder if we should even bother trying to get them to upgrade at all.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
|
Not Categorized, Please Help
|
|
