1. Re: Muhahahaha
So as to keep Jiri awake since we've obviously been boring him to death
(Hi, I'm Sherm, and I'm a Euphorian. Let me tell you about my conversion
experience. I was sitting alone at my computer one night, Jolt cola in
hand, dreaming of Cindy Margolis and a Snickers bar, when suddenly there
was this flash of light.....)
Seriously....
The thousands of lines to create a GUI point would be a good one, except
it's flawed.
The statement:
********
...in Euphoria you have to write THOUSANDS of lines of code just to create
a small Hello World Windows app, and in VB you write 0 lines for the same
purpose! Win32lib does not count because it is not part of the language,
and even so still incorporates thousands of Euphoria lines to create a GUI
interface, proving me correct anyways.
********
What about the HUNDREDS of thousands of lines of code in VBRUN***.dll,
without which NO VB program will run at all? If you exclude one, you must
exclude them both. The same goes for even a C program written in something
like C++ Builder or Delphi - both must use "redistributable" files which
dramatically increase file sizes. In Eu, I have yet to build an executable
over 200k - though admittedly I'm just building "toys". But those same toys
in C++ builder were twice as big. Not to mention that I occasionally
brought down the program through some access violation I wasn't able to
track.
It's simply a fact that if you're going to do Windows programming EASILY,
there will be overhead. If you want to access the windows API directly
(good luck) then you can do it, but it's complex and you CAN'T do it in a
few lines, even in ANSI C. If I'm wrong, I'm from Missouri - show me.
Another point was about the speed of the interpreter, and it is a decent
point. Doubt Eu EVER gets to the speed of C. Doubt C EVER gets to the speed
of assembly. I, at least, would MUCH rather program in Eu. I can much more
easily see my errors, and I'm MUCH less likely to crash my program and my
OS through some stupid access violation or something. I SAVE more time in
programming than I LOSE in execution.
Will Eu be suitable for say, rendering MPG video? Doubtful. But I doubt C
would be optimal either; a renderer like that should probably be optimised
in assembly. Will Eu ever be used to write Quake? Probably not, though at
some point, the graphics cards and processor speed will make up for the
execution speed. At current processor acceleration rates, that might happen
in 3 years or less. How many FPS do you REALLY need?
One thing you left out of your comparison though: size of development
environment. The Eu development environment (such as it is, <sigh>) is less
than 2 megs. VC++ never even MADE it to my machine because the minimal
install I saw was 30 megs. C++ Builder (which I like) is 100 megs installed
on my machine. If I were doing it today, I don't think I would put it on
even at a minimum install of around 30 megs. As HD prices fall, it's less
of an issue, but 100 megs is a couple of minutes of rendered video for me.
I'm an engineer, not a programmer. I don't CARE about PS/2 or N64, or
making Quake, or getting the last 2 milliseconds out of my code. I want an
environment that lets me develop fast, lets me concentrate on my LOGIC, NOT
my code, makes pretty pictures on the screen for my UI, and can do WHAT I
want correctly. Eu does all of that. I'm not simulating drug interactions,
or rendering video (not with Eu, anyway), or even simulating car crashes.
I'm automating a few tasks, maybe exploring some data through a few
transformations or something. Eu does fine for that. MUCH better than C,
assembly, Java, Python, blah blah blah.
Not that Eu doesn't have shortcomings. It does. We've talked about them a
lot, but didn't get anywhere (which is itself a shortcoming). Thanks for
reminding us. Now, what do we DO about it, without reverting to C or VB?
