Re: fixed windows
On Tue, Aug 05, 2003 at 02:06:16PM -0500, gertie at visionsix.com wrote:
<snip>
> In a word(s):
>
> mirc:
First, mirc will not run in Linux, FreeBSD, or DOS. So such a merger between
Eu and mIRC would make Eu Windows-only. So a comparision between the 2 is
not really far in terms of portability. Also such a merger would be difficult
when using the translator. (If you say that you don't need these features of Eu,
then I have no choice but to call you a hypocrite, since you believe you
should have the below features even if others don't need them. I'm sure
there is a compromise to be found in there somewhere ;)
> 1) executing strings
Not builtin. DC and Matt Lewis have given us the option as an addon lib tho.
Cost: speed.
> 2) goto
Well, Dredge has that ...
Beyond that, I say no more ;[
> 3) threads (including threaded timers)
Have it (for linux).
Cost: speed and memory (and quite a bit of complexity). Also, with my
*emulation*, its not as fault-tolerant as real threads would be.
> 4) event handling
Have lots of libs for that.
Cost: speed, also no major lib so potentionally much confusion.
> 5) native socks support (you can http/telnet/pop3 with mirc too)
Why does it have to be native? Very few languages have it "native".
Cost: none that I can think of atm.
> 6) easy as heck gui support
At a high overhead. But it may be well worth the cost, depending on your
POV.
Cost: personally, i think the mirc way costs more.
> 7) no var instanciation required
> 8) no crash if a var has no contents in a boolean test
Dredge has these 2.
I think that Eu would do well to have these 2 options in it as well.
Cost: using Dredge gives a huge overhead, both in the compile stage
and in the run-time (due to the hacks required).
>
> Bach:
> 9) classes
Have lots of libs for that.
Would be nice if there was a simpler standard syntax for Euphorian OO tho
(as there will be for OE).
Cost: builtin would make the interp slower, external lib would make OO slower
+ lack of syntax (or use of preproc to get that) makes it clumsy to use.
If syntax were builtin, then I'd say the cost would be greater for OO to be
totally builtin into the interpreter (see OE notes on its proposed OO support
for a better explaination on what I mean).
> 10) crash catching
I have an errhandle.e that makes a meek attempt to provide this, but it has a
HUGE overhead ... this is a must.
Cost: using errhandle.e is too slow, and not using it means programs can't
have crash catching periond so they arent as robust.
> 11) gui support
Bach's GUI IMO isn't the best. Also, must GUI support be builtin?
Cost: I don't know enough to say.
> 12) block comments
A niceity but not a necessity.
Cost: more typing
> 13) slicing shorthands
Ditto.
Cost: more typing
> 14) better include paths
Yes, again a must.
Cost: possibly more typing, possibly much confusion for the programmer (on how
to get the right file to always be included).
<snip>
>
> Kat
>
jbrown
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
|
Not Categorized, Please Help
|
|
