1. Homosequences - Start Again
- Posted by Peter Robinson <indorlaw at ya?o?.com.au> Aug 16, 2007
- 519 views
Hi all I wrote this (several times), but didn't send it. “I've almost posted a few times lately, but pulled back because I think the contributors should run the show. My own load of f/t non-programming job and p/t accelerated Masters in CS make it hard to use my favourite language, and impossible to contribute to the effort. Most of my Euphoria work is direct programming for research and ad hoc purposes, but as a committed user, I'm worried about where OpenEu is going. In particular, I think development is being consistently discussed at too low a level. “Enhancements” seem to be limited to a neat little function here, a little sugar there, which in 2 -3 years time will look like a wounded body with band-aids all over it. Take the latest discussion on arrays/lists, etc, and assume for the sake of argument that a programming language is a user-computer interface that seeks to map cognitive concepts to code as seamlessly as possible. Entities that contain uniform data are common cognitive models, so we would like an easy way to declare them. Entities with fixed, non-uniform data are also common real world conceptions. String objects are also common. While we love the flexibility of Euphorian sequences, often (as good programmers) we would like to constrain the data within a sequence. At the moment, the method of doing that is to write a series of quasi-boolean expressions within a type block, rather than to declare the encapsulated data explicitly. I'd rather see our champions argue about this:- Can Euphoria do better at mapping real-world concepts of data objects to code? Than this:- Should it be sequence of integer, or seq_of_ints, or list or array or .. who cares? If the solution were considered at a higher-level, it would be the sort of enhancement that elevates the language to another plane – not just sugar. Note that I'm not talking about OO. I'm talking about the way that everyone on this list thinks about real-world objects, whether they admit it, or realise it, or not. Rob observed that users don't often use the type construct. If you look at all programmers, not just Euphorians, they use the type construct constantly, although under other names and guises. So could it be that Euphorians don't use it because its syntax doesn't reflect the way they think about the problem space? Another completely different example. When a proposed new function is discussed, the discussion starts with an implementation, someone else comes up with a different implementation with different parameters and/or return values, someone else starts talking at the machine-level about how fast it will be if you run it in a million-fold loop, and someone else says it's all crap, etc, and each person seems to have a proprietary interest in his own implementation or idea. When a new function is proposed, the implementation shouldn't be relevant until after it's decided to include it in the langauge. All that's required at the decision stage is the function signature. Once that's agreed, everyone can engage in friendly competition to decide how to implement it (with plagiarism encouraged). I'm not saying this will avoid argument, but at least the argument will be about the right things.” I was going to go on with more examples, but since writing the above, the discussion on homogeneous sequences, which are just a trivial subset of the overall problem, has gone berserk. If the discussion were at a higher level, a much broader range of solutions would be considered. Just as an example, a declarative approach within type blocks reflects more how people think about entities, and solves lots more problems than what's currently being discussed. Each of the following declarative constructs does little more than translate boolean expressions into simpler declarations:- type integer_list( sequence x ) integer x[] end type type integer_matrix( sequence x ) sequence x[] integer x[][] end type type customer( sequence x ) integer x[1] -- customer ID sequence x[2] –- name sequence x[3] –- address sequence x[4] –- DOB end type OR type customer( sequence x ) integer x[1] sequence x[2..4] end type Aliasing can be accomodated in such type blocks without adding a single word to the language. type customer( sequence x ) integer x[1] .id –- I've assumed dot access, but it could also be shorthand for a subscript constant sequence x[2] .name –- but the alias is more sensitive – x[address][name] should fail sequence x[3] .address end type Once you accept a declarative shorthand for boolean expressions, the following is equally intuitive:- type ten_ints( sequence x ) length(x) = 10 – insert any boolean expression you want end type Since type blocks are just a series of boolean expressions, why not ASSUME that in a declarative syntax? None of these examples offend core Euphorian principles. You'd have to look twice to realise that they're illegal. I put them forward primarily as an example of the broader approach I'm advocating. If our champions approach the problems at a higher level, I think the advances will not only be more significant, but alos more simple, since the idea of cognitive mapping is by definition simple. Cheers Peter Robinson
2. Re: Homosequences - Start Again
- Posted by Salix <salix at fr??mail.hu> Aug 16, 2007
- 483 views
Very interesting reading. Both the general comments and the concrete suggestion. Cheers, Salix
3. Re: Homosequences - Start Again
- Posted by Jason Gade <jaygade at yahoo.c??> Aug 16, 2007
- 479 views
Well said... I kind of like the idea of assuming statements in type constructs are boolean expressions. It differentiates them more from other functions. Plus I've been wondering about some kind of built-in to test whether all elements of a sequence are a basic type (integer or sequence). I don't know if I can discuss mapping "real-world concepts of data objects to code" though. I'm not a CS guy, just a noisy hobbyist. Plus it seems to me that most of the "big picture vision" stuff belongs to Rob. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
4. Re: Homosequences - Start Again
- Posted by CChris <christian.cuvier at agriculture??ouv.fr> Aug 16, 2007
- 485 views
I definitely agree with your comments and am sometimes bewildered as you are by the way development is being handled and what are the discussed issues. More detail follows. Peter Robinson wrote: > > Hi all > > I wrote this (several times), but didn't send it. > > “I've almost posted a few times lately, but pulled back because I think the > contributors should run the show. My own load of f/t non-programming job and > p/t accelerated Masters in CS make it hard to use my favourite language, and > impossible to contribute to the effort. Most of my Euphoria work is direct > programming > for research and ad hoc purposes, but as a committed user, I'm worried about > where OpenEu is going. In particular, I think development is being > consistently > discussed at too low a level. “Enhancements” seem to be limited to a neat > little > function here, a little sugar there, which in 2 -3 years time will look like > a wounded body with band-aids all over it. The only consistent plan I see in the discussions is: hey, don't change anything. Otherwise, as you say, it's just a collection of individual needs which are more or less shared. Trying to discuss things at a higher level elicits a "too complicated" response, which is almost equivalent to a death sentence on the topic being considered any further. I've never seen this "too complicated" thing anywhere else. As I have said in the past, one of the main issues is that there is a small group of say 20 regular posters (often quite less) at any given time. How this group is representative of the hopefully larger user community is a mystery. In theory, Rob may have clues - if any feedback is emailed, it will be at RDS. > > Take the latest discussion on arrays/lists, etc, and assume for the sake of > argument that a programming language is a user-computer interface that seeks > to map cognitive concepts to code as seamlessly as possible. Entities that > contain > uniform data are common cognitive models, so we would like an easy way to > declare > them. Entities with fixed, non-uniform data are also common real world > conceptions. > String objects are also common. While we love the flexibility of Euphorian > sequences, > often (as good programmers) we would like to constrain the data within a > sequence. > At the moment, the method of doing that is to write a series of quasi-boolean > expressions within a type block, rather than to declare the encapsulated data > explicitly. I'd rather see our champions argue about this:- > > Can Euphoria do better at mapping real-world concepts of data objects to code? Euphoria was designed as the fastest possible interpreter - makes sense on 40MHz machines, perhaps less today. It was designed for the installer to fit on a floppy, but machines may no longer have a floppy drive today. Consistency with "business models", or user's native task/problem representation, is quite absent - except when that model happen to match the heterogeneous sequence pattern -. What matters is less many keywords and thinner docs, it seems. > > Than this:- > > Should it be sequence of integer, or seq_of_ints, or list or array or .. who > cares? > > If the solution were considered at a higher-level, it would be the sort of > enhancement > that elevates the language to another plane – not just sugar. 150% agreed. > Note that I'm > not talking about OO. I'm talking about the way that everyone on this list > thinks > about real-world objects, whether they admit it, or realise it, or not. Rob > observed that users don't often use the type construct. If you look at all > programmers, > not just Euphorians, they use the type construct constantly, although under > other names and guises. So could it be that Euphorians don't use it because > its syntax doesn't reflect the way they think about the problem space? > > Another completely different example. When a proposed new function is > discussed, > the discussion starts with an implementation, someone else comes up with a > different > implementation with different parameters and/or return values, someone else > starts talking at the machine-level about how fast it will be if you run it > in a million-fold loop, and someone else says it's all crap, etc, and each > person > seems to have a proprietary interest in his own implementation or idea. You forgot adding that then the discussion dies without any decision being recorded. > When > a new function is proposed, the implementation shouldn't be relevant until > after > it's decided to include it in the langauge. All that's required at the > decision > stage is the function signature. Once that's agreed, everyone can engage in > friendly competition to decide how to implement it (with plagiarism > encouraged). > I'm not saying this will avoid argument, but at least the argument will be > about > the right things.” > > I was going to go on with more examples, but since writing the above, the > discussion > on homogeneous sequences, which are just a trivial subset of the overall > problem, > has gone berserk. If the discussion were at a higher level, a much broader > range > of solutions would be considered. Just as an example, a declarative approach > within type blocks reflects more how people think about entities, and solves > lots more problems than what's currently being discussed. Each of the > following > declarative constructs does little more than translate boolean expressions > into > simpler declarations:- > > type integer_list( sequence x ) > integer x[] > end type > > type integer_matrix( sequence x ) > sequence x[] > integer x[][] > end type > > type customer( sequence x ) > integer x[1] -- customer ID > sequence x[2] –- name > sequence x[3] –- address > sequence x[4] –- DOB > end type > > OR > > type customer( sequence x ) > integer x[1] > sequence x[2..4] > end type > > Aliasing can be accomodated in such type blocks without adding a single word > to the language. > > type customer( sequence x ) > integer x[1] .id –- I've assumed dot access, but it could also be > shorthand > for a subscript constant > sequence x[2] .name –- but the alias is more sensitive – > x[address][name] > should fail > sequence x[3] .address > end type > > Once you accept a declarative shorthand for boolean expressions, the following > is equally intuitive:- > > type ten_ints( sequence x ) > length(x) = 10 – insert any boolean expression you want > end type > > Since type blocks are just a series of boolean expressions, why not ASSUME > that > in a declarative syntax? None of these examples offend core Euphorian > principles. > You'd have to look twice to realise that they're illegal. Agreed, except that types are predicates in the current state of the language, so I'd use "structure" instead of "type". Oops, another keyword - won't fly. > I put them forward primarily as an example of the broader approach I'm > advocating. > If our champions approach the problems at a higher level, I think the advances > will not only be more significant, but alos more simple, since the idea of > cognitive > mapping is by definition simple. Not only that, but it speeds up development because a/ coding is more straightforward and b/ bugs are less likely, since they very often come from a discrepancy between the coder's mind and the language set of text to executable rules. I have raised this sort of issues before in an invariably lonely way. CChris > > Cheers > Peter Robinson
5. Re: Homosequences - Start Again
- Posted by c.k.lester <euphoric at ?k?ester.com> Aug 16, 2007
- 514 views
Peter Robinson wrote: > > My own load of f/t non-programming job and > p/t accelerated Masters in CS make it hard > to use my favorite language,and impossible > to contribute to the effort. They're giving Masters degrees in Counter-strike?!?! OMG! Sign me up! I totally PWN at that game.
6. Re: Homosequences - Start Again
- Posted by Derek Parnell <ddparnell at bigpo??.com> Aug 16, 2007
- 475 views
CChris wrote: > I have raised > this sort of issues before in an invariably lonely way. lol ... you are still a new kid on the block ... Some have been suggesting significant changes for a long time. eg. http://www.users.bigpond.com/ddparnell/euphoria/product.htm Peter's views are old news. It used to be "Nothing ever changes, well not in a hurry anyway." but now there is real potential for Euphoria to get back on track with the modern needs of developers. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
7. Re: Homosequences - Start Again
- Posted by Robert Craig <rds at RapidEuphor?a.?om> Aug 16, 2007
- 490 views
Peter Robinson wrote: > Rob observed that users don't often use the type construct. > If you look at all programmers, not just Euphorians, > they use the type construct constantly, although under > other names and guises. In most other languages you *have* to pre-declare all your data in order to do anything with it. You can't build arrays, stacks, queues, trees, strings, structures, arrays of strings, arrays of floating-point numbers, or anything else *without* using types. > So could it be that Euphorians > don't use it because its syntax doesn't reflect the way > they think about the problem space? In Euphoria, you are free to declare all variables as "object" if you like. It doesn't prevent you from building and using any kind of interesting data structure. Most Euphoria programmers will use the pre-declared types "integer" or "sequence" or "atom", where appropriate, rather than "object". They don't mind doing that. Few or no extra keystrokes. However, creating a user-defined type is not necessary for getting the job done, so why bother? Types can help catch bugs, but debugging is already pretty easy, given all the other run-time error checks. Types also document your variables better, but so do comments, another feature you are free to ignore. Another issue, is that checking a sequence for type conformance of all elements, is currently O(n), so it's generally more expensive than it's worth. That's why types are not used as much in Euphoria. The recently proposed enhancement would greatly alleviate the O(n) problem, (as well as helping the Translator to generate somewhat faster C code). Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Homosequences - Start Again
- Posted by Robert Craig <rds at Rapi?Euphor?a.com> Aug 16, 2007
- 501 views
- Last edited Aug 17, 2007
CChris wrote: > The only consistent plan I see in the discussions is: hey, don't change > anything. > Otherwise, as you say, it's just a collection of individual needs which are > more or less shared. Trying to discuss things at a higher level elicits a "too > complicated" response, which is almost equivalent to a death sentence on the > topic being considered any further. I've never seen this "too complicated" > thing > anywhere else. What other forums do you participate in, where things are very different? > As I have said in the past, one of the main issues is that there is a small > group of say 20 regular posters (often quite less) at any given time. How this > group is representative of the hopefully larger user community is a mystery. > In theory, Rob may have clues - if any feedback is emailed, it will be at RDS. When I was still getting registrations, 80-90% of the people who registered were people who had never posted a single message on EUforum. These days I still get email from people who never post here. However, I now have less of an idea of how many users there are "out there". Most people are not keenly interested in language design, or even if they are, they don't feel qualified to comment on ideas put forward by people who have been using Euphoria for many years, have gone through the source code, etc. Most people do not have problems in using a relatively simple language like Euphoria, that require clarification on this forum (assuming they even have the required English skills to post). > Euphoria was designed as the fastest possible interpreter True to some extent. > - makes sense on 40MHz machines, perhaps less today. People will always value performance, perhaps not in an individual program, but when deciding what language to invest their time in. The first PC that I ran Euphoria on was a 486 50 MHz machine. When that machine first came out, I remember reading an article that speculated that only professionals in certain areas, and other "power users" would ever need that kind of speed. With faster machines and huge memories, you could also argue that fewer will use C/C++, and more will want something easier to learn and debug with, like Euphoria. > It was designed for the installer to fit on a > floppy, Not true. > but machines may no longer have a floppy drive today. > Consistency with "business models", or user's native task/problem > representation, > is quite absent - except when that model happen to match the heterogeneous > sequence > pattern -. What matters is less many keywords and thinner docs, it seems. One of the main goals, was to make a simpler language that amateurs, hobbyists etc. could easily learn and use. It was never my intention to compete against C++ and Microsoft in the professional arena. > > If the solution were considered at a higher-level, it would be the sort of > > enhancement > > that elevates the language to another plane – not just sugar. > > 150% agreed. Then propose something that will truely take Euphoria "to a higher plane". > > Another completely different example. When a proposed new function is > > discussed, > > the discussion starts with an implementation, someone else comes up with a > > different > > implementation with different parameters and/or return values, someone else > > starts talking at the machine-level about how fast it will be if you run it > > in a million-fold loop, and someone else says it's all crap, etc, and each > > person > > seems to have a proprietary interest in his own implementation or idea. > > You forgot adding that then the discussion dies without any decision being > recorded. OK, from now on, I think anyone who is serious about a proposal should eventually, after a period of discussion and analysis, write a summary of his/her (revised) proposal, and call for a vote. People can vote by posting a message here. Voters should clearly say "Yes" or "No", and can give an optional, very brief (one or two sentence) reason for their vote. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
9. Re: Homosequences - Start Again
- Posted by CChris <christian.cuvier at agr?culture.?ouv.fr> Aug 16, 2007
- 480 views
- Last edited Aug 17, 2007
Robert Craig wrote: > > CChris wrote: > > The only consistent plan I see in the discussions is: hey, don't change > > anything. > > Otherwise, as you say, it's just a collection of individual needs which are > > more or less shared. Trying to discuss things at a higher level elicits a > > "too > > complicated" response, which is almost equivalent to a death sentence on the > > topic being considered any further. I've never seen this "too complicated" > > thing > > anywhere else. > > What other forums do you participate in, > where things are very different? > Eiffel, FreePascal, to quote the ones I'm currently browsing or on which I post. I still have to look at the D thing as well, I wish I did it earlier. > > As I have said in the past, one of the main issues is that there is a small > > group of say 20 regular posters (often quite less) at any given time. How > > this > > group is representative of the hopefully larger user community is a mystery. > > In theory, Rob may have clues - if any feedback is emailed, it will be at > > RDS. > > When I was still getting registrations, 80-90% of the people > who registered were people who had never posted a single message > on EUforum. These days I still get email from people who never post here. > However, I now have less of an idea of how many users there are "out there". > > Most people are not keenly interested in language design, > or even if they are, they don't feel qualified to comment > on ideas put forward by people who have been using Euphoria > for many years, have gone through the source code, etc. > > Most people do not have problems in using a relatively > simple language like Euphoria, that require > clarification on this forum (assuming they even have > the required English skills to post). > Very true. However, they can tell you if they are happy with it, not to tell you if they are not, and ask naive questions which could help you in future decisions. As I said, if anyone has clue, it should be RDS for obvious reasons. > > Euphoria was designed as the fastest possible interpreter > > True to some extent. And it has succeeded in that area. > > > - makes sense on 40MHz machines, perhaps less today. > > People will always value performance, perhaps not in an > individual program, but when deciding what language > to invest their time in. > > The first PC that I ran Euphoria on was a 486 50 MHz machine. > When that machine first came out, I remember reading an > article that speculated that only professionals in certain areas, > and other "power users" would ever need that kind of speed. > > With faster machines and huge memories, you could also argue > that fewer will use C/C++, and more will want something easier > to learn and debug with, like Euphoria. > Some people at M$ assumed that 640kb was well above the ordinary user's need People will always value performance. Except that, when speed becomes high enough, performance is no longer an issue in 80% of cases and other aspects may come into play. You hardly care if some routine takes 2200 or 640 nanoseconds, except when you call it in a loop. And people critically in need of speed will use a lower level language anyway, be it C or assembly. This is why I am not 100% sure that, for non CPU intensive code, cutting edge performance in Euphoria is as important as it was 10-15 years ago. Even more so now that the Translator is public. > > It was designed for the installer to fit on a > > floppy, > > Not true. Did I dream this up? I'll check the "propaganda" texts... > > > but machines may no longer have a floppy drive today. > > Consistency with "business models", or user's native task/problem > > representation, > > is quite absent - except when that model happen to match the heterogeneous > > sequence > > pattern -. What matters is less many keywords and thinner docs, it seems. > > One of the main goals, was to make a simpler language > that amateurs, hobbyists etc. could easily learn and use. > It was never my intention to compete against C++ and Microsoft > in the professional arena. > Nor mine, although I think Eu could be easily far better, the potential is there. And the "easy to use part" is debatable in some areas. EuForum is full of detailed accounts about them. > > > If the solution were considered at a higher-level, it would be the sort of > enhancement</font></i> > > > that elevates the language to another plane – not just sugar. > > > > 150% agreed. > > Then propose something that will truely take Euphoria "to a higher plane". > * Check how the type system could accommodate a couple "machine" types to speed up a variety of things. * Design a fully integrated scoping system which makes the promise of modular programming in Eu come true, without leaving supposedly corner cases that supposedly no one will ever need. * Start considering a reentrant front end/backend pair, so as to allow a variety of dynamic constructs which are expected from an interpreted language, and probably reduce the load time of large (GUI) programs as well; * Start investigating the possibility of plugin systems, in applications first (perhaps using conditional include statements), then if possible in the language itself. This will allow those who like it bare bones to have it bare bones, and those who like it cheesier to have it too. Instead of adjusting your learning curve to the language, adjust the language to your learning curve. * Upgrade to decent debugging facilities, featuring dynamic breakpoints and expression watch most urgently. Just some ideas I have/have started to work on, there are probably many more useful things to do. For the most part, they can hardly be one man's spare time projects. Open cooperation would be critically needed. > > > Another completely different example. When a proposed new function is > > > discussed, > > > the discussion starts with an implementation, someone else comes up with a > > > different > > > implementation with different parameters and/or return values, someone > > > else > > > starts talking at the machine-level about how fast it will be if you run > > > it > > > in a million-fold loop, and someone else says it's all crap, etc, and each > > > person > > > seems to have a proprietary interest in his own implementation or idea. > > > > You forgot adding that then the discussion dies without any decision being > > recorded. > > OK, from now on, I think anyone who is serious about a proposal > should eventually, after a period of discussion and analysis, > write a summary of his/her (revised) proposal, and call for a vote. > > People can vote by posting a message here. > Voters should clearly say "Yes" or "No", and can give > an optional, very brief (one or two sentence) > reason for their vote. > Thanks! That's certainly a good thing to do. CChris > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
10. Re: Homosequences - Start Again
- Posted by Bernie Ryan <xotron at b?uefrog?com> Aug 16, 2007
- 461 views
- Last edited Aug 17, 2007
Robert Craig wrote: > > CChris wrote: > > The only consistent plan I see in the discussions is: hey, don't change > > anything. > > Otherwise, as you say, it's just a collection of individual needs which are > > more or less shared. Trying to discuss things at a higher level elicits a > > "too > > complicated" response, which is almost equivalent to a death sentence on the > > topic being considered any further. I've never seen this "too complicated" > > thing > > anywhere else. > > What other forums do you participate in, > where things are very different? > > > As I have said in the past, one of the main issues is that there is a small > > group of say 20 regular posters (often quite less) at any given time. How > > this > > group is representative of the hopefully larger user community is a mystery. > > In theory, Rob may have clues - if any feedback is emailed, it will be at > > RDS. > > When I was still getting registrations, 80-90% of the people > who registered were people who had never posted a single message > on EUforum. These days I still get email from people who never post here. > However, I now have less of an idea of how many users there are "out there". > > Most people are not keenly interested in language design, > or even if they are, they don't feel qualified to comment > on ideas put forward by people who have been using Euphoria > for many years, have gone through the source code, etc. > > Most people do not have problems in using a relatively > simple language like Euphoria, that require > clarification on this forum (assuming they even have > the required English skills to post). > > > Euphoria was designed as the fastest possible interpreter > > True to some extent. > > > - makes sense on 40MHz machines, perhaps less today. > > People will always value performance, perhaps not in an > individual program, but when deciding what language > to invest their time in. > > The first PC that I ran Euphoria on was a 486 50 MHz machine. > When that machine first came out, I remember reading an > article that speculated that only professionals in certain areas, > and other "power users" would ever need that kind of speed. > > With faster machines and huge memories, you could also argue > that fewer will use C/C++, and more will want something easier > to learn and debug with, like Euphoria. > > > It was designed for the installer to fit on a > > floppy, > > Not true. > > > but machines may no longer have a floppy drive today. > > Consistency with "business models", or user's native task/problem > > representation, > > is quite absent - except when that model happen to match the heterogeneous > > sequence > > pattern -. What matters is less many keywords and thinner docs, it seems. > > One of the main goals, was to make a simpler language > that amateurs, hobbyists etc. could easily learn and use. > It was never my intention to compete against C++ and Microsoft > in the professional arena. > > > > If the solution were considered at a higher-level, it would be the sort of > enhancement</font></i> > > > that elevates the language to another plane – not just sugar. > > > > 150% agreed. > > Then propose something that will truely take Euphoria "to a higher plane". > > > > Another completely different example. When a proposed new function is > > > discussed, > > > the discussion starts with an implementation, someone else comes up with a > > > different > > > implementation with different parameters and/or return values, someone > > > else > > > starts talking at the machine-level about how fast it will be if you run > > > it > > > in a million-fold loop, and someone else says it's all crap, etc, and each > > > person > > > seems to have a proprietary interest in his own implementation or idea. > > > > You forgot adding that then the discussion dies without any decision being > > recorded. > > OK, from now on, I think anyone who is serious about a proposal > should eventually, after a period of discussion and analysis, > write a summary of his/her (revised) proposal, and call for a vote. > > People can vote by posting a message here. > Voters should clearly say "Yes" or "No", and can give > an optional, very brief (one or two sentence) > reason for their vote. > Rob: I agree 100% with this. It seems that some users come along and are always trying to push the langauge away from its orginal purpose. I chose to use Euphoria because of it's simplicity and ease of use. I often see user's objecting to the way the langauge works. Then I look in the archive to see what programs they have written and I find a couple of small simple programs that don't require any extra features or special skill to write. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan