1. RE: Block Commenting
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
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
>
> > 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
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
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
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
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
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
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
