1. Re: My View of Euphoria
On Mon, 8 Feb 1999 00:17:07 -0500, Smith Ray
<Ray.Smith at FUJITSU.COM.AU> wrote:
>I have read lots of discussions about why Euphoria isn't as popular as =
it should
>be, and with the small experience I have gained from using Euphoria here=
are my
>opinions :
>Forget about DOS programming. Its a shame because I believe Euphoria =
(with all
>the extra libraries) is as good and easy to use as any other DOS based
>development system in the world. I'm not saying that it should be =
dropped from
>the package but it will play a very small role in advancing the =
popularity of
>Euphoria.
Disagree. The DOS programming stuff for Euphoria - or at least
the console mode that avoids machine-specific usages - will be
key to getting Euphoria - by whatever name - accepted on other
platforms. Those that have a GUI at all don't generally have
Wintel-compatibility; where they do, it's often incomplete or
compatible with an older version of the WinAPI. Euphoria ports
(peuphoria and/or gnuphoria, plus any future similar exercises)
have the potential to be for other platforms what BASIC was to
the Apple ][ and DOS worlds - a way to make programming in those
environments accessible to the less-technical. Not a bad thing,
IMO.
>Euphoria needs a GUI development environment. A rip off of Visual Basic=
would
>do the trick. I know some people are working on such projects, but as =
yet
>nothing I have seen has come close. To be able to design windows =
graphically,
>set properties, create, test, debug and bind all from a GUI environment =
would
>give Euphoria users real programming power.
This I will agree with. As objectionable as it may (or may not)
be, the world has gone to VDEs, and that's not likely to change
any time soon. A development system that doesn't support a VDE
is not going to be considered any more than a "toy".
>I'm not getting into the 'Structures' argument, but let me just say ... =
they are
>required.
No. They are highly desirable, especially for manipulating
Windows data structures, but I have yet to see a compelling
argument to mandate their availability.
>This next point goes against the Euphoria philosophy but ... shouldn't =
it be
>possible to define set sizes and types of variables. I agree that most
>languages are very restricting in their use of variables and Euphoria =
sequences
>and atoms are very flexible, BUT ... sometimes there are known limits to=
what
>variables can store. Example, if you wanted to use any type of database=
system
>they all contain fixed sized data. Ok, they are inflexible, but what do=
you
>want a programmer to do? Write his/her own database system in Euphoria =
using
>its flexible design. Ok, I'll be back in 6 months, now about a reporting=
tool_
>ok another 6 months.
This is something that may have benefits, but, as with
structures, I've seen no compelling argument to mandate the
availability. In fact, the _only_ arguments I see in favor at
the moment are exactly the same ones as for structures.
>Bigger and better Windows examples are required. People will never have=
faith
>in Euphoria until they can see large complex examples. If I asked the =
question
>... Show me what Euphoria can do? What would I be shown? Now convince =
me to
>use Euphoria to write my next large application. Show me database =
connectivity,
>show me how to produce a report. I know its all possible but Euphoria =
is
>competing with Visual Basic and Delphi and C++, how difficult is it to =
connect
>to a database, write a report and use OCX's in these languages? How =
difficult is
>it in Euphoria?
This is a good idea - I'm sure that if you write a better example
or ten, Robert will be more than happy to include them in the
Euphoria distribution.
Remember, Robert isn't a commercial outfit like Symantec, Inprise
or Microsoft. He almost certainly doesn't make a living from
Euphoria; it probably pays for his beer and pretzels, but not
much more. In that respect, it's like the Linux community - user
support for the product is key. =20
>I have been very hard in my opinions and some might say negative. I am =
aware
>that Euphoria is still a very new language and will improve. I guess =
I'm just
>raising what I see as shortcomings with the product. My opinions are =
business
>development based, but if Euphoria is to be a commercial success it has =
to be a
>Rapid Development Tool able to produce quality software.
You're assuming that Robert _wants_ Euphoria to be a commercial
success (i.e., that this is one of his explicit goals). Convince
me. Better still, convince _him_. Consider both the advantages
to him _and_ the disadvantages - what does it take to run a
company in his part of Canada? How many people will he have to
hire to manage marketing and support? What will it cost him to
go into shrinkwrap production? What's his expected income? What
are the benefits to Joe Programmer of using Euphoria instead of
C++Builder or Delphi or VC++ or VB?
It's been a lot of years since it was possible to design the
killer app on the back of a napkin and create it in an evening of
hacking. It may not even be possible to create the killer app
any more. Do the analysis of risk vs. reward. Then, come back
and critique it again.
>With the current core of talented people contributing heavily I believe =
it will
>get there, maybe not this year, maybe not even next year, but with =
persistence
>it will be a winner.
>I use Euphoria to write small fun windows games, and have had fun, =
(except for
>my HDD crashing I would have posted a couple) but I wouldn't YET =
consider it to
>write a large or commercial Windows application.
Why? Because the development support tools are missing? Hey,
man, WRITE 'EM! I guarantee that nobody will say that you
shouldn't have. That's actually how what we've got developed;
somebody said, "Hey, wouldn't it be nice if Euphoria had this
API?" and then made it so. We've gotten some nice stuff out of
it; check the Archive from the Euphoria home page.
--
Jeff Zeitlin
jzeitlin at cyburban.com
