Re: Homosequences - Start Again
Robert Craig wrote:
>
> CChris wrote:
> > The only consistent plan I see in the discussions is: hey, don't change
> > anything.
> > Otherwise, as you say, it's just a collection of individual needs which are
> > more or less shared. Trying to discuss things at a higher level elicits a
> > "too
> > complicated" response, which is almost equivalent to a death sentence on the
> > topic being considered any further. I've never seen this "too complicated"
> > thing
> > anywhere else.
>
> What other forums do you participate in,
> where things are very different?
>
Eiffel, FreePascal, to quote the ones I'm currently browsing or on which I post.
I still have to look at the D thing as well, I wish I did it earlier.
> > As I have said in the past, one of the main issues is that there is a small
> > group of say 20 regular posters (often quite less) at any given time. How
> > this
> > group is representative of the hopefully larger user community is a mystery.
> > In theory, Rob may have clues - if any feedback is emailed, it will be at
> > RDS.
>
> When I was still getting registrations, 80-90% of the people
> who registered were people who had never posted a single message
> on EUforum. These days I still get email from people who never post here.
> However, I now have less of an idea of how many users there are "out there".
>
> Most people are not keenly interested in language design,
> or even if they are, they don't feel qualified to comment
> on ideas put forward by people who have been using Euphoria
> for many years, have gone through the source code, etc.
>
> Most people do not have problems in using a relatively
> simple language like Euphoria, that require
> clarification on this forum (assuming they even have
> the required English skills to post).
>
Very true. However, they can tell you if they are happy with it, not to tell you
if they are not, and ask naive questions which could help you in future
decisions. As I said, if anyone has clue, it should be RDS for obvious reasons.
> > Euphoria was designed as the fastest possible interpreter
>
> True to some extent.
And it has succeeded in that area.
>
> > - makes sense on 40MHz machines, perhaps less today.
>
> People will always value performance, perhaps not in an
> individual program, but when deciding what language
> to invest their time in.
>
> The first PC that I ran Euphoria on was a 486 50 MHz machine.
> When that machine first came out, I remember reading an
> article that speculated that only professionals in certain areas,
> and other "power users" would ever need that kind of speed.
>
> With faster machines and huge memories, you could also argue
> that fewer will use C/C++, and more will want something easier
> to learn and debug with, like Euphoria.
>
Some people at M$ assumed that 640kb was well above the ordinary user's need 
People will always value performance. Except that, when speed becomes high
enough, performance is no longer an issue in 80% of cases and other aspects may
come into play. You hardly care if some routine takes 2200 or 640 nanoseconds,
except when you call it in a loop. And people critically in need of speed will
use a lower level language anyway, be it C or assembly. This is why I am not 100%
sure that, for non CPU intensive code, cutting edge performance in Euphoria is as
important as it was 10-15 years ago. Even more so now that the Translator is
public.
> > It was designed for the installer to fit on a
> > floppy,
>
> Not true.
Did I dream this up? I'll check the "propaganda" texts...
>
> > but machines may no longer have a floppy drive today.
> > Consistency with "business models", or user's native task/problem
> > representation,
> > is quite absent - except when that model happen to match the heterogeneous
> > sequence
> > pattern -. What matters is less many keywords and thinner docs, it seems.
>
> One of the main goals, was to make a simpler language
> that amateurs, hobbyists etc. could easily learn and use.
> It was never my intention to compete against C++ and Microsoft
> in the professional arena.
>
Nor mine, although I think Eu could be easily far better, the potential is
there. And the "easy to use part" is debatable in some areas. EuForum is full of
detailed accounts about them.
> > > If the solution were considered at a higher-level, it would be the sort of
> enhancement</font></i>
> > > that elevates the language to another plane – not just sugar.
> >
> > 150% agreed.
>
> Then propose something that will truely take Euphoria "to a higher plane".
>
* Check how the type system could accommodate a couple "machine" types to speed
up a variety of things.
* Design a fully integrated scoping system which makes the promise of modular
programming in Eu come true, without leaving supposedly corner cases that
supposedly no one will ever need.
* Start considering a reentrant front end/backend pair, so as to allow a variety
of dynamic constructs which are expected from an interpreted language, and
probably reduce the load time of large (GUI) programs as well;
* Start investigating the possibility of plugin systems, in applications first
(perhaps using conditional include statements), then if possible in the language
itself. This will allow those who like it bare bones to have it bare bones, and
those who like it cheesier to have it too. Instead of adjusting your learning
curve to the language, adjust the language to your learning curve.
* Upgrade to decent debugging facilities, featuring dynamic breakpoints and
expression watch most urgently.
Just some ideas I have/have started to work on, there are probably many more
useful things to do. For the most part, they can hardly be one man's spare time
projects. Open cooperation would be critically needed.
> > > Another completely different example. When a proposed new function is
> > > discussed,
> > > the discussion starts with an implementation, someone else comes up with a
> > > different
> > > implementation with different parameters and/or return values, someone
> > > else
> > > starts talking at the machine-level about how fast it will be if you run
> > > it
> > > in a million-fold loop, and someone else says it's all crap, etc, and each
> > > person
> > > seems to have a proprietary interest in his own implementation or idea.
> >
> > You forgot adding that then the discussion dies without any decision being
> > recorded.
>
> OK, from now on, I think anyone who is serious about a proposal
> should eventually, after a period of discussion and analysis,
> write a summary of his/her (revised) proposal, and call for a vote.
>
> People can vote by posting a message here.
> Voters should clearly say "Yes" or "No", and can give
> an optional, very brief (one or two sentence)
> reason for their vote.
>
Thanks! That's certainly a good thing to do.
CChris
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
|
Not Categorized, Please Help
|
|
