1. RE: What we really need...
Maybe some of it has to do with the web site? I personally think that it
could use a bit of tuning up, and that it doesn't look too hot right
now. You can compare it to the resources like www.perl.com and
java.sun.com. You can go there and immediately they look more
established because of their web presence. Their languages could be
pieces of crap, but perl.com especially immediately has more reference
material and white paper than I can shake a stick at.
I think improving the web site may just help draw more people into those
"Download" links than one might expect. Just my two cents.
~Tom
-----Original Message-----
From: irv at take.maxleft.com [mailto:irv at take.maxleft.com]
Sent: Tuesday, November 12, 2002 4:04 AM
To: EUforum
Subject: What we really need...
Do we need a 'killer app' to make Euphoria more popular?
I say no.
No, because most people do not know or care what language their
applications are written in. Would you stop using your favorite and most
productive app just because you discovered that it had been written in
VisualWhooPas-2.0?
Didn't think so.
No, because any competent programmer knows that any app can be
written in any language. What matters is _how easily_ it can be written
in a given language.
What DO we need?
To make Euphoria more popular among programmers ~ who else is going
to use it? ~ we need to honestly evaluate where Euphoria excels, and
where
it fails. RDS has done a good job of emphasizing Euphoria's strong
points:
speed and simplicity, but speed and simplicity apparently aren't enough.
Consider Perl, Python, Java, Ruby, Rebol.....
Euphoria is smaller and faster than any of the above.
Euphoria is more readable than perl or java, and (arguably) python and
ruby
as well.
Yet perl, python, java and ruby each have 10, 100, 1000 times as many
users
as Euphoria. Why? If you really expect Euphoria to be more popular,
you'll
have to be able to answer that question.
Let's see what you think.
Regards,
Irv
==^^===============================================================
This email was sent to: thomas at columbus.rr.com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
2. RE: What we really need...
David Cuny wrote:
[snip]
> My conclusion: both occupy a niche that there doesn't have a lot of
> demand.
> People seem to prefer more features and bloat over faster execution. The
> same
> features that make Euphoria attractive to the current user base make it
> unattractive to the larger programming community.
>
> Is this necessarily a problem to be solved? As long as the user base is
> sufficient to support Robert, I'm not sure that there's an issue here.
>
> -- David Cuny
I agree ... developers aren't worried about bloat, who cares if it's a
10MB (or even 50MB) download to install a development system.
Who cares if the software you write needs a 5MB or 10MB install and will
only run on a PII PC with 64MB ram (except Igor :)).
I'm becoming a Python advocate ... and everyone says Python is very very
slow ... full blown applications are written all the time in 100% Python
without speed issues.
Google is (I beleive) mostly written in Python.
The speed and memory of PC's and the speed of the internet are all
expanding faster than bloat and slow speed of development tools.
THE REAL ISSUE IS ...
How easy (or difficult) is it to develop my apps.
This is the highest priority for developers when deciding on a
development tool.
All other issues are secondary ... speed, size, etc
Ray Smith
http://rays-web.com
3. RE: What we really need...
irv at take.maxleft.com wrote:
[snip]
> Consider Perl, Python, Java, Ruby, Rebol.....
> Euphoria is smaller and faster than any of the above.
> Euphoria is more readable than perl or java, and (arguably) python and
> ruby
> as well.
The reason???
Perl, Python and Ruby are 100% free and open source. Many people add
features, apply patches and make improvements. Because they are open
source they exist on almost every OS ever invented!
Java is being developed, supported and promoted by almost all the big
computer companies in the world. Probably hundreds ... no ... thousands
of people are involved in its development and promotion.
Lesser issues but still important ... there are basically no tutorials
or documentation to help people learn to use Euphoria.
One killer app won't make a difference ... maybe 10 solid apps would.
I like Python ;) ...
When Python people say Google runs on Python, or these 50 commercial
web sites, or these 100 commercial applications are written in Python
it matters.
I dare anyone who hasn't looked at the Python code repository ...
the "Vaults of Parnassus" (http://www.vex.net/parnassus/) to go there
and tell me they aren't impressed.
Or browse the online builtin module list of Python at ...
http://python.org/doc/current/modindex.html
Want to connect to any of the databases at
http://python.org/topics/database/modules.html
using a standard API?
Anyone interested in web programming http://python.org/topics/web/?
This is the work of many dozens (probably hundreds) of people over a
very long period of time. As a note ... much of this work is done in
a commercial environment and given back to the community because
Python was given to them!
The current Euphoria business model will never compete with these
languages. Anyone who wants Euphoria to be anything that it currently
isn't will be very disappointed.
Saying all that I still like Euphoria,
if Euphoria can do the job you want that's great,
if it can't do what you want and "you personally" can't make it do what
you want, then it most likely won't do what you want in the near future.
Everyone makes their own choice.
My comments might sound negative (and they are) ...
nothing I have seen in the last 3 or 4 years makes me believe Euphoria
in the future will be anything different to what it is now.
(Yes the number and quality of Euphoria libraries are improving but
at a slower rate than the competition ... it will never catch up)
Ray Smith
http://rays-web.com
4. RE: What we really need...
>And considering that the majority of Eu's new users, are novice
>programmers, there is no learning materials available.
Refman.doc and Library.doc provide quite sufficient information about
Euphoria. As for the novices you're talking about; what they need is
probably info on programming in general (the concept of variables,
flow-control, subroutines etc), and I don't see that as "our" responsibility
to provide. However, maybe RDS ought to simplify for those wanting to do
Win32 programming by shipping win32lib and an IDE (Judith's or an own-made)
with the Ex/Exw package.
5. RE: What we really need...
> > Maybe some of it has to do with the web site? I personally think that it
> > could use a bit of tuning up,
>
> Isnt that funny, I said the very same thing years ago.
> Get rid of the "PINK" on the site and the "Gay" swash
> that resides around the Euphoria name. and things may pickup
> BTW, No offence to the openly Gay community.
Naa, some of my most popular sites which contain really top notch
software that I frequent have *horrible* websites. I dont *go* there
for the web site. I go there for the software. I could care less how a
particular page looks.
> 10) And Don Phillips EuNexus Project or MEdit
> a) ofcource Don would need to get rid of that MSC .dll he uses
a) <<-- Hah! Fat chance =)
Main reason why... convenience. Win32Lib does a superb job of hiding
the details of what is going on behind the scenes. API programming is
not for the faint of heart. There are more constants, data types, and
structures than you can shake a stick at. I have one file at home
*one*, which is about 55k full of nothing but constants. Nothing else.
Point? It is easier for me to code API in just about any other language
than Euphoria because of structure support. Heck, the top three
assembly languages I use all have structures. I find it unfortunate
that Windows is so reliant on these things. I find it even more so that
Euphoria does not directly support them.
Trying to program API structures with Euphoria is like pulling teeth.
If done directly via peeks and pokes, its nice and fast. Its also hard
to read and maintain. You can use a library to hide the details (many
to choose from; I even have my own), but you trade readability for
speed. I needed both for the editor portion thus the code resides in a
DLL.
6. RE: What we really need...
irv at take.maxleft.com wrote:
> Consider Perl, Python, Java, Ruby, Rebol.....
> Euphoria is smaller and faster than any of the above.
> Euphoria is more readable than perl or java, and (arguably) python and
> ruby
> as well.
>
> Yet perl, python, java and ruby each have 10, 100, 1000 times as many
> users
> as Euphoria. Why? If you really expect Euphoria to be more popular,
> you'll
> have to be able to answer that question.
>
> Let's see what you think.
> Regards,
Irv:
You will also notice that most of the above langauges are included
with the common distributions of LINUX.
Bernie
7. RE: What we really need...
> Ive been writting in C and using Masm32 myself and this Euphoria snippet
> is what I use to make code smaller and faster. Just a very small snipp..
>
> constant
> sizeof_trm = 32 -- Size of trm structure
>
> atom trm
> trm = allocate(sizeof_trm)
> mem_set(trm,0,32)
>
> constant
> trm_Op = trm + 0, -- Tsunami operation number
> trm_File = trm + 4, -- Tsunami file handle
> trm_DataPtr = trm + 8, -- Address of data buffer
> trm_DataLen = trm + 12, -- Length of data buffer
> trm_KeyPtr = trm + 16, -- Address of key buffer
> trm_KeyLen = trm + 24, -- Length of key buffer
> trm_KeyNo = trm + 28 -- Key number
>
> ->>>> is definatly better than
>
> trm_Op = allocate(4)
> trm_File = allocate(4)
> trm_DataPtr = allocate(4)
> trm_DataLen = allocate(4)
> trm_KeyPtr = allocate(4)
> trm_KeyLen = allocate(4)
> trm_KeyNo = allocate(4)
>
> and then peek4( ) each time you need access to a particular part of the
> struct sucks.
> Also, when you peek or poke a value you eliminate the extra "addition"
> (+)
> required
> e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start
> of
> your proggy.
>
> Maybe this is hard for some to understand but for me this seems easier
> and
> besides
> is obviously faster with less messy code.
Yes, that method (besides maybe immediate values) would be the fastest
you can get. However, while this might be the fastest, it makes it
harder to use as name reuse is not possible defining constants in that
manner. This is a fine practice (imo) for your own structures or simply
several wrappers, but for something like the API I dont want to have to
constantly have to go back and forth to find which constant I used for
which definition. I would like the names to be exactly the same as in
the API reference so I only have to look them up once.
Doesnt really matter though. I can program either way with almost no
slowdown at all. Besides, I created a new library for myself which
deals with exactly this problem. I plan on using it in all my future
proggies that I submit so its really a non issue.
Masm32 is nice and simple. I (now) prefer FASM over Masm32 now that I
completely understand how the stack frame works and how I can manipulate
it. I post to the board all the time. You probably seen alot of my
posts over there and didnt even know it :P
Don
8. RE: What we really need...
> Naa, some of my most popular sites which contain really top notch=20
> software that I frequent have *horrible* websites. I dont *go* there=20
> for the web site. I go there for the software. I could care less how
a=20
> particular page looks.
You may not go to the web site for the web site itself, but I tend to
see a web site like the front of a building. If you see a fa=E7ade that
looks like it hasn't been touched for 5 years, it's not going to matter
that there are freshly baked cookies behind the broken glass and spider
webs.
I think that if we can get a better layout for the site that promotes
the archive, support (chat and forums) and learning materials a bit
more, then there's a better chance of people staying at the site and
learning more about the language before pounding into the download link
thinking it's a miracle language. It's not, but it *is* extremely
powerful.
~Tom Reinhart
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
=20
