1. RE: Block Commenting
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 03, 2003
- 539 views
Block comments would be a godsend, as well as a number of other bits of shorthand I'd like to see. I was actually thinking about this recently -- what if any of us could add any kind of short-hand to Euphoria that we liked? Now of course I can make a pre-processor that converts my special code to Euphoria-compliant code if I want, but then you've got to manage different sets of source files, ex.err will refer to the final version only, etc. What if there was a standard pre-processing protocol built-in the interpreter? Users could optionally link a pre-processor syntax file to the interpreter, which would automatically convert the user source files to regular Euphoria before it gets on with the actual interpreting. In other words, allow custom exentions to the parser. And when errors occur, the line numbers could be synchronized with the original source (or with the converted source as well as an option). Now this is a project that would probably need to tackled by one of us, but it would be a lot more feasible if some of the facility was built-in to the interpreter. I suppose you could make a front-end that did the preprocessing, called the interpreter, and caught the error file, but there would be more overhead. -- Andy Derek Parnell wrote: > > > ----- Original Message ----- > From: "Robert Craig" <rds at RapidEuphoria.com> > To: "EUforum" <EUforum at topica.com> > Sent: Sunday, August 03, 2003 11:49 AM > Subject: Re: Block Commenting > > > > Dave Probert wrote: > > > Any chance we'll see block commenting abilities in the next Euphoria? > > > > I don't think so. > > I'm not interested in having two different ways > > to write comments. > > And yet your *customers* are. Interesting, no? > > >In ed, I hit F12 a bunch of times > > to comment out a block. (uncommenting isn't quite as easy) > > And why were block comments invented? To make life easier for the CODER > not the language author. > > > > Also is there any chance of gathering together some of the more useful > > > (small!) code funcs/procs, that are often rewritten by coders, into a > > > base include file (ie one that is supplied with the standard Euphoria > > > download)? > > > > Do you want me to maintain a bunch of code written > > by other people? When they change/improve their code > > will I have to keep my version up to date as well? > > Of course not! However, some of the submissions (and stuff not > submitted) are so common that you ought to consider making them standard > (read: RDS Supported) routines. For example: abs(). > > Another 'compromise' could be to make RDS's Euphoria have the ability to > read directly from ZIP files. A ZIP file could contain a set of normal > 'include files'. This would be a real library (a collection of books in > one place) facility. The commonly available tools could be used to > maintain the library contents as updated versions come in. JAVA uses > this type of facility to good effect. > > Would it really hurt RDS to take on a bit more responsibility for this? > I'd pay for such an 'add-on' service. > > > > Possibly worth asking for submissions for the above. > > > > > > The main reason for this would be to reduce the number of "This > > > application requires the xxx library to work" when people supply their > > > tools (or else people often include them as well, so there can be > > > various versions of the same file located in many folders). > > > > Maybe we just need a big index that you can search > > that will tell you where to find the latest version > > of an include file. I could periodically run > > a program that would go through all 1100+ .zip files, > > and prepare a sorted list of all the contained files, > > along with their time stamp and size. Maybe I could > > list all the global symbols and index them somehow too. > > Wouldn't hurt to have that service available either, Robert. Thanks for > the offer; its appreciated. > > -- > Derek >
2. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 03, 2003
- 475 views
Andy Serpa wrote: > Block comments would be a godsend, as well as a number of other bits of > shorthand I'd like to see. I like to share with Robert on this one: I don't care for block comments either. Tmo line comments have the great side effect of being very "visible" in large code files. Actually, I like to add additional "visibility" to comments by drawing lines (sort of) around my comments. Besides, most modern editors have the option to convert blocks of text into comments or back using line-comment identifiers. <snip> > What if there was a standard pre-processing protocol built-in the > interpreter? Users could optionally link a pre-processor syntax file to > the interpreter, which would automatically convert the user source files > > to regular Euphoria before it gets on with the actual interpreting. In > other words, allow custom exentions to the parser. And when errors > occur, the line numbers could be synchronized with the original source > (or with the converted source as well as an option). I don't like that either. From a performance pov I would say to keep the interpreter as the "engine" to run programs on, nothing more or less than that. Extentions to what Euphoria can do are handled nicely by the include system and custom functions. I quite like Euphoria for this. Most of what you want can be handled in a good IDE and kept out of the way in the final version of a project. For my own IDE project I will most certainly look into several ideas like these to see what can be incorporated. Hans Peter Willems
3. RE: Block Commenting
- Posted by Andy Serpa <ac at onehorseshy.com> Aug 03, 2003
- 486 views
> > > Block comments would be a godsend, as well as a number of other bits of > > shorthand I'd like to see. > > I like to share with Robert on this one: I don't care for block > comments either. Tmo line comments have the great side effect of > being very "visible" in large code files. Actually, I like to add > additional "visibility" to comments by drawing lines (sort of) > around my comments. > > Besides, most modern editors have the option to convert blocks > of text into comments or back using line-comment identifiers. > > <snip> No one would force you to use block comments if you don't like them. Line-comments would still exist, just like now. > > What if there was a standard pre-processing protocol built-in the > > interpreter? Users could optionally link a pre-processor syntax file to > > the interpreter, which would automatically convert the user source files > > > > > > to regular Euphoria before it gets on with the actual interpreting. In > > other words, allow custom exentions to the parser. And when errors > > occur, the line numbers could be synchronized with the original source > > (or with the converted source as well as an option). > > I don't like that either. From a performance pov I would say > to keep the interpreter as the "engine" to run programs on, > nothing more or less than that. > Extentions to what Euphoria can do are handled nicely by > the include system and custom functions. I quite like Euphoria > for this. > > Most of what you want can be handled in a good IDE and kept > out of the way in the final version of a project. > For my own IDE project I will most certainly look into several > ideas like these to see what can be incorporated. > It could be handled a number of different ways, I suppose. But any performance loss would only occur on start-up when loading in the file, and would be neglible I would think. Since it is a pre-processing step, it wouldn't effect the speed of the program at all. It would speed up YOUR performance though by allowing you to code faster, don't forget that.
4. RE: Block Commenting
- Posted by gertie at visionsix.com Aug 03, 2003
- 482 views
On 3 Aug 2003, at 13:34, Andy Serpa wrote: > > > > > Block comments would be a godsend, as well as a number of other bits of > > > shorthand I'd like to see. > > > > I like to share with Robert on this one: I don't care for block > > comments either. Tmo line comments have the great side effect of > > being very "visible" in large code files. Actually, I like to add > > additional "visibility" to comments by drawing lines (sort of) > > around my comments. > > > > Besides, most modern editors have the option to convert blocks > > of text into comments or back using line-comment identifiers. > > > > <snip> > > No one would force you to use block comments if you don't like them. > Line-comments would still exist, just like now. Ya know, since RobC wouldn't add this stuff, Bliss/Bach was written, and does have it. And classes, and goto, and some other stuff. Kat
5. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 03, 2003
- 472 views
Andy Serpa wrote: > No one would force you to use block comments if you don't like them. > Line-comments would still exist, just like now. I'll put it another way: the fact that block comments are not supported is no problem for me Of course, if it would be supported it would not be a problem as well. I just wanted to state my view in accordance with Robert's statement. > It could be handled a number of different ways, I suppose. But any > performance loss would only occur on start-up when loading in the file, > and would be neglible I would think. I'm building (large) custom applications for customers on a daily basis, believe me that performance is *always* an issue. > Since it is a pre-processing step, > it wouldn't effect the speed of the program at all. It would speed up > YOUR performance though by allowing you to code faster, don't forget > that. My pov at this is formed because lately I've reviewed several programming languages in search of a new development platform for my company. The resulting conclusion is that most languages that are of interest need 10 Mb or more of virtual machine, interpreter or other supporting files to be able to run just a simple program. The way I see it is that this is the result of decisions to implement as much stuff as discussed here into the core support files of a language, making it bloated and in need of a fairly fast machine to have usable performance. Try to run a Python based program and you know what I mean. As a language, Python is quite cool and supports everything you are talking about and much more, but clearly at a price. I'm not against progress, but performance-wise the fastest languages are the ones with a small command set and specific functionality added as auxiliary functions on a per-project basis. Hans Peter Willems
6. RE: Block Commenting
- Posted by Al Getz <Xaxo at aol.com> Aug 03, 2003
- 498 views
Robert Craig wrote: Dave Probert wrote: > Any chance we'll see block commenting abilities in the next Euphoria? I don't think so. I'm not interested in having two different ways to write comments. In ed, I hit F12 a bunch of times to comment out a block. (uncommenting isn't quite as easy) > Also is there any chance of gathering together some of the more useful > (small!) code funcs/procs, that are often rewritten by coders, into a > base include file (ie one that is supplied with the standard Euphoria > download)? Do you want me to maintain a bunch of code written by other people? When they change/improve their code will I have to keep my version up to date as well? > Possibly worth asking for submissions for the above. > > The main reason for this would be to reduce the number of "This > application requires the xxx library to work" when people supply their > tools (or else people often include them as well, so there can be > various versions of the same file located in many folders). Maybe we just need a big index that you can search that will tell you where to find the latest version of an include file. I could periodically run a program that would go through all 1100+ .zip files, and prepare a sorted list of all the contained files, along with their time stamp and size. Maybe I could list all the global symbols and index them somehow too. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com Hello Rob and others, BI block commenting would be nice, but i've had block commenting since the year 2000 because i built it into my own 'personal' editor. Here's the workaround... One way for people to have 'block' commenting is simply to add that to their editor, or ask the person that wrote the editor they use to add it. It's the easiest thing to add i must say, because all you have to do is allow the user to select a block of text (all editors do this i think) and then click a menu that inserts "--" at the start of each line selected, or optionally searches for the first non space character in each line and puts "--" right before that character. To remove the commenting, the user again selects the text block and then clicks on another menu item (Rems->Remove Rems) and it searches the beginning of text to remove "--" from the start of the lines, or optionally searches the whole line and removes the rems. The above is useful for writing larger blocks of notes for the user of the file, or for debugging when you might want to rem out a larger section of code to study the effects of leaving it out, and works basically the same way block rems work in C. My editor does the same thing for block indents, adding or removing as decisions are made to add or remove levels of nested code, and since most editors will want this too, why not add the block remming right into the editor? From a file parsing point of view, i'd say it would take longer to hunt for the ending rem char then to simply read in each line and know ahead of time you can allow the interp. to ignore it, unless maybe there was a restriction imposed that the block rems had to be in the very first column of the text--which would actually speed things up but would have that rather nasty restriction. In any case, i've been using the editor multiline rem technique for about three years or so and have found it to be satisfactory. I'd welcome BI multiline remming, but only if it didnt slow the parsing of the interpreted (e,ex,ew,exw) files. Take care for now, Al
7. RE: Block Commenting
- Posted by Dave Probert <zingo at purpletiger.com> Aug 03, 2003
- 472 views
Derek Parnell wrote: > > > > Dave Probert wrote: > > > Any chance we'll see block commenting abilities in the next Euphoria? > > > > I don't think so. > > I'm not interested in having two different ways > > to write comments. > > And yet your *customers* are. Interesting, no? > I really have to agree wholeheartedly with Derek on this - is this a language that is being improved, or just your own toy? If it's the latter then you're gonna LOSE a lot of potential customers with that sort of attitude. > >In ed, I hit F12 a bunch of times > > to comment out a block. (uncommenting isn't quite as easy) > > And why were block comments invented? To make life easier for the CODER > not the language author. > Of the top 5 programming languages how many don't have block commenting? If I wanted to program in NotePad (Not that I'm that crazy!), I can - for C, C++, Java, PHP, JavaScript, HTML, ActionScript and a huge bunch of others. I don't see that the editor should control the language features!!! I will say that I'm enjoying learning Euphoria, but it's a real struggle when comparing it to more 'professional' languages that have been around for a few years - Oh wait - so has Euphoria!!! If the task of adding or improving features is too hard a task then may I suggest that you look at getting some help. > > > Also is there any chance of gathering together some of the more useful > > > (small!) code funcs/procs, that are often rewritten by coders, into a > > > base include file (ie one that is supplied with the standard Euphoria > > > download)? > > > > Do you want me to maintain a bunch of code written > > by other people? When they change/improve their code > > will I have to keep my version up to date as well? > > Of course not! However, some of the submissions (and stuff not > submitted) are so common that you ought to consider making them standard > (read: RDS Supported) routines. For example: abs(). > Again, I have to agree with Derek. The route to a full blown product is versatility and a good range of features - Euphoria certainly works Ok for the former, but falls down with the latter. I was not suggesting a HUGE library of routines, but just the more common ones. Why not have an 'official' package, some nice person could be the one to do the maintenance - just like Derek does with Win32Lib (thankyou). Sorry, I can't volunteer for the task - I'm only a beginner with this tool. > Would it really hurt RDS to take on a bit more responsibility for this? > I'd pay for such an 'add-on' service. > It would definately help persuade me and, I assume, many others in actually going beyond the free download. I will reiterate that I'm enjoying Ehphoria and like it a lot, but would love to see some sort of organisation that takes it beyond just a 'Hobby' language. PS. Look at the history of PHP from a few years ago when it was PHP/FI - now it's a major system on many, many web servers. And is constantly being improved.
8. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 03, 2003
- 477 views
jbrown105 at speedymail.org wrote: > You can't add new syntax to Euphoria with its existing facilities tho. > You either need a preprocessor or wait for RDS to add the new syntax > into > the core Euphoria language. What actual additions to the language do you need ? For me all the necessary stuff is in there. There are a few functions I still didn't find yet, but I'm sure they have been written by someone already. > Dredge does this, but its outputed files are very slow (due to the way > variables are handled for pointers and goto support) and also very ugly > looking. (One plus of Dredge is that it can do partcial conversion of an > ex.err > file into a dredge.err file so you know which file and which line the > error > occurred in the original source code. However, again due to the way > dredge > handles variables, and also due to the way the interpreter trunacates > long sequences in ex.err, it can't handle a full conversion of variables > and > their values. Too bad Rob won't give us the option of turning on support > for seeing the full sequence in ex.err, that would give a huge boost to > Dredge.) I'll take a peek at Dredge later to see what it can add. > That is very true (altho it should be 'editor' not IDE, but otherwise we > are > in agreement). A good editor (baring that, a properly modified ed.ex) > can > easily handle such special syntax at will. Why "editor" insread of IDE. Tmo all the editors fall short when it comes to integrating additional stuff into your development workflow. I think a real IDE has much more to offer (like automatically running pre-processors before actually executing the code in the interpreter). Hans Peter Willems
9. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 03, 2003
- 479 views
Dave Probert wrote: > Of the top 5 programming languages how many don't have block commenting? > In the top 5 programming languages, how does this reflect on the actual usability of those languages ? Indeed: not at all. > If I wanted to program in NotePad (Not that I'm that crazy!), I can - > for C, C++, Java, PHP, JavaScript, HTML, ActionScript and a huge bunch > of others. I don't see that the editor should control the language > features!!! Comments are a language feature based on the ability or inability to use comments. How they are implemented has no effect on the usability of the language, but more on how the coder builds it's embedded documentation and THAT can be aided big time with a good editor. Again it has nothing to do with the functional content of the language in question. > I will say that I'm enjoying learning Euphoria, but it's a real struggle > > when comparing it to more 'professional' languages that have been around > > for a few years - Oh wait - so has Euphoria!!! Why is it "a struggle" ??? I've been programming in more then 20 languages over the last 22 years and Euphoria is one of the most inviting languages I've come across. Again, this has nothing to do with the way that comments are implemented in the language. > If the task of adding or improving features is too hard a task then may > I suggest that you look at getting some help. Tmo Robert is doing a great job so far > Again, I have to agree with Derek. The route to a full blown product is > > versatility and a good range of features - Euphoria certainly works Ok > for the former, but falls down with the latter. So what features do you miss ??? When I entered this community only a few weeks ago I didn't had insight in what is actually available and mentioned string- functions, only to have Kat point me to some very impressive libraries. Even more so, something like the stringtoken library isn't even available in many of your so called top 5 languages. > I was not suggesting a HUGE library of routines, but just the more > common ones. And who is to decide what is "common" ? This is very much dependant on the goal that someone is coding for. One man's poison is another man's bread > It would definately help persuade me and, I assume, many others in > actually going beyond the free download. I registered for the "full" version about one week after I found Euphoria. I'm having licenses for development systems costing 200 times more (and over that) then the cost of an Euphoria license, and those systems aren't even cross platform. > I will reiterate that I'm enjoying Ehphoria and like it a lot, but would > > love to see some sort of organisation that takes it beyond just a > 'Hobby' language. I don't perceive Euphoria as a hobby language and I'm looking at it seriously to replace our current development platforms for professional software development. What Euphoria needs more then everything else is a good IDE that will make it usable for large scale software projects. And that is something that's definitely outside the scope of the interpreter. > PS. Look at the history of PHP from a few years ago when it was PHP/FI > - now it's a major system on many, many web servers. And is constantly > being improved. We just saw the 2.4 release of Euphoria. No reason to complain there either. This language is actively being maintained. That is more then can be said of some "top 5 languages" with frozen specs. Hans Peter Willems
10. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 03, 2003
- 486 views
jbrown105 at speedymail.org wrote: > An IDE is mostly good for developing GUI applications. If you don't need > the app > to have a GUI then you don't need an IDE to make the app. Sorry to say, but you are mistaken here. An IDE can include gui builders, but that's not always the case. When you are developing large software systems you also need documentation maintanance, test-integration, quality assurance, bug-tracking and task-tracking, build management, installer generation, version management and much more: loads of stuff that has little to do with a editor but much more with a Integrated Development Environment (or IDE). Ever heard of iCase ? > Also, if you write your own editor (possible if you base it on ed.ex, > ee.ex, > or even Meditor) then you can add whatever you need to it, w/o making it > into > a full IDE. A real IDE is something completely different from a Editor, see comment above. I have been a software developer for the last 22 years and after you have written as many code as I have done (I've stopped counting after the first million lines of code) you know that an editor is just a small part of what you need in software projects. Btw, for those interested in real Software Engineering, visit the SEI website: http://www.sei.cmu.edu > BTW, what does Tmo mean? To My Opinion. Hans Peter Willems
11. RE: Block Commenting
- Posted by eugtk at yahoo.com Aug 03, 2003
- 486 views
--- Peter Willems <peter at integratedmoves.com> wrote: > Why is it "a struggle" ??? > I've been programming in more then 20 languages > over the last > 22 years and Euphoria is one of the most > inviting languages I've > come across. <snip> Yes, that first impression is shared by many. Put Eu to work for a while, and it's still 'inviting', but its shortcomings begin to surface. > So what features do you miss ??? Structures, Useful namespacing, Real database connectivity, Exception handling, to name a few. Irv
12. RE: Block Commenting
- Posted by Ray Smith <smithr at ix.net.au> Aug 04, 2003
- 509 views
Peter Willems wrote: > My pov at this is formed because lately I've reviewed several > programming languages in search of a new development platform > for my company. The resulting conclusion is that most languages > that are of interest need 10 Mb or more of virtual machine, > interpreter or other supporting files to be able to run just > a simple program. The way I see it is that this is the result of > decisions to implement as much stuff as discussed here into the > core support files of a language, making it bloated and in need > of a fairly fast machine to have usable performance. > Try to run a Python based program and you know what I mean. > As a language, Python is quite cool and supports everything > you are talking about and much more, but clearly at a price. > > I'm not against progress, but performance-wise the fastest > languages are the ones with a small command set and specific > functionality added as auxiliary functions on a per-project > basis. > > Hans Peter Willems I haven't followed this thread all the way through but ... Since I was a Euphoria fanatic and am now Python convert I wanted to respond with the reasons why I have switched ... I agree that perfectly you it would be nice to have a development environment that had a full set of features, required a small amount of RAM to execute and run at the speed of light, since this doesn't exist the question becomes ... what are you willing to sacrifice? For me it was RAM usage and execution speed. "My" requirements are to allow me as a developer to produce software as easily as possible, make it as stable as possible, and allow me to modify/enhance my programs in the future as easily as possible. i.e. I consider "my" resources to be more valuable then my computers resources. Your "performance-wise" comment is 100% true, but I can happily run almost all Python programs I have ever seen on a PII 300 with 128MB RAM. If you're in the business of delivering software to users who don't have enough money to spend $200 on a better computer I think you have your business plan wrong. Is it better to take 12 months to produce a software package with Euphoria that runs on 100% of PC's ... or ... Send 2 or 3 months to do the same thing with Python (or another language) that works on 95% of PC's? (Unless you live in Russia and your first name is Igor!!) Euphoria isn't being developeded nearly fast enough, it's implossible for one person to develop a language with a "full" set of features that can compete with other languages of today. The fact that Euphoria doesn't have threads and execption handling means that some tasks are impossible. You can build as many libraries and add-ons as you want but some tasks are impossible. The user base just isn't strong enough either. I'd rather use Perl than Euphoria now days. I hate Perl (so that tells you what I think about the future of Euphoria), but at least it has a full set of features, has a HUGE library / user base and is being actively developed. I almost consider Python to be a "Super" Euphoria. Not quiet, but it does have a similar elegence. As I've always said though, everyone is free to make their own chooses and if Euphoria, Python, Perl etc etc allows you to develop software the way you want it then be happy with your choice. Regards, Ray Smith http://rays-web.com
13. RE: Block Commenting
- Posted by Ray Smith <smithr at ix.net.au> Aug 04, 2003
- 466 views
Dave Probert wrote: > I really have to agree wholeheartedly with Derek on this - is this a > language that is being improved, or just your own toy? If it's the > latter then you're gonna LOSE a lot of potential customers with that > sort of attitude. It is without a doubt the toy of "RDS". That's not say it isn't useful for a whole lot of programs. The "gonna LOSE" comment should probably be, "Have LOST and will LOSE many more" If you look through the archives many many people have come and gone over the years. People who were very good programmers and very active on the list and in the community. Is it surprising to see them go? If RDS added just a few features that these people wanted (like the block comments request now) ... how many of these people who have left would have stayed? What sort of extra contribution to Eu would have these people made? The attitude of "I don't agree therefore it won't happen" just doesn't give people a warm fuzzie feeling. This is obviously where open source software thrives. If you "really" do want it, you can add it yourself. If enough people think it's a good idea you can almost always push your changes back into the master/offical version. No language is perfect, no language implements every request made, but I'm 100% certain RDS could add many many improvments to Euphoria that would make many many people much happier without adding the kitchen sink. I've said this many times ... "If Euphoria does what you want it to do now, great. If it doesn't, then don't hold your breath". I think I should put that quote on a web page somewhere :) Regards, Ray Smith http://rays-web.com
14. RE: Block Commenting
- Posted by kbochert at copper.net Aug 04, 2003
- 470 views
On 3 Aug 2003 at 15:01, eugtk at yahoo.com wrote: > > Yes, that first impression is shared by many. > Put Eu to work for a while, and it's still > 'inviting', but its shortcomings begin to > surface. > > > So what features do you miss ??? > > Structures, Bach has that. > Useful namespacing, Bach has that. > Real database connectivity, Bach has that. > Exception handling, Bach has that. Karl Bochert
15. RE: Block Commenting
- Posted by kbochert at copper.net Aug 04, 2003
- 478 views
On 3 Aug 2003 at 14:45, Al Getz wrote: > BI block commenting would be nice, but i've had block commenting > since the year 2000 because i built it into my own 'personal' > editor. > > Here's the workaround... > > One way for people to have 'block' commenting is simply to add > that to their editor, or ask the person that wrote the editor > they use to add it. It's the easiest thing to add i must say, > because all you have to do is allow the user to select a block > of text (all editors do this i think) and then click a menu that > inserts "--" at the start of each line selected, or optionally > searches for the first non space character in each line and puts "--" > right before that character. > To remove the commenting, the user again selects the text block > and then clicks on another menu item (Rems->Remove Rems) and > it searches the beginning of text to remove "--" from the > start of the lines, or optionally searches the whole line > and removes the rems. > > The above is useful for writing larger blocks of notes for the > user of the file, or for debugging when you might want to rem > out a larger section of code to study the effects of leaving it > out, and works basically the same way block rems work in C. > > My editor does the same thing for block indents, adding or > removing as decisions are made to add or remove levels of > nested code, and since most editors will want this too, why not > add the block remming right into the editor? > > >From a file parsing point of view, i'd say it would take longer > to hunt for the ending rem char then to simply read in each line > and know ahead of time you can allow the interp. to ignore it, > unless maybe there was a restriction imposed that the block rems > had to be in the very first column of the text--which would actually > speed things up but would have that rather nasty restriction. > Bach restricts the block comment to the first non-white chars on a line. The opening block comment really should be restricted this way. It might be useful to allow the closing block comment to be at the end of the line, but forcing it to be at the start makes it easier to find and read . This also means that the parser is not slowed at all, and makes it easier to write a colorizer for an editor -- Bach's took under 1/2hr, while I have tried for years to handle C's /*..*/, so far without success. I colorize my nested blocks differently than single line ones -- makes them stand out nicely. Block comments can be well used as part of a documentation generator scheme. File documentation headers look quite different with the left side blank, which some (me) may like. Karl Bochert
16. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 04, 2003
- 483 views
eugtk at yahoo.com wrote: > Yes, that first impression is shared by many. > Put Eu to work for a while, and it's still > 'inviting', but its shortcomings begin to > surface. I'm working with WinDev for several years now. I have three licenses for my company which cost about Euro 1500 each, not counting the upgrades over the last few years (also a nice sum). It is a very capable and "deep" development environment, but it has it's shortcomings also..... some very nasty. When you are entering into contract development you will always run into corners where your tool won't perform as well, no matter the price tag. > Structures, In what way.... this is not realy clear to me. > Useful namespacing, I didn't miss it in all my other languages, don't miss it now. > Real database connectivity, How "real" must it be. The available stuff works, doen't it. > Exception handling, WinDev does have exception handling, but not that good. The result of that is that you are pushed to write fool-proof code. For my client it doesn matter if the software crashes with a generated error code, or if it just stops working at that point. In both cases there is a problem with usability of the software that needs to be debugged and solved. I have asked for better error trapping myself just recently, but I realized that it is no biggy as for the above explanation. Hans Peter Willems
17. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 04, 2003
- 472 views
Ray Smith wrote: > Since I was a Euphoria fanatic and am now Python convert I wanted to > respond with the reasons why I have switched ... I seriously looked at Python. I'm very impressed with it's feature set and I think we will add Python to our workbench anyway. Did you ever look at Erlang, it's as impressive... (www.erlang.org) > I agree that perfectly you it would be nice to have a development > environment that had a full set of features, required a small amount > of RAM to execute and run at the speed of light, > since this doesn't exist the question becomes ... what are you > willing to sacrifice? Well, in my case I'll sacrifice the time to build that environment myself, especially as my pov is that the language/compiler/ interpreter is just a part of that. > For me it was RAM usage and execution speed. > "My" requirements are to allow me as a developer to produce software > as easily as possible, make it as stable as possible, and allow me > to modify/enhance my programs in the future as easily as possible. > > i.e. I consider "my" resources to be more valuable then my computers > resources. I do agree with you, but in my case I also need my clients to see it that way. > Your "performance-wise" comment is 100% true, but I can happily run > almost all Python programs I have ever seen on a PII 300 with 128MB > RAM. > If you're in the business of delivering software to users who don't > have enough money to spend $200 on a better computer I think you > have your business plan wrong. I did run some Python based programs on a PIII-450 with 128 Mb ram and was very underwhelmed. And $200 for a better computer is not an issue when it is YOUR computer. Try telling a client that he has to migrate 50 workstations, including the cost for the actual migration (workstation downtime, etc.). > Is it better to take 12 months to produce a software package with > Euphoria that runs on 100% of PC's ... or ... > Send 2 or 3 months to do the same thing with Python (or another > language) that works on 95% of PC's? It's best to have a IDE that let you build software fast and in a controlled/documented fashion, regardless of the language that you are using. > Euphoria isn't being developeded nearly fast enough, it's implossible > for one person to develop a language with a "full" set of features > that can compete with other languages of today. I have seen several situations where ONE person creates a (software) product that can compete with large scale product development teams. Don't forget that with large teams a great part of available time get spend on getting everyone to agree on certain points, communicating stuff around the group, etc. > The fact that Euphoria doesn't have threads and execption handling > means that some tasks are impossible. You can build as many > libraries and add-ons as you want but some tasks are impossible. WinDev also does not have threads and it has poor exception handling. Nevertheless it's a very professional development tool that is used in big projects. > The user base just isn't strong enough either. I'd rather use Perl > than Euphoria now days. I hate Perl (so that tells you what I think > about the future of Euphoria), but at least it has a full set > of features, has a HUGE library / user base and is being actively > developed. The user base does not have any inclination as to how usable the language is for me. > I almost consider Python to be a "Super" Euphoria. Not quiet, but > it does have a similar elegence. I agree that Python is a great language, just not fast enough for me. I looked around to see if there was any option to compile Python code to machine language but there isn't. At the same time Robert manages to deliver a Eu2C convertor, taking care of it for Euphoria. > As I've always said though, everyone is free to make their own > chooses and if Euphoria, Python, Perl etc etc allows you to develop > software the way you want it then be happy with your choice. Of course Hans Peter Willems
18. RE: Block Commenting
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 04, 2003
- 520 views
eugtk at yahoo.com wrote: > > --- Peter Willems <peter at integratedmoves.com> wrote: > > > So what features do you miss ??? > > Structures, > Useful namespacing, > Real database connectivity, > Exception handling, I can agree with structures. I think that namespacing should be unbroken, if not yet at its full potential, by 2.5. It will at least solve some real problems, even if it doesn't add any more power to the language. I'm curious, though, what your definition is of 'Real database connectivity.' There are a couple of starts at using ODBC in the archives, one of them mine (the other by Tone Skoda). I can tell you that one reason it was left so incomplete was the underwhelming response it got--perhaps I should pick it up again. But, there are several other wrappers for various database formats (I can recall MySQL and Tsunami record manager contributions off the top of my head, but I know there are ). Additionally, you could use EuCOM to wrap ADO or OLEDB (which I think give you pretty full ODBC functionality) or straight MS Access. In addition, there's (still very immature, but I can't resist a shameless plug) EuSQL. [Formal] Exception handling remains a deep dark hole of confusion for me. It seems to be obfuscation more than anything else. My personal needs tend to be met by using an object and testing for a proper value/datatype--when I bother with error checking or validation at all. :( Matt Lewis
19. RE: Block Commenting
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 04, 2003
- 491 views
OK, I'll take a look at it. What specifically did you want to be able to do with it. This will help me prioritize development. Matt Lewis George Walters wrote: > > > Mike, I really wish you would continue work on your OBDC. I think > the community needs it. I suspect (as in my case) that my > development (consisted of mostly learning) had not gotten to the > point where I could use it.... but now it would be great to have it. > > george
20. RE: Block Commenting
- Posted by Al Getz <Xaxo at aol.com> Aug 04, 2003
- 464 views
Matt Lewis wrote: > > > eugtk at yahoo.com wrote: > > > > --- Peter Willems <peter at integratedmoves.com> wrote: > > > > > So what features do you miss ??? > > > > Structures, > > Useful namespacing, > > Real database connectivity, > > Exception handling, > > > I can agree with structures. I think that namespacing should be > unbroken, if not yet at its full potential, by 2.5. It will at least > solve some real problems, even if it doesn't add any more power to the > language. > > I'm curious, though, what your definition is of 'Real database > connectivity.' There are a couple of starts at using ODBC in the > archives, one of them mine (the other by Tone Skoda). I can tell you > that one reason it was left so incomplete was the underwhelming response > > it got--perhaps I should pick it up again. But, there are several other > > wrappers for various database formats (I can recall MySQL and Tsunami > record manager contributions off the top of my head, but I know there > are ). Additionally, you could use EuCOM to wrap ADO or OLEDB (which I > think give you pretty full ODBC functionality) or straight MS Access. > In addition, there's (still very immature, but I can't resist a > shameless plug) EuSQL. > > [Formal] Exception handling remains a deep dark hole of confusion for > me. It seems to be obfuscation more than anything else. My personal > needs tend to be met by using an object and testing for a proper > value/datatype--when I bother with error checking or validation at all. > :( > > Matt Lewis > Hi there Matt and others, I just have to say that if a group of people are going to get together and ask Rob to implement a certain feature, then that feature should be something REALLY useful. Something that REALLY improves the language. Block commenting, although nice, doesnt really improve the language very much, because anything you can write now that also has a certain level of performance will still be the same after adding block commenting. I have to agree with structures and other C interface ideas, because any decent program these days has to interface to dll's of one kind or another. This would really be an improvement worth having. Also, lets not forget about something like constant sequences of single dimension for use with control structures (such as maintaining an id list) that could be used when real speed is needed. If not, then perhaps in addition to 'allocate' we could have 'reallocate' so that we could use memory blocks to achieve the same thing (using peek and poke). I asked Rob about 'reallocate' a while back and i think he wouldnt mind adding it, or else making 'allocate' work like 'reallocate'. Take care for now, Al
21. RE: Block Commenting
- Posted by Al Getz <Xaxo at aol.com> Aug 05, 2003
- 476 views
Pete Lomax wrote: > > > On Mon, 4 Aug 2003 15:19:16 +0000, Al Getz <Xaxo at aol.com> wrote: > > >Also, lets not forget about something like constant sequences > >of single dimension for use with control structures (such as > >maintaining an id list) that could be used when real speed > >is needed. > > Err... Isn't that really specialised, like mpeg6 or cypher-chracking > black belt? > > Pete > Hello Pete, Actually, what i ment was an array of type 'long' for use with control structures usually found in libraries. Seems everyone likes to maintain a list of window handles that can be looked up via their respective ID value. This is very common practice. I could get by with having realloc() though and that would be easy to implement and very widely applicable to other kinds of code too. Take care for now, Al
22. RE: Block Commenting
- Posted by Ray Smith <smithr at ix.net.au> Aug 05, 2003
- 461 views
Peter Willems wrote: > > Ray Smith wrote: > > Is it better to take 12 months to produce a software package with > > Euphoria that runs on 100% of PC's ... or ... > > Send 2 or 3 months to do the same thing with Python (or another > > language) that works on 95% of PC's? > > It's best to have a IDE that let you build software fast and > in a controlled/documented fashion, regardless of the language > that you are using. An IDE isn't going to make developing programs quicker if the underlying language is missing features or libraries. E.g. If you need to use a Web Services object in Euphoria, or connect to a database that no one has written a library for ... a good IDE isn't going to be of much help. > > Euphoria isn't being developeded nearly fast enough, it's implossible > > for one person to develop a language with a "full" set of features > > that can compete with other languages of today. > > I have seen several situations where ONE person creates a > (software) product that can compete with large scale product > development teams. Don't forget that with large teams a great > part of available time get spend on getting everyone to agree > on certain points, communicating stuff around the group, etc. For me, Euphoria isn't one of them. > > The fact that Euphoria doesn't have threads and execption handling > > means that some tasks are impossible. You can build as many > > libraries and add-ons as you want but some tasks are impossible. > > WinDev also does not have threads and it has poor exception > handling. Nevertheless it's a very professional development > tool that is used in big projects. So some tasks in WinDev are impossible as well :) > > The user base just isn't strong enough either. I'd rather use Perl > > than Euphoria now days. I hate Perl (so that tells you what I think > > about the future of Euphoria), but at least it has a full set > > of features, has a HUGE library / user base and is being actively > > developed. > > The user base does not have any inclination as to how usable > the language is for me. The user base has a huge impact when much of the functionality required comes from people other than the main developer. If you only had "Euphoria" that was downloaded from RDS to use, with no libraries from the archive etc ... Euphoria would be a bit of a white elephant!! The user base has as much (if not more) impact on how successful a language will be. Especially for the small and open source languages. Regards, Ray Smith http://rays-web.com
23. RE: Block Commenting
- Posted by Peter Willems <peter at integratedmoves.com> Aug 05, 2003
- 477 views
Ray Smith wrote: > An IDE isn't going to make developing programs quicker if the > underlying language is missing features or libraries. > E.g. If you need to use a Web Services object in Euphoria, or connect > to a database that no one has written a library for ... a good IDE > isn't going to be of much help. But it is a BIG help when you do have all these things in libraries and you want to manage all those libraries. <snip> > So some tasks in WinDev are impossible as well :) ... and still it is regarded as a very professional development environment, capable of very stable and feature rich programs that are used in enterprises all over the world. > The user base has a huge impact when much of the functionality > required comes from people other than the main developer. > If you only had "Euphoria" that was downloaded from RDS to use, with > no libraries from the archive etc ... Euphoria would be a bit of a > white elephant!! I must agree with that. It would mean that you have to write a lot of stuff yourself... as we did with WinDev (as there is only a small bit of auxilliary functions available in comparison with Euphoria). > The user base has as much (if not more) impact on how successful > a language will be. Especially for the small and open source > languages. The success of a language is also depending on the willingness of companies to addopt it for serious projects. And that is very much depending on how good the language can be integrated in a controllable workflow: read IDE Hans Peter Willems