Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.

java-programmer, Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing. On Sat, 10 Sep 2005 14:42:07 GMT, DevarajA <email***@***.com> wrote:

>
>When you write an open bracket, immediately write the closing one. Then
>write the code between them, and you won't forget anything. This is what
>I always do and I've nevere left out a bracket.

Long ago, I programmed Slickedit to produce a right bracket every time
I typed a left bracket.
--
Al Balmer
Balmer Consulting
email***@***.com

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing. On Sat, 10 Sep 2005 14:42:07 GMT, DevarajA <email***@***.com> wrote:

>
>When you write an open bracket, immediately write the closing one. Then
>write the code between them, and you won't forget anything. This is what
>I always do and I've nevere left out a bracket.

Long ago, I programmed Slickedit to produce a right bracket every time
I typed a left bracket.
--
Al Balmer
Balmer Consulting
email***@***.com

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing. On Mon, 12 Sep 2005 15:44:19 GMT, "Oliver Wong" <email***@***.com>
wrote:

> DevarajA, your advice about always putting the closing bracket when you
>put an opening bracket is an excellent one, and one that I've been following
>myself. Incidentally, if you use the Eclipse IDE, it will automatically put
>the closing bracket for you.
>
>"DevarajA" <email***@***.com> wrote in message
>news:rVCUe.45294$email***@***.com...
>> Right now I realized that if you have many nested blocks it could be hard
>> to tell where the one to delete ends. In this case you can count the open
>> brackets and subtract one each close bracket you encounter. The close
>> bracket taking you to '0' is the last one. Hit del.
>
> In Eclipse, Visual Studio, and probably many other IDEs, you can put
>your cursor on the opening bracket of the block you want to delete, and the
>IDE will highlight the corresponding closing bracket, so you don't even need
>to do this counting manually.
>
Slickedit can be asked to highlight the entire block, and the delete
key does the rest.
--
Al Balmer
Balmer Consulting
email***@***.com

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Skybuck Flying" <email***@***.com> wrote in message
news:dfspg5$7s7$email***@***.com...

> I have proven that one style is cumbersome and therefore dumb and one
style
> is handy and therefore smart.

Debatable. What you have really proven is that you do not understand the
grammar.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Andrew McDonagh" <email***@***.com> wrote in message
news:dfub8f$t01$email***@***.com...
> Skybuck Flying wrote:
> > "Andrew McDonagh" <email***@***.com> wrote in message
> > news:dfsv1i$fmd$email***@***.com...
> >
> >>Skybuck Flying wrote:
> >>
> >>>Sometime ago on the comp.lang.c, I saw a teacher's post asking why C
> >
> >
> >>snipped very long message about badly written code and how to 'fix' it
> >>by making indentation better....
> >>You are missing the point....
> >
> >
> > No, I think you didn't read my post well enough.
>
> I did, I just don't agree with your premise.

No, you didnt read or understand it well enough.

>
> >
> > Here are the main points:
> >
> > Point 1: With the pascal style bracketing/layout it is easier to spot
> > missing brackets.
>
> The choice of '{}', 'begin end', ';', and any other language block
> scoping identifiers is irrelevant - they all suffer the same problems of
> people not aligning them.

I agree the choice of {} begin/end etc is irrelevant.

The aligning is most relevant.

The pascal style aligns it properly vertically like so:

if a<b then
begin

end;

Some C styles dont align like so:

if (A<b) {

}

Making it harder to spot where the brackets start and end in an eye's blink
like shown in previous examples.

Again you didnt read it well enough or didnt understand it ;)

>
> You may find the words 'begin & end' to be easier to read and thats fine
> - others find them cumbersome.

No you dont understand.

>
> > Point 2: Indentation can be used by the computer/compiler to spot
missing
> > brackets.
> > (It can figure out where statement blocks start and stop and where
missing
> > brackets are and can simply stop the flow of error messages. )
>
> In some languages yes, but not all languages could.
>
> >
> >
> >>Any modern IDE has a format code option which will layout the code
> >>regardless of your brackets - allowing you to see where the problem is.
> >
> >
> > I dont know about that maybe I am missing some points or maybe you
making
> > this up.
>
> Not making anything up...
> >
> > Some questions:
> >
> > Does borland delphi 2005 have such a code formatting option ?
> > Does visual studio .net 2003 have such a code formatting option ?
> > Does borland delphi 7 have such a code formatting option ?
> >
>
>
> I'm not sure about Delphi 2005 or VS2005 as haven't seen them...but let
> me google it...hang on in there... I can't find much info about VS or
> Delphi 2005 and Delphi 7 and earlier does not natively support
> formatting, but there are plenty of add-ons...
>
>
http://www.google.co.uk/search?hl=en&q=delphi+7+code+formatting&btnG=Google+Search&meta=
>
>
>
> > Can you name any modern IDE which has the claimed feature ?
>
> Eclipse, IntelliJ, jbuilder and more.....
>
> >
> >
> >>Second any method/procedure which is so long that its hard to see the
> >>logical parts of it, is too long....making smaller will help in numerous
> >>ways, not least making it easier to see the indent problems.
> >
> >
> > Point 2 does this automatically for you.
> > Point 1 helps you narrow it down.
> >
>
> True they would help with the symptom, but the cure would be not to
> create such long methods/procedures which cause mismatching blocks in
> the first place.
>
> The smaller a method the easier to read and see, add in code formatters
> and the problem 'justGoesAway'
>
> > Bye,
> > Skybuck.
> >
> >
>
> cheerio
>
> Andrew

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Bruce Roberts" <email***@***.com> wrote in message
news:2wiVe.1321$email***@***.com...
>
> "Skybuck Flying" <email***@***.com> wrote in message
> news:dfspg5$7s7$email***@***.com...
>
> > I have proven that one style is cumbersome and therefore dumb and one
> style
> > is handy and therefore smart.
>
> Debatable.

You can debate it all you want. Tests however will prove that one style is
fast at finding missing brackets and the other style is slow at it ;)

> What you have really proven is that you do not understand the
> grammar.

I don't feel there is anything wrong with it lol... but that's just me being
used to the dutch grammar.

I guess the correct english grammar could be:

I proofed... etc. instead of I have proven.

The difference could be something like this:

I proofed.... meaning: I did something

I have proven meaning: I own my own actions, I have done that... etc ;)

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Skybuck Flying" <email***@***.com> wrote in message
news:dg4vf1$53u$email***@***.com...
>
> "Bruce Roberts" <email***@***.com> wrote in message
> news:2wiVe.1321$email***@***.com...
>> What you have really proven is that you do not understand the
>> grammar.
>
> I don't feel there is anything wrong with it lol... but that's just me
> being
> used to the dutch grammar.

I think Bruce referring to the context-free grammar that describes the
Java language, not your usage of the English grammar.

- Oliver

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing. <email***@***.com> wrote in message
news:email***@***.com...
> As a test I loaded this snippet of code into a test.cpp
> file and sure enough the code folding quickly identified
> the missing bracket.

In other words, this is (and has long been) a solved problem. Something
Skybuck seems to have trouble understanding. :/

- Oliver

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Oliver Wong" <email***@***.com> wrote in message
news:ErBVe.271041$on1.217553@clgrps13...

> I think Bruce referring to the context-free grammar that describes the
> Java language, not your usage of the English grammar.

Actually, since I was posting from a Delphi ng, I was referring to the
context-free grammar that describes Delphi. Not that it makes any
difference. The fact is that the suggestion that layout impart grammatical
structure is not as simple as resolving matching compound statement
bracketing.

In Pascal a While loop has the grammar

While <expression> Do <statement>

With a layout dependant grammar one would have to define it

While <expression> Do <newline> <indent> <statement>

Seems to me to be an awful lot of extra fluff for little gain.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Bruce Roberts" <email***@***.com> wrote in message
news:9MBVe.2018$email***@***.com...
>
> "Oliver Wong" <email***@***.com> wrote in message
> news:ErBVe.271041$on1.217553@clgrps13...
>
>> I think Bruce referring to the context-free grammar that describes
>> the
>> Java language, not your usage of the English grammar.
>
> Actually, since I was posting from a Delphi ng, I was referring to the
> context-free grammar that describes Delphi.

Yeah, immediately after I had hit "send", I said to myself "Oh wait,
this guy crossposted to the C and Delphi guys too, right? Damn."

> Not that it makes any
> difference. The fact is that the suggestion that layout impart grammatical
> structure is not as simple as resolving matching compound statement
> bracketing.
>
> In Pascal a While loop has the grammar
>
> While <expression> Do <statement>
>
> With a layout dependant grammar one would have to define it
>
> While <expression> Do <newline> <indent> <statement>
>
> Seems to me to be an awful lot of extra fluff for little gain.

Agreed. And if Skybuck is really serious about this idea, (s)he should
probably move the discussion to comp.compilers where it's more appropriate
to discuss language design issues.

- Oliver

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing. Skybuck Flying wrote:

snipped

>
>
>>>Here are the main points:
>>>
>>>Point 1: With the pascal style bracketing/layout it is easier to spot
>>>missing brackets.
>>
>>The choice of '{}', 'begin end', ';', and any other language block
>>scoping identifiers is irrelevant - they all suffer the same problems of
>>people not aligning them.
>
>
> I agree the choice of {} begin/end etc is irrelevant.
>

good...

> The aligning is most relevant.

bad... you are missing the point....

>
> The pascal style aligns it properly vertically like so:
>
> if a<b then
> begin
>
> end;
>
> Some C styles dont align like so:
>
> if (A<b) {
>
> }
>

snipped

As I said earlier - the real problem is the size of the method.
Trying to help enforce or aid alignment is focusing upon fixing the
symptom - not the real problem.

if your method only contains one use of blocks, then it does not matter
what alignment strategy the language or developer uses.

As soon as another block is needed, its a good indicator that the method
is trying to do more than one job.

so...

>>>
>>
>>True they would help with the symptom, but the cure would be not to
>>create such long methods/procedures which cause mismatching blocks in
>>the first place.
>>
>>The smaller a method the easier to read and see, add in code formatters
>>and the problem 'justGoesAway'
>>
>>

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Andrew McDonagh" <email***@***.com> wrote in message
news:dg7j5q$9ta$email***@***.com...
> Skybuck Flying wrote:
>
> snipped
>
> >
> >
> >>>Here are the main points:
> >>>
> >>>Point 1: With the pascal style bracketing/layout it is easier to spot
> >>>missing brackets.
> >>
> >>The choice of '{}', 'begin end', ';', and any other language block
> >>scoping identifiers is irrelevant - they all suffer the same problems of
> >>people not aligning them.
> >
> >
> > I agree the choice of {} begin/end etc is irrelevant.
> >
>
> good...
>
> > The aligning is most relevant.
>
> bad... you are missing the point....

Nope. You think thing splitting code into multiple methods will solve the
problem somehow.

The point that you are missing is that a missing brace can be an accident ;)

>
> >
> > The pascal style aligns it properly vertically like so:
> >
> > if a<b then
> > begin
> >
> > end;
> >
> > Some C styles dont align like so:
> >
> > if (A<b) {
> >
> > }
> >
>
> snipped
>
> As I said earlier - the real problem is the size of the method.

No it's not.

The real problem remains the alignment.

It doesn't matter if the code is split up into multiple methods.

The compiler will still produce a storm of error messages if there is a
missing bracket/brace *anywhere* ;)

> Trying to help enforce or aid alignment is focusing upon fixing the
> symptom - not the real problem.
>
> if your method only contains one use of blocks, then it does not matter
> what alignment strategy the language or developer uses.
>
> As soon as another block is needed, its a good indicator that the method
> is trying to do more than one job.
>
> so...
>
> >>>
> >>
> >>True they would help with the symptom, but the cure would be not to
> >>create such long methods/procedures which cause mismatching blocks in
> >>the first place.
> >>
> >>The smaller a method the easier to read and see, add in code formatters
> >>and the problem 'justGoesAway'

Nope lol. A missing bracket/brace can occur on accident.

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Bruce Roberts" <email***@***.com> wrote in message
news:9MBVe.2018$email***@***.com...
>
> "Oliver Wong" <email***@***.com> wrote in message
> news:ErBVe.271041$on1.217553@clgrps13...
>
> > I think Bruce referring to the context-free grammar that describes
the
> > Java language, not your usage of the English grammar.
>
> Actually, since I was posting from a Delphi ng, I was referring to the
> context-free grammar that describes Delphi. Not that it makes any
> difference. The fact is that the suggestion that layout impart grammatical
> structure is not as simple as resolving matching compound statement
> bracketing.
>
> In Pascal a While loop has the grammar
>
> While <expression> Do <statement>
>
> With a layout dependant grammar one would have to define it
>
> While <expression> Do <newline> <indent> <statement>
>
> Seems to me to be an awful lot of extra fluff for little gain.
>

That's not how you would parse it.

There would be something like an indentation count.

As soon as it increases a new statement block begins, as soon as it
decreases the end of a statement block has been reached.

However I like writing code like this in case there are many parameters:

if function(
a,b,c,d,
e,f,g,h,
i,j,k,l ) then
begin
blabla;
end;

This would be a problem unless parameters have to be passed in a special
way.. for example
by using twice the indentation:

if function(
a,b,c,d,
e,f,g,h,
i,j,k,l ) then
begin
blabla;
end;

Which would look like:

if function(
a,b,c,d,
e,f,g,h,
i,j,k,l ) then
blabla;

:)

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Oliver Wong" <email***@***.com> wrote in message
news:btBVe.271042$on1.60786@clgrps13...
> <email***@***.com> wrote in message
> news:email***@***.com...
> > As a test I loaded this snippet of code into a test.cpp
> > file and sure enough the code folding quickly identified
> > the missing bracket.
>
> In other words, this is (and has long been) a solved problem.
Something
> Skybuck seems to have trouble understanding. :/

No I am not aware of any C IDE which does what you say ?

So from your description it would seem the editor loads a file and
completely folds it ???

Or did you fold it yourself manually which is ofcourse retarded... why do it
manually ?

The point is ease of use... so let the compiler or editor do it for you...
which is what this is all about.

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Oliver Wong" <email***@***.com> wrote in message
news:btBVe.271042$on1.60786@clgrps13...
> <email***@***.com> wrote in message
> news:email***@***.com...
> > As a test I loaded this snippet of code into a test.cpp
> > file and sure enough the code folding quickly identified
> > the missing bracket.
>
> In other words, this is (and has long been) a solved problem.
Something
> Skybuck seems to have trouble understanding. :/

After reading your posts I decided to give it a try in visual studio .net
2003. It simply folds the code no matter if there are any missing braces so
at least in this IDE first of all it doesnt find the missing brace and
second of all I had to do it all manually.

// Test.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
int a,b,c,sdfd,sqfd,dddd,dsdfssdf;
if (a<b)
{
if (sdfd<c)
{
}
if (sqfd<342563)
{
} else
{
}
if (dddd=234)
{
if (dsdfssdf=23)
{
}
}
return 0;
}
Oh look at that it didn't copy paste it right... well blame it on microsoft
outlook... not going to fix it *again* lol :)
Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Oliver Wong" <email***@***.com> wrote in message
news:btBVe.271042$on1.60786@clgrps13...
> <email***@***.com> wrote in message
> news:email***@***.com...
> > As a test I loaded this snippet of code into a test.cpp
> > file and sure enough the code folding quickly identified
> > the missing bracket.
>
> In other words, this is (and has long been) a solved problem.
Something
> Skybuck seems to have trouble understanding. :/

Hmm ok for some reason the previous message did not arrive at my newsreader.

Now I see what he is talking about ;) (Some kind of external editor called
zeus ;))

(Kinda strange that post didnt reach me, anybody have any idea why that is
???)

Ok I installed zeus and paste the code into it, the final result is lol:

You're an idiot.

It doesn't detect jack squat. (It simply folds everything etc lol
hahahahahaha)

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Skybuck Flying" <email***@***.com> wrote in message
news:dg7m5o$3up$email***@***.com...

> That's not how you would parse it.

It doesn't matter how you would parse it. What matters is how the parser
would parse it. You might want to remember that the parser is doing the work
and it is limited to processing a non-ambiguous grammar.

> There would be something like an indentation count.
>
> As soon as it increases a new statement block begins, as soon as it
> decreases the end of a statement block has been reached.

And what exactly defines an indent? <newline> followed by <space> or <tab>?
And what if there is a mixture? And how does the parser know what expansion
setting a user's editor was using for <tab> at the time the source was
created?

> However I like writing code like this in case there are many parameters:
>
> if function(
> a,b,c,d,

> This would be a problem unless parameters have to be passed in a special
> way.. for example
> by using twice the indentation:

In Delphi / Pascal the parser has no problems with this since it is working
from a grammar that distinguishes actual parameters from statements. It
might be a problem in C derivatives since an expression can be a statement.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Bruce Roberts" <email***@***.com> wrote in message
news:aDXVe.2648$email***@***.com...
>
> "Skybuck Flying" <email***@***.com> wrote in message
> news:dg7m5o$3up$email***@***.com...
>
> > That's not how you would parse it.
>
> It doesn't matter how you would parse it. What matters is how the parser
> would parse it. You might want to remember that the parser is doing the
work
> and it is limited to processing a non-ambiguous grammar.
>
> > There would be something like an indentation count.
> >
> > As soon as it increases a new statement block begins, as soon as it
> > decreases the end of a statement block has been reached.
>
> And what exactly defines an indent? <newline> followed by <space> or
<tab>?

Lookup the basic concept of indentation lol, shouldn't be to hard to grasp.

Here is what you do:

Turn the text into lines.

Then process each line.

How hard would that be ?

And ofcourse tab characters would be mandatory.

> And what if there is a mixture? And how does the parser know what
expansion
> setting a user's editor was using for <tab> at the time the source was
> created?

See above.

>
> > However I like writing code like this in case there are many parameters:
> >
> > if function(
> > a,b,c,d,
>
> > This would be a problem unless parameters have to be passed in a special
> > way.. for example
> > by using twice the indentation:
>
> In Delphi / Pascal the parser has no problems with this since it is
working
> from a grammar that distinguishes actual parameters from statements. It
> might be a problem in C derivatives since an expression can be a
statement.

Problem solved above.

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
Skybuck Flying wrote:
> "Bruce Roberts" <email***@***.com> wrote in message
> news:9MBVe.2018$email***@***.com...
[]
> >
> > In Pascal a While loop has the grammar
> >
> > While <expression> Do <statement>
> >
> > With a layout dependant grammar one would have to define it
> >
> > While <expression> Do <newline> <indent> <statement>
> >
> > Seems to me to be an awful lot of extra fluff for little gain.
> >
>
> That's not how you would parse it.
>
> There would be something like an indentation count.
>
> As soon as it increases a new statement block begins, as soon as it
> decreases the end of a statement block has been reached.
>
> However I like writing code like this in case there are many parameters:
>
[]
>
> This would be a problem unless parameters have to be passed in a special
> way.. for example
> by using twice the indentation:
>
> if function(
> a,b,c,d,
> e,f,g,h,
> i,j,k,l ) then
> begin
> blabla;
> end;
>
> Which would look like:
>
> if function(
> a,b,c,d,
> e,f,g,h,
> i,j,k,l ) then
> blabla;
>
> :)
>
> Bye,
> Skybuck.

Care to present a grammer for this "indented block" structure?
Code examples don't count.

I don't think a valid grammer for this style can be written in a
context free grammer. In order to keep tract of the block level the
inner level must somehow know the level of the outer block. IOW the
block level is not context free. Bruce's example doesn't work for
anything beyond while loops with a single simple statement. (no sub
blocks like another WHILE or IF)

So show how serious you are by getting down in the works and get it to
happen.

And I agree with others that this solution is worse than the original
problem of missing a block bracket.
Enjoy,
ed

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Ed Prochak" <email***@***.com> wrote in message
news:email***@***.com...
>
> Skybuck Flying wrote:
> > "Bruce Roberts" <email***@***.com> wrote in message
> > news:9MBVe.2018$email***@***.com...
> []
> > >
> > > In Pascal a While loop has the grammar
> > >
> > > While <expression> Do <statement>
> > >
> > > With a layout dependant grammar one would have to define it
> > >
> > > While <expression> Do <newline> <indent> <statement>
> > >
> > > Seems to me to be an awful lot of extra fluff for little gain.
> > >
> >
> > That's not how you would parse it.
> >
> > There would be something like an indentation count.
> >
> > As soon as it increases a new statement block begins, as soon as it
> > decreases the end of a statement block has been reached.
> >
> > However I like writing code like this in case there are many parameters:
> >
> []
> >
> > This would be a problem unless parameters have to be passed in a special
> > way.. for example
> > by using twice the indentation:
> >
> > if function(
> > a,b,c,d,
> > e,f,g,h,
> > i,j,k,l ) then
> > begin
> > blabla;
> > end;
> >
> > Which would look like:
> >
> > if function(
> > a,b,c,d,
> > e,f,g,h,
> > i,j,k,l ) then
> > blabla;
> >
> > :)
> >
> > Bye,
> > Skybuck.
>
> Care to present a grammer for this "indented block" structure?
> Code examples don't count.
>
> I don't think a valid grammer for this style can be written in a
> context free grammer. In order to keep tract of the block level the

Who cares about context free grammer. I dont care about.

I am all for context.

Runtime information is a sort of context.

> inner level must somehow know the level of the outer block. IOW the
> block level is not context free. Bruce's example doesn't work for
> anything beyond while loops with a single simple statement. (no sub
> blocks like another WHILE or IF)
>
> So show how serious you are by getting down in the works and get it to
> happen.

Lol, Why should I ? Python already does it.

>
> And I agree with others that this solution is worse than the original
> problem of missing a block bracket.

Then I guess you wont be programming in python lol ;)

(where there are no brackets in the first place lol =D)

Bye,
Skybuck.

java-programmer >> Correct Identation/Contex can solve the too many compiler error messages problem when a closing bracket is missing.
"Skybuck Flying" <email***@***.com> wrote in message
news:dgalup$6fj$email***@***.com...
>
> "Ed Prochak" <email***@***.com> wrote in message
> news:email***@***.com...
>> I don't think a valid grammer for this style can be written in a
>> context free grammer. In order to keep tract of the block level the
>
> Who cares about context free grammer. I dont care about.
>
> I am all for context.
>
> Runtime information is a sort of context.

Since you don't seem to know what context-free grammars are, I suggest
you read up on them before further embarassing yourself on topics of
programming language design. You can start with Wikipedia:
http://en.wikipedia.org/wiki/Context-free_grammar As an aside, there's no
shame in not knowing what CFGs are (most programmers don't), but it is very
discouraging that, rather than showing a curiosity or desire to learn more
about them, you dismiss them entirely.

If you are not willing to learn, it will be much more difficult (perhaps
impossible) for you to become as knowlegeable as someone who IS willing to
learn.

>> So show how serious you are by getting down in the works and get it to
>> happen.
>
> Lol, Why should I ? Python already does it.

So in other words, what you want has already been done. It's called
Python, and you're satisfied with Python. So why don't you code in Python,
post on Python related newsgroups, and let the Delphi/C/Java people code in
whatever languages they want?

> Then I guess you wont be programming in python lol ;)
>
> (where there are no brackets in the first place lol =D)

Hilarious.

- Oliver