1. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 409 views
gertie at visionsix.com wrote: > So the mirc nicklist and channel window are just fixed (but changeable > and > detachable) child windows in the parent ! That explains how it is > possible to > move each channel out of the mirc application screen and out onto the > desktop. Just think where Eu would be now if RobC had merged Eu and mirc > > functionality way back when i first suggested it. Eu would look like > Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there. Kat, I've seen your remarks about mIRC before and I don't get it. As far as I can see mIRC is an application that handles the IRC protocol. It has a build in interpreter to handle scripting inside mIRC so all kind of stuff can be automated. mIRC is definitely NOT a multi-purpose programming environment. Having said that, I think it is very much possible to implement IRC functionality with Euphoria, and creating a library that can understand mIRC commands and run them as a Eu program should be possible also (although I think it's a serious undertaking). One thing should be clear: the functionality of mIRC (like what can be done with it's windows) has nothing to do with mIRC's scripting language. I'm not sure in what programming language mIRC has been developed, but it is definitely not written in it's own scripting language So I really don't understand what you mean by "merging Eu and mIRC" ?! They are two completely different things. It's like asking to merge Visual Basic (a language) with OpenOffice (as a scriptable application). Hans Peter Willems
2. RE: fixed windows
- Posted by gertie at visionsix.com Aug 05, 2003
- 411 views
On 5 Aug 2003, at 18:12, Peter Willems wrote: > > > gertie at visionsix.com wrote: > > > So the mirc nicklist and channel window are just fixed (but changeable > > and > > detachable) child windows in the parent ! That explains how it is > > possible to > > move each channel out of the mirc application screen and out onto the > > desktop. Just think where Eu would be now if RobC had merged Eu and mirc > > > > functionality way back when i first suggested it. Eu would look like > > Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there. > > Kat, I've seen your remarks about mIRC before and I don't get it. > > As far as I can see mIRC is an application that handles the > IRC protocol. It has a build in interpreter to handle scripting > inside mIRC so all kind of stuff can be automated. > > mIRC is definitely NOT a multi-purpose programming environment. Want a list of the language words and variables of mirc? Want a list of what it can do that Eu can't? > Having said that, I think it is very much possible to implement > IRC functionality with Euphoria, and creating a library that can > understand mIRC commands and run them as a Eu program should be > possible also (although I think it's a serious undertaking). Not terribly serious, other than the string execution mirc has. And being able to override it's built-in commands. I wrote a 100% Eu bot, and you can find the mirc-eu bot in the archives. The 100% Eu bot has no gui. The mirc-eu bot has access to mirc's script engine and gui. > One thing should be clear: the functionality of mIRC (like what > can be done with it's windows) has nothing to do with mIRC's > scripting language. I'm not sure in what programming language > mIRC has been developed, but it is definitely not written in it's > own scripting language > > So I really don't understand what you mean by "merging Eu and > mIRC" ?! They are two completely different things. It's like > asking to merge Visual Basic (a language) with OpenOffice (as > a scriptable application). In a word(s): mirc: 1) executing strings 2) goto 3) threads (including threaded timers) 4) event handling 5) native socks support (you can http/telnet/pop3 with mirc too) 6) easy as heck gui support 7) no var instanciation required 8) no crash if a var has no contents in a boolean test Bach: 9) classes 10) crash catching 11) gui support 12) block comments 13) slicing shorthands 14) better include paths 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. If RobC can't handle the full developement of Eu, i refer you to my suggestion he hire Jiri, Cuny, and Parnell (maybe paying them in futures, like stock). Kat
3. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 388 views
Hey Kat, gertie at visionsix.com wrote: <big snip> > 1) executing strings You might need it, I don't. > 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). > 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. > 4) event handling There is a full event-driven library in the archive. > 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. > 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). 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. > 7) no var instanciation required No comment on that. > 8) no crash if a var has no contents in a boolean test Ditto.. > Bach: > 9) classes I'm glad Euphoria is NOT object oriented in it's own design. > 10) crash catching Agreed. But that is not specific for mIRC OR Bach. > 11) gui support Don't know what Bach has over Eu in this regard. > 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 > 14) better include paths Clarify please ?? > 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. > If RobC can't handle the full developement of Eu, .... the way YOU think he should do it.... right ? 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. Btw, Kat, have you aver heard of Erlang ? It's a language that is developed by Ericson Telecom that seems to have everything you desire in a language AND it is open source and completely free. The proxy stuff you where asking for a while ago is easy in Erlang as it has all that stuff build into the language. You can get it at http://www.erlang.org It's one of my choices for distributed tcp-based applications and I'm going to make sure that my new IDE can handle Erlang as well Hans Peter Willems
4. RE: fixed windows
- Posted by gertie at visionsix.com Aug 05, 2003
- 383 views
On 5 Aug 2003, at 14:06, gertie at visionsix.com wrote: > > > On 5 Aug 2003, at 18:12, Peter Willems wrote: > > > > > gertie at visionsix.com wrote: > > > > > So the mirc nicklist and channel window are just fixed (but changeable and > > > detachable) child windows in the parent ! That explains how it is possible > > > to move each channel out of the mirc application screen and out onto the > > > desktop. Just think where Eu would be now if RobC had merged Eu and mirc > > > > > > functionality way back when i first suggested it. Eu would look like > > > Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there. > > > > Kat, I've seen your remarks about mIRC before and I don't get it. > > > > As far as I can see mIRC is an application that handles the > > IRC protocol. It has a build in interpreter to handle scripting > > inside mIRC so all kind of stuff can be automated. > > > > mIRC is definitely NOT a multi-purpose programming environment. > > Want a list of the language words and variables of mirc? Want a list of what > it > can do that Eu can't? > > > Having said that, I think it is very much possible to implement > > IRC functionality with Euphoria, and creating a library that can > > understand mIRC commands and run them as a Eu program should be > > possible also (although I think it's a serious undertaking). > > Not terribly serious, other than the string execution mirc has. And being able > to override it's built-in commands. I wrote a 100% Eu bot, and you can find > the > mirc-eu bot in the archives. The 100% Eu bot has no gui. The mirc-eu bot has > access to mirc's script engine and gui. > > > > One thing should be clear: the functionality of mIRC (like what > > can be done with it's windows) has nothing to do with mIRC's > > scripting language. I'm not sure in what programming language > > mIRC has been developed, but it is definitely not written in it's > > own scripting language > > > > So I really don't understand what you mean by "merging Eu and > > mIRC" ?! They are two completely different things. It's like > > asking to merge Visual Basic (a language) with OpenOffice (as > > a scriptable application). > > In a word(s): > > mirc: > 1) executing strings > 2) goto > 3) threads (including threaded timers) > 4) event handling > 5) native socks support (you can http/telnet/pop3 with mirc too) > 6) easy as heck gui support > 7) no var instanciation required > 8) no crash if a var has no contents in a boolean test > > Bach: > 9) classes > 10) crash catching > 11) gui support > 12) block comments > 13) slicing shorthands > 14) better include paths > > 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. If RobC can't handle the full > developement > of Eu, i refer you to my suggestion he hire Jiri, Cuny, and Parnell (maybe > paying them in futures, like stock). I forgot, executing strings is rather like dynamic includes,, or re-including, like Erlang. Yes, i know it's not the same, but either could be used as the other if neither has restrictions in length or scope. Kat
5. RE: fixed windows
- Posted by gertie at visionsix.com Aug 05, 2003
- 379 views
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? > > 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. > > 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 } > > 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. > > 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? > 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. > > 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. > > 11) gui support > > Don't know what Bach has over Eu in this regard. Size. Open source, for nix and winders. > > 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? > > 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. > 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. Kat
6. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 393 views
gertie at visionsix.com wrote: <lots of previous stuff snipped> > And you are saying since you don't need the option, i should be forced > to do > without? > So again, you don't need it, so i can't have it. > By your previous tone, i suspect that means you are against them. So > far, > you are against everything i suggest but threads. How unexpected. > I'm sure you won't like it, and will vote to keep it from me in Eu. > 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? Come on Kat, you behave like a little kid that doesn't get her way of doing things. As I said in several posts before, I don't mind if certain things would be implemented in Eu, as long as it won't loose it's appeal to me. If it does, I'll simply move on to another language. I've done that many times over the last 22 years. The point is that I DON'T diminish the actual quality of the language as a usable development platform, just because there are a few things not there yet. With all the languages that I have used I was always waiting for something that I wanted but it never stopped me from developing applications with them. When I couldn't live any longer with certain shortcommings then I moved to another platform. But I never said that the language I left behind was no good at all, it was just not good for me. > Yes, stop thinking of the program and it's flow, and engineer a > workaround > that the programming language will allow. I'll repeat my point here: goto is not needed in a language Maybe it helps to understand my pov when you know that I got my programming education based on Pascal. > And you think Eu is written in Euphoria? I don't know with Eu, but many languages are indeed started as a small sub-set interpreter and then further developed in the actual language itself. The Python interpreter is largely written in Python and most Java pre-compilers are indeed written in..... yep, Java. This is actually where the term "bootstrapping" comes from. It's very well possible that Eu was developed in the same way. > It's already apparent he is out of time, whether i say anything or not. So how did he manage to release the last update then ? > 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. I really don't see my company developing enterprise solutions with mIRC for our clients, but I can use Euphoria, Python, Erlang, Modula, Pascal, Oberon, etc. fine for that. These are all multi-purpose languages, mIRC is most certainly not. Hans Peter Willems
7. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 387 views
Derek Parnell wrote: > > I'll repeat my point here: goto is not needed in a language > > Except Assembler, of course Of course.... and any other Linear language > And in the same spirit, a construct such as " x += 1" is not needed as > well; it just useful sometimes. Agreed again > My POV is goto is only *needed* to extract the best execution speed out > of an application; and this is a very rare thing and must be heavily > justified. All other uses of goto are just doomed to cause expensive > maintenance times. If you are the project manager of a large software project you are happy that the used language does not have goto. > On the other hand, I have no right to dictate how people should code > their apps. If they want to make "spaghetti" code, that's their problem. > But, I'd kick them off my programming teams . I don't want to dictate how people code their apps, unless I'm in charge of a project and they are coding for my company. Besides that I was just stating my opinion, but it's clear to me that you get that Derek Hans Peter Willems
8. RE: fixed windows
- Posted by gertie at visionsix.com Aug 05, 2003
- 393 views
On 5 Aug 2003, at 21:44, Peter Willems wrote: > > > gertie at visionsix.com wrote: > > <lots of previous stuff snipped> > > > And you are saying since you don't need the option, i should be forced > > to do > > without? > > > So again, you don't need it, so i can't have it. > > > By your previous tone, i suspect that means you are against them. So > > far, > > you are against everything i suggest but threads. How unexpected. > > > I'm sure you won't like it, and will vote to keep it from me in Eu. You snipped telling me here that i am not the only one using Eu. As if i didn't know that. The condescention and patronising bothered me more than anything. > > 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? > > Come on Kat, you behave like a little kid that doesn't get > her way of doing things. And the way some people argue against an OPTION like goto in Eu is bordering on pathological. > As I said in several posts before, > I don't mind if certain things would be implemented in Eu, as > long as it won't loose it's appeal to me. If it does, I'll simply > move on to another language. I've done that many times over the > last 22 years. Me too. Since 1979. Eu has the most promise to be the best (fast, easy to learn and code in, most user options, and small footprint) language. > > Yes, stop thinking of the program and it's flow, and engineer a > > workaround > > that the programming language will allow. > > I'll repeat my point here: goto is not needed in a language > Maybe it helps to understand my pov when you know that I got > my programming education based on Pascal. Sure goto isn't needed. And sure i didn't mind stopping everything for an hour the other nite to work out a while loop with new flag vars and some exit statements, when a simple goto was all that was needed. I could have typed hundreds of goto and got clear code, when now i have a cursed mess of exit flags and loop controls. I wrote in Turbo Pascal for 6 yrs too. > > And you think Eu is written in Euphoria? > > I don't know with Eu, but many languages are indeed started > as a small sub-set interpreter and then further developed in > the actual language itself. The Python interpreter is largely > written in Python and most Java pre-compilers are indeed written > in..... yep, Java. This is actually where the term "bootstrapping" > comes from. > It's very well possible that Eu was developed in the same way. I doubt it. TP was bootstrapped this way. I have the source for TP5. > > It's already apparent he is out of time, whether i say anything or not. > > So how did he manage to release the last update then ? Late. > > 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. > > I really don't see my company developing enterprise solutions > with mIRC for our clients, but I can use Euphoria, Python, > Erlang, Modula, Pascal, Oberon, etc. fine for that. > These are all multi-purpose languages, mIRC is most certainly not. Just because no one is using it for "enterprise" coding does not mean it could not do the task. Jeeze, you are dissing it soley for haveing a built-in irc interface! Can you think outside the box at all? I remember when C was called a dead language, when i was laughted at for wanting to use Python for anything, yet now you say they are all "enterprise" languages. You know what?,, i still say the moon orbits the earth, and i bet some on this list will argue against that. Kat
9. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 387 views
gertie at visionsix.com wrote: <snipped a lot of repeating stuff> > Just because no one is using it for "enterprise" coding does not mean it > > could not do the task. Jeeze, you are dissing it soley for haveing a > built-in irc > interface! I don't diss it because of it's built-in irc capabilities, I diss it because it is seriously lacking in specific areas for enterprise solution development. And even that is not diminishing the quality of mIRC for what it's meant for..... but it was never meant to be used to build enterprise solutions. > Can you think outside the box at all? I remember when C was > called a dead language, when i was laughted at for wanting to use Python > for > anything, yet now you say they are all "enterprise" languages. They are because their feature set is aimed at writing such applications. Is that so hard to grasp ? There are specific languages for compiler construction, there are specific languages for text-handling, there are specific languages for CAD solutions, the list goes on..... non of these are usable to write enterprise solutions as they are simply not meant for that. And there are languages that ARE meant for enterprise solutions. Maybe that Python wasn't there a few years ago, but today it's scope for enterprise solutions is clear tmo. > You know what?,, i still say the moon orbits the earth, and i bet some > on this list will > argue against that. Probably.... but you can't win them all Hans Peter Willems
10. RE: fixed windows
- Posted by mistertrik at hotmail.com Aug 06, 2003
- 383 views
>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? The problem with adding more features to the library is this: You may not code it that way, and you may not want to deal with those extra features, but a lot of programming is looking at other people's code in libraries, and including them for your own program to use. So while _you_ may not use the new features, you can still encounter them, and have to work out exactly what the person was doing with their code. This can be particularly difficult if the library has a heavy reliance on new features. ===================================================== my 0.02 .______<-------------------\__ / _____<--------------------__|=== ||_ <-------------------/ \__| Mr Trick
11. RE: fixed windows
- Posted by "C. K. Lester" <cklester at yahoo.com> Aug 06, 2003
- 393 views
> i still say the moon orbits the earth, and i bet some on > this list will argue against that. I don't know about that, but I am thinking about Uranus. ---
12. RE: fixed windows
- Posted by kbochert at copper.net Aug 06, 2003
- 383 views
On 5 Aug 2003 at 14:06, gertie at visionsix.com wrote: > > So I really don't understand what you mean by "merging Eu and > > mIRC" ?! They are two completely different things. It's like > > asking to merge Visual Basic (a language) with OpenOffice (as > > a scriptable application). > > In a word(s): > > mirc: > 1) executing strings I have lately come to realize that this is not that hard in Bach. Bach 2 has already laid the groundwork by changing the way source is handled internally. > 2) goto This belongs in the group below as well. for me, goto is essential in writing something like thr interpreter. I have not once found a situation in Bach where it would help. > 3) threads (including threaded timers) Bach 2 does have coroutines which allow cooperative multitasking. Not quite the same thing, but its a start. Another feature which I have lately realized is quite doable is child processes: child_exec("foo.exe -w") would operate just like system_exec(), except that the child process would have its stdio redirected to the parent. Is this old hat? Is there a Eu library that does this? > 4) event handling You could write your program as an event loop that calls a series of coroutines. One coroutine detects events, another responds to them. Still not pre-emptive but if you don't need realtime... > 5) native socks support (you can http/telnet/pop3 with mirc too) Bach will interface to TCP4U. Does this provide enuf? > 6) easy as heck gui support > 7) no var instanciation required I have great difficulty with languages that allow this. Having the data spelled out with declarations is crucial to my understanding of that program. > 8) no crash if a var has no contents in a boolean test In Bach, variables that are part of a class are automatically initialized, so a statement like: if Cls.cnt = 0 then ... will never crash > > Bach: > 9) classes Bach's classes are meant to provide a more powerful procedural programming environment, not OO! (I don't comprehend OO) > 10) crash catching > 11) gui support I continue to be amazed at the short learning curve of IUP. > 12) block comments Seemed like a frill, but turned out to be very useful. Not only for commenting out blocks, but also for documentation blocks. > 13) slicing shorthands When I started Bach, this was the first thing on my wish list. Turns out to be less important than I thought. > 14) better include paths Changed a little in 2.0. homedir, BACHLIB env var path, BACHDIR\user, BACHDIR\LIB I was losing track of what was searched, so failure to find an id displays all files which were tried. > > 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. If RobC can't handle the > full developement of Eu, i refer you to my suggestion he hire Jiri, Cuny, and > Parnell (maybe paying them in futures, like stock). > > Kat > > --^---------------------------------------------------------------- > This email was sent to: kbochert at copper.net > > > TOPICA - Start your own email discussion group. FREE! > >
13. RE: fixed windows
- Posted by Christian.CUVIER at agriculture.gouv.fr Aug 06, 2003
- 387 views
> From: gertie at visionsix.com > Subject: RE: fixed windows > > >> <lots of previous stuff snipped> [Even more snipping] > >> > 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? > >> >> Come on Kat, you behave like a little kid that doesn't get >> her way of doing things. > > > And the way some people argue against an OPTION like goto in Eu is > bordering on pathological. > I also learnt programming in Pascal,and I fully share Derek's view that goto means higher maintenance time and cost. You really end up with a mess of flags to tell if you are coming at this spot in code from a oto or from linear flow, and that's why I skipped goto in VB programming fast and happy. If speed is so critical that goto are needed, then these critical parts of code are better written in C or ASM, so goto is pointless again. But, since a multi-purpose language is used to write business-class code as well as toy snippets by hobby programmers, why not include goto in EU? A possible answer: implementing goto means a lot of cleaning and flow control code. This is my experience from implementing them in idEu, and it means extra code being executed. If the source doesn't have goto inside, the preprocessor still must do some extra work in case there is one downstream. So, you may have to (slightly) pay for it even if you don't use it. I don't share some people's harsh attitude against this, but can understand it. > >> As I said in several posts before, >> I don't mind if certain things would be implemented in Eu, as >> long as it won't loose it's appeal to me. If it does, I'll simply >> move on to another language. I've done that many times over the >> last 22 years. > > > Me too. Since 1979. Eu has the most promise to be the best (fast, easy to > learn and code in, most user options, and small footprint) language. > Actually, apart from integration in Office apps, I don't see many reasons to use VB rather than Eu (oh yes, the debugger). Yet the user base for Eu is tiny compared to VB's. Guess why? > >> > Yes, stop thinking of the program and it's flow, and engineer a >> > workaround >> > that the programming language will allow. > >> >> I'll repeat my point here: goto is not needed in a language >> Maybe it helps to understand my pov when you know that I got >> my programming education based on Pascal. > > > Sure goto isn't needed. And sure i didn't mind stopping everything for an hour > > the other nite to work out a while loop with new flag vars and some exit > statements, when a simple goto was all that was needed. I could have typed > hundreds of goto and got clear code, when now i have a cursed mess of exit > flags and loop controls. I wrote in Turbo Pascal for 6 yrs too. > Adding to my earlier statements about goto: what is sorely needed is more flexible flow control, what I'd call structured or controlled goto. For instance: exit one or more if blocks, exit one or more loops at a time, possibly labelling them - this is a real bonus in maintenance-. Scoped variables and nested routines would really help too. Wait for next year... > >> > And you think Eu is written in Euphoria? > >> >> I don't know with Eu, but many languages are indeed started >> as a small sub-set interpreter and then further developed in >> the actual language itself. The Python interpreter is largely >> written in Python and most Java pre-compilers are indeed written >> in..... yep, Java. This is actually where the term "bootstrapping" >> comes from. >> It's very well possible that Eu was developed in the same way. > > > I doubt it. TP was bootstrapped this way. I have the source for TP5. > > >> > It's already apparent he is out of time, whether i say anything or not. > >> >> So how did he manage to release the last update then ? > > > Late. > > >> > 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. > >> >> I really don't see my company developing enterprise solutions >> with mIRC for our clients, but I can use Euphoria, Python, >> Erlang, Modula, Pascal, Oberon, etc. fine for that. >> These are all multi-purpose languages, mIRC is most certainly not. > > > Just because no one is using it for "enterprise" coding does not mean it > could not do the task. Jeeze, you are dissing it soley for haveing a built-in > irc > interface! Can you think outside the box at all? I remember when C was > called a dead language, when i was laughted at for wanting to use Python for > anything, yet now you say they are all "enterprise" languages. You know > what?,, i still say the moon orbits the earth, and i bet some on this list > will > argue against that. > Matt recently remarked that the Eu user base seems mostly interested by GUI building and hardly anything else. Since this is not your main use for EU (/me not mine either), you don't get listened too much on this list. <ad><h1>Join OE!</h1></ad> > Kat CChris
14. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
- 397 views
Christian.CUVIER at agriculture.gouv.fr wrote: > Actually, apart from integration in Office apps, I don't see many > reasons to use VB rather than Eu (oh yes, the debugger). Yet the user > base for Eu is tiny compared to VB's. Guess why? Ermm........ marketing budget > Adding to my earlier statements about goto: what is sorely needed is > more flexible flow control, what I'd call structured or controlled goto. > > For instance: exit one or more if blocks, exit one or more loops at a > time, possibly labelling them - this is a real bonus in maintenance-. In WinDev there is a simple solution for this: return When you have a procedure with deeply nested loops and constructs, doing a return anywhere in that construct will break you out of the construct and back to the point after where the procedure was called. > Matt recently remarked that the Eu user base seems mostly interested by > GUI building and hardly anything else. Since this is not your main use > for EU (/me not mine either), you don't get listened too much on this > list. I think that GUI building is important also, as we are living in a world where desktop machines are running windowed user environments. It is also the area where the supporting libraries and such are still lacking. Mind you I don't say I want it implemented inside Euphoria. As Eu is cross platform that would bring a lot of dead overhead to the interpreter, and greatly diminish the possible use because of differences between operating systems. Hans Peter Willems
15. RE: fixed windows
- Posted by kbochert at copper.net Aug 06, 2003
- 380 views
On 6 Aug 2003 at 12:10, Christian.CUVIER at agriculture.gouv.fr wrote: > > And the way some people argue against an OPTION like goto in Eu is > > bordering on pathological. > > > > I also learnt programming in Pascal,and I fully share Derek's view that > goto means higher maintenance time and cost. You really end up with a > mess of flags to tell if you are coming at this spot in code from a oto > or from linear flow, and that's why I skipped goto in VB programming > fast and happy. Loops cause control to arrive at the end of the loop via any number of paths. You end up by setting flags within the loop, so the following code can know why the loop was exited. > If speed is so critical that goto are needed, then these critical parts > of code are better written in C or ASM, so goto is pointless again. goto has nothing to do with speed. Its sole purpose is to express control flow in a clearer way. When misused, it has great potential to obfuscate code, but when well used it can clarify the designers intentions. Many other features also have obfuscation potential (indeed there are programmers who can misuse ANY feature). I would much rather work on code that had an occaisional goto than on code that was mis-indented. > But, since a multi-purpose language is used to write business-class > code as well as toy snippets by hobby programmers, why not include goto > in EU? > A possible answer: implementing goto means a lot of cleaning and flow > control code. This is my experience from implementing them in idEu, and > it means extra code being executed. If the source doesn't have goto > inside, the preprocessor still must do some extra work in case there is > one downstream. So, you may have to (slightly) pay for it even if you > don't use it. I don't share some people's harsh attitude against this, > but can understand it. That can be a real problem. Thats why.. See below. > <snip> > > > > Adding to my earlier statements about goto: what is sorely needed is > more flexible flow control, what I'd call structured or controlled goto. > For instance: exit one or more if blocks, exit one or more loops at a > time, possibly labelling them - this is a real bonus in maintenance-. > Scoped variables and nested routines would really help too. Wait for > next year... > To quote from the Bach manual: "Goto can only be used within a function or procedure, and it may not jump out of that function or procedure. Jumping into a loop is also prohibited" > > Matt recently remarked that the Eu user base seems mostly interested by > GUI building and hardly anything else. Since this is not your main use > for EU (/me not mine either), you don't get listened too much on this list. > <ad><h1>Join OE!</h1></ad> > I have always felt that a big part of Eu's popularity was its low-level ability -- run on dos, write console apps, poke memory, etc. Maybe not. Regards Karl Bochert
16. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
- 388 views
kbochert at copper.net wrote: > goto has nothing to do with speed. Its sole purpose is to express > control flow in a clearer way. How can you express control in a clearer way then without goto. I'm realy curious, maybe you can give an example. > When misused, it has great potential to > obfuscate code, but when well used it can clarify the designers > intentions. Again, I can't see how the designers intentions would be better clarified my means of using goto. In my little corner of the programming universe, the developers intentions are made visible by means of inline documentation... lot's of it And again, an example would be appreciated. > Many other features also have obfuscation potential (indeed there are > programmers who can misuse ANY feature). )))) > I have always felt that a big part of Eu's popularity was its > low-level ability -- run on dos, write console apps, > poke memory, etc. > Maybe not. Maybe not anymore Hans Peter Willems
17. RE: fixed windows
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 06, 2003
- 391 views
Christian.CUVIER at agriculture.gouv.fr wrote: <lots of snips> > Actually, apart from integration in Office apps, I don't see many > reasons to use VB rather than Eu (oh yes, the debugger). Yet the > user base for Eu is tiny compared to VB's. Guess why? In fact, you can't even use that (Office integration) as an argument any more. It's really pretty simple to Automate Office apps using EuCOM (see the archives). > Matt recently remarked that the Eu user base seems mostly > interested by GUI building and hardly anything else. Since this is > not your main use for EU (/me not mine either), you don't get > listened too much on this list. > <ad><h1>Join OE!</h1></ad> I think you must be referring to the post about the MicroEconomy. I don't think I'd draw this conclusion. It's more that virtually every app uses some sort of GUI, therefore, *everyone* needs them, and they are very popular. It's just a lowest common denominator across most programmers. OTOH, not everyone needs an elegant little library for the Simplex Algorithm, but I just can't help myself but to download and vote for cool things like this. Matt Lewis
18. RE: fixed windows
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 06, 2003
- 390 views
kbochert at copper.net wrote: > I have always felt that a big part of Eu's popularity was its > low-level ability -- run on dos, write console apps, poke memory, > etc. Maybe not. I like the feeling that I can usually focus on an algorithm without having to fight the language (at least more so than with other languages I have tried). It largely has to do with the flexibility of the datatypes, but also the clean, clear syntax. Eu has enough low level abilities that I feel that I am able to do anything I want to. Certainly some things are more difficult than they would be with other languages, but I've had a lot of fun (not to mention frustration) getting Eu to cooperate with COM, for example. Matt Lewis
19. RE: fixed windows
- Posted by kbochert at copper.net Aug 06, 2003
- 407 views
On 6 Aug 2003 at 11:27, Peter Willems wrote: > > > goto has nothing to do with speed. Its sole purpose is to express > > control flow in a clearer way. > > How can you express control in a clearer way then without goto. > I'm realy curious, maybe you can give an example. > Its very difficult to spell out actual code because it is quite rare and tends to occur only in complex code. As an example, a bytecode interpreter (EU's for instance), consists of a while statement that contains a switch statement with maybe 200 cases. Many of these are a page long (even when written with macros!) and contain additional structures. When, inside a for, inside a switch, inside a while, on page 36, I see if ( x != 0 ) goto type_error; I know immediately the programmers intentions. It is as clear, concise and meaningful as 'get_cnt();' would be. The structured equvalent: if ( x != 0 ) { type_error = TRUE; break; } Is more wordy, uses data-coupling (does anyone else modify type_error?) and sprinkles error handling code through-out the code. (Each nested loop checks the flag) If I need to know what happens on type_error, it is located in a single place. Replace 50 'goto type_error's; and 'goto range_error;'s' with the equivalent flags and structured code is a mess. A compiler back end is very complex. It can be structured to put the complexity in in-line code, or in macros, or in objects, or in structures, but it remains hard to grasp. The best solution always seems to be to handle some of the detail with data structures, some with careful code structure, some with macros, and some with a few well-chosen goto's. (A C++ programmer would probably add templates, classes etc. to that list). I will admit that since adding goto to Bach, I have found not a single case where I have wanted to use it. (But then I haven't written a complex program with Bach, either) > > When misused, it has great potential to > > obfuscate code, but when well used it can clarify the designers > > intentions. > > Again, I can't see how the designers intentions would be > better clarified my means of using goto. In my little corner > of the programming universe, the developers intentions are > made visible by means of inline documentation... lot's of it > > And again, an example would be appreciated. I have far too often seen complex code which is so well clarified with sometimes incorrect comments, that only a few lines of code remained on each page. This was just barely acceptable when the code was correct, intolerable if it had bugs. (Its also very! hard to erase a comment ) In-line comments can be invaluable, but they can also be a trap. In-line comments that recapitulate the code are an abuse. goto's can be easily abused, but in my experience, incorrect comments and mis-indenting are far more serious problems. I think that Dijkstra has scared programmers enough that they use goto verrry carefully. Thats a lot of opinion, held for (I think) non-trivial reasons. I care greatly about the clarity of code ( I rank it above correctness! ) and my experience and taste tell me that goto is useful in a few cases. Karl Bochert
20. RE: fixed windows
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 06, 2003
- 384 views
Derek Parnell wrote: > > > From: "Matt Lewis" <matthewwalkerlewis at yahoo.com> > > I like the feeling that I can usually focus on an algorithm > > without having to fight the language (at least more so than with > > other languages I have tried). It largely has to do with the > > flexibility of the datatypes, but also the clean, clear syntax. > > Wirth also developed Pascal because he felt that structured data > was just as important as structure programming. He'd hate > Euphoria's dynamically typed data structures. But I agree with you > in that the fluid nature of Euphoria's datatypes makes so many > coding problems just disappear. It would be nice if we could have > both dynamically typed and statically typed data in the same > language. There is a place for both. I agree, and so, to a degree at least, does Rob (i.e., user-defined types). It just doesn't go as far as many (most/all?) would like. The two ideas I like are a more focused way to typecheck a variable and structures (of Eu data, not memory mapped data). In fact, the second would probably cover most cases where the first would be handy. Matt Lewis
21. RE: fixed windows
- Posted by Peter Willems <peter at integratedmoves.com> Aug 06, 2003
- 385 views
kbochert at copper.net wrote: <snipped a bit> > Many of these are a page long (even when written with macros!) and > contain additional structures. > When, inside a for, inside a switch, inside a while, on page 36, I see > > if ( x != 0 ) > goto type_error; > I know immediately the programmers intentions. > It is as clear, concise and meaningful as 'get_cnt();' > would be. > The structured equvalent: > > if ( x != 0 ) { > type_error = TRUE; > break; > } How about this: if ( x != 0 ) type_error() break As for readability it is the same as your first example. The only difference is that the program will return to this code so your break is processed here instead of where you jumped to with the goto. And *that* is exavctly what I like: I know from my version instantly that after executing the type_error handler (or whatever) I will still return to this specific place in the program's logic. That goes a long way for maintainability. In your example with goto I'm forced to check out the code that is actually handling the type_error to see where it will lead me, while my concern was with the code where type_error was called. Again, this also reflects largely on how the program is modularized. > If I need to know what happens on type_error, it is > located in a single place. Same with my example. > Replace 50 'goto type_error's; and 'goto range_error;'s' > with the equivalent flags and structured code is a mess. ... and not needed, even without a goto. > A compiler back end is very complex. It can be structured > to put the complexity in in-line code, or in macros, or in > objects, or in structures, but it remains hard to grasp. I'm doing a lot of (commercial) work on dynamically loaded parsers. Such a parser does not implement a certain language, but instead it can parse any language or structured file based on a language description. This is even more complex then to have the parser understand a fixed instruction set. So I do know a little bit about this matter > I will admit that since adding goto to Bach, I have found not a > single case where I have wanted to use it. (But then I haven't > written a complex program with Bach, either) Just today I found that WinDev actually also has goto... after working with that language in commercial development for several years it shows how many times I have been wishing for goto... ... zero times > I have far too often seen complex code which is so well > clarified with sometimes incorrect comments, that only a few > lines of code remained on each page. This was just barely > acceptable when the code was correct, intolerable if it had > bugs. (Its also very! hard to erase a comment ) I agree that sometimes people can get carried away with commenting code. Documenting code with comments is as much a skill as writing clean code. > In-line comments can be invaluable, but they can also be a trap. > In-line comments that recapitulate the code are an abuse. So what do you think about inline comments that contain special tags to load a document generator ? In this case the inline documentation becomes the sole place for documentation maintenance. I actually like that. > goto's can be easily abused, but in my experience, > incorrect comments and mis-indenting are far more serious > problems. As you say, *incorrect* comments are indeed.... incorrect. But that is a bit stating the obvious. > I think that Dijkstra has scared programmers enough that > they use goto verrry carefully. I'm curious how many people here on the list ever heard of him Hans Peter Willems