Re: fixed windows
On Tue, Aug 05, 2003 at 04:02:17PM -0500, gertie at visionsix.com wrote:
On 5 Aug 2003, at 19:51, Peter Willems wrote:
>
>
> Hey Kat,
>
> gertie at visionsix.com wrote:
>
> <big snip>
>
> > 1) executing strings
>
> You might need it, I don't.
And you are saying since you don't need the option, i should be forced to do
without?
If he is saying that, I would say he is wrong.
> > 2) goto
>
> Please no ! In my pov only hobby programmers need goto. That is
> why many pro languages don't have it. There is nothing I can do
> with goto that I can't already do without (but yes, you need to
> do some "engineering" before starting to program).
Yes, stop thinking of the program and it's flow, and engineer a workaround
that the programming language will allow.
> > 3) threads (including threaded timers)
>
> Agreed. Multi threading can help with several applications.
> Nevertheless, the current tool we use in my company also don't
> have multi-threading and still use it to develop for multi
> nationals and to their satisfaction.
So again, you don't need it, so i can't have it.
Again, i would disagree with him then. (Just because he doesnt need it
doesnt mean it shouldnt be in there).
> > 4) event handling
>
> There is a full event-driven library in the archive.
Not quite what i wanted, i don't see it doing:
on error:*sequence lengths not equal*: { code here }
Thats not event handling, thats error catching.
> > 5) native socks support (you can http/telnet/pop3 with mirc too)
>
> I have no problem in it not being native. It's a library in most
> other languages as well.
Sure, Eu has such libs also, and every one has drawbacks. You can do x in
one, but not in the other, whch can do y.
Sounds like Eu just has more options.
> > 6) easy as heck gui support
>
> Now here is where your comparison with mIRC goes completely wrong.
> mIRC is a application with a userface that can be driven with it's
> scripting language. That is com[pletely different from a language
> that is USED to build that user interface (I already stated that
> mIRC, including it's user interface, is not written in it's own
> scripting language).
And you think Eu is written in Euphoria?
JTLYK, It can be: see eu.ex
Anyways, his point is explained futher below.
> Let's be honest, there is no GUI developer in mIRC that generates
> code that can then be executed without running mIRC's own FULL
> user interface.
Wrong. You can generate child windows that have their own button in the
taskbar, move independantly of the main mirc window, etc.. Besides, i
WANT the full language available to me to run the code i write. The display,
in any font i can download, in any point size, in any color, at any point, with
full mouse support, is a plus.
But you still need the whole of mirc loaded to do that. You can't get rid of
the main mirc window. I think thats the point being made.
> > 7) no var instanciation required
>
> No comment on that.
>
> > 8) no crash if a var has no contents in a boolean test
>
> Ditto..
By your previous tone, i suspect that means you are against them. So far,
you are against everything i suggest but threads. How unexpected.
> > Bach:
> > 9) classes
>
> I'm glad Euphoria is NOT object oriented in it's own design.
I don't actually like the way classes are in Bach, but it seems others do. I
want *full* variant records, with overriding.
> > 10) crash catching
>
> Agreed. But that is not specific for mIRC OR Bach.
It's possible to recover in mirc, to a point. For instance, i can type:
/msg cs addop nick 3
which is an error, and which i can script to correct before it finally errors
out.
Hey, I can write code to catch almost all runtime errors in Eu as well!
Just wrap every single builtin routine and do tons of checking and only call
the real builtin if everything looks ok, else abort out. (Note that errhandle.e
actually does this. It also provides routines to replace the builtin operators
and a function to wrap the tests in an if or elsif or while statement to prevent
crashing there.)
(It would be better for the support to be builtin no doubt, due to overhead,
but I'm just saying ... ;)
> > 11) gui support
>
> Don't know what Bach has over Eu in this regard.
Size. Open source, for nix and winders.
I wonder if IUP could be wrapped for normal Eu *shrug*.
> > 12) block comments
>
> We're discussing that in depth already, so you know my view on
> that. Seems I'm not alone on this point either.
>
> > 13) slicing shorthands
>
> No idea what that's about 
I'm sure you won't like it, and will vote to keep it from me in Eu.
> > 14) better include paths
>
> Clarify please ??
Bach introduced looking in the application's own /include subdir, not just the
interpreter's /include subdir. And other places.
> > These 14 items are things BobC has said will not appear in Eu. The
> > closest
> > app i have seen coded in Eu that might enable all the above is AGetz's
> > window server and Jiri's associated lists. And several string libs are
> > required
> > in my opinion, string.e and strtok.e, and the file manipulation libs
> > like file.e,,
> > and for any windows gui, you must have win32lib.
>
> That is your idea of how Eu should be developed, mine is different.
> And other users might still have yet another pov. Don't forget
> you are not the ONLY user.
Golly, really? Are you the only one who matters then? If Robc includes goto,
you think throngs of mad programmers will descent on you next fullmoon and
force you to re-write all your code with goto?
No, tho he might be forced to deal with unreadable goto's in other's code.
The idea of not having goto support, is to replace it with better controlled
and restricted "goto"s which prevent the unreadablility. Whether or not this
is a good thing depends on the skill of the programmer, the level of difficulty
of the language overall (i.e. if its asm code then a goto or jmp isnt gonna
make it that much more unreadable), and personal opinion.
> > If RobC can't handle the full developement of Eu,
>
> .... the way YOU think he should do it.... right ?
It's already apparent he is out of time, whether i say anything or not. I think
you are a great example of the pot calling the kettle black.
LOL!
> Kat, the bottom line is that I might (but shurely will) use Eu
> for completely different tasks then you. And other people might
> use it for yet completely different tasks. That is why Euphoria
> is a GENERAL PURPOSE language while mIRC is a tool dedicated to
> a very (VERY) specific application area.
Mirc is hardly restricted to "a very (VERY) specific application area*. Just
because it has one screen format for irc does not mean it cannot just as
easily handle other tasks. What you are saying is like saying feet are for
walking with, and if you have no feet, you cannot move at all. Or feet should
not be used to play soccer with. Or hair should be worn the way you say,
and worn any other way is confusing.
Or perhaps hes just not as creative in using mirc as you are. IIRC, you said you
have done things w/ mirc that the creator didn't think was possible.
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
|
|
