Why code completion and early error checking are needed

[E. Robert Tisdale]

Re: Why code completion and early error checking are needed

Julie wrote:
[color=blue]
> "E. Robert Tisdale" wrote:
>[color=green]
>>Julie wrote:
>>[color=darkred]
>>>All of what you want and more can be easily provided
>>>if the source is (parsed and) stored in a _database_
>>>as opposed to the ancient file-based structure currently used.
>>>
>>>So, my recommendation is
>>>to look at changing the fundamental storage unit
>>>and the other stuff comes naturally.
>>>Otherwise, it come at a very high price w/file-based code.[/color]
>>
>>No it doesn't.
>>Everything that Steven T. Hatton has proposed and more
>>can be and is being done now with plain text source code files.[/color]
>
> Right! at a very high price, like I said.[/color]

No. It isn't at all difficult or expensive.

[Steven T. Hatton]

Re: [LONG] Re: Why code completion and early error checking are needed

Mark A. Gibbs wrote:
[color=blue]
> there is absolutely no basis in fact for that last statement. none. if
> that wasn't a complete fabrication, then you are sorely confused about
> java, c++ or both.
>
> errr, i meant[/color]

Well, I haven't used it, but I've seen it. AFAIK, the Java compiler is
porting to the major platforms. Just by the number of libraries that
compile with the default distribution, I'm pretty convinced that Java code
compile wll on multiple platforms.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

E. Robert Tisdale wrote:
[color=blue]
> Julie wrote:
>[color=green]
>> "E. Robert Tisdale" wrote:
>>[color=darkred]
>>>Julie wrote:
>>>
>>>>All of what you want and more can be easily provided
>>>>if the source is (parsed and) stored in a _database_
>>>>as opposed to the ancient file-based structure currently used.
>>>>
>>>>So, my recommendation is
>>>>to look at changing the fundamental storage unit
>>>>and the other stuff comes naturally.
>>>>Otherwise , it come at a very high price w/file-based code.
>>>
>>>No it doesn't.
>>>Everything that Steven T. Hatton has proposed and more
>>>can be and is being done now with plain text source code files.[/color]
>>
>> Right! at a very high price, like I said.[/color]
>
> No. It isn't at all difficult or expensive.[/color]

It doesn't take long to build an index of say, Xerces C++'s include files
for KDevelop, using the persistant class store feature. I'll have to take
the middle ground as far as Julie's code in databases ideas go. To my way
of thinking, the file system /is/ a data repository, and the structure is a
resource to leverage in the same sense the facilities of an RDBMS or other
data store can be.

That's why I think the use of filesystem names to correspond with namespace
names is a good idea. If such an arrangement were standardize, it could,
and should be done in terms of namespaces, not explicitly file systems.
I'm going to attempt to establish a system that works like this in the
context of KDevelop, regardless of whether is becomes part of, or
associated with, the Standard.

As for the functionality I've described being available, are you talking
about VC++? I don't believe what I've described is a trivial exercise,
especially with C++. If you know how to accomplish these things easily,
please help out the KDevelop team.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Julie]

Re: Why code completion and early error checking are needed

"Steven T. Hatton" wrote:[color=blue]
> C#? I've looked at it briefly. The monodoc thing that came with it is kind
> of nifty.[/color]

Take a deeper look. It is a high-powered modern language w/ a billion-dollar
backing and a lot of features.

[Julie]

Re: Why code completion and early error checking are needed

"E. Robert Tisdale" wrote:[color=blue]
>
> Julie wrote:
>[color=green]
> > "E. Robert Tisdale" wrote:
> >[color=darkred]
> >>Julie wrote:
> >>
> >>>All of what you want and more can be easily provided
> >>>if the source is (parsed and) stored in a _database_
> >>>as opposed to the ancient file-based structure currently used.
> >>>
> >>>So, my recommendation is
> >>>to look at changing the fundamental storage unit
> >>>and the other stuff comes naturally.
> >>>Otherwise, it come at a very high price w/file-based code.
> >>
> >>No it doesn't.
> >>Everything that Steven T. Hatton has proposed and more
> >>can be and is being done now with plain text source code files.[/color]
> >
> > Right! at a very high price, like I said.[/color]
>
> No. It isn't at all difficult or expensive.[/color]

Well then perhaps you would care to elaborate on why these features have been
poorly implemented, supported, and basically only recent (somewhat spotty)
additions to IDEs -- the modern IDE has been around since the early 90's. I'll
stick w/ my opinion that it is due to the cost to implement and the relative
cost of the feature (i.e. pre-processing/parsing/pre-compiling performance
issues on the user's machine).

Regardless, along w/ the features STH was posting about, (parsed) code in a
database offers a *magnitude* (if not more) capabilities to code development
that could ever be provided by simple text-based files and their supporting
editors. I'm not trying to sell anything here, and I don't purport to be the
originator of the idea, but in the future, code *will* be in a database, pure
and simple. Increasing project complexity mandates it.

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Julie wrote:
[color=blue]
> "Steven T. Hatton" wrote:[color=green]
>> C#? I've looked at it briefly. The monodoc thing that came with it is
>> kind of nifty.[/color]
>
> Take a deeper look. It is a high-powered modern language w/ a
> billion-dollar backing and a lot of features.[/color]

Looking over some of the metrics, I get the sense that C++ has a significant
edge over C# in expressive power per line of code (whatever that's worth)
and raw performance. IMO C++ has two very serious problems, the C
preprocessor, and people who insult others for suggesting the former is a
problem. There are other problems such as exceptions. That can probably
be fixed in a forward-looking sense, but won't solve the problem of
existing C++ code using the flawed exception mechanism.

I came across this comparison between C++ and C#. It seems reasonably
informed and objective from skimming it:

http://www.andymcm.com/csharpfaq.htm#1.5

I believe C++ could, and should look a whole lot different than it currently
does. Removing on character, and the syntax associated with it would be
the best thing that every happened to C++. What C++ could do without is
the '#' symbol. That probably won't happen in the short term. But there
is a good chance there will be means of confining the C preprocessor to the
few places where legacy usage still prevails.

I have an idea for how to accomplish the same thing headers do now with pure
C++ code. There's one significant qualification to that which would
require a change in the Standard to address. On that, more later.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Julie]

Re: Why code completion and early error checking are needed

"Steven T. Hatton" wrote:[color=blue]
>
> Julie wrote:
>[color=green]
> > "Steven T. Hatton" wrote:[color=darkred]
> >> C#? I've looked at it briefly. The monodoc thing that came with it is
> >> kind of nifty.[/color]
> >
> > Take a deeper look. It is a high-powered modern language w/ a
> > billion-dollar backing and a lot of features.[/color]
>
> Looking over some of the metrics, I get the sense that C++ has a significant
> edge over C# in expressive power per line of code (whatever that's worth)
> and raw performance. IMO C++ has two very serious problems, the C
> preprocessor, and people who insult others for suggesting the former is a
> problem. There are other problems such as exceptions. That can probably
> be fixed in a forward-looking sense, but won't solve the problem of
> existing C++ code using the flawed exception mechanism.
>
> I came across this comparison between C++ and C#. It seems reasonably
> informed and objective from skimming it:
> http://www.andymcm.com/csharpfaq.htm#1.5
>
> I believe C++ could, and should look a whole lot different than it currently
> does. Removing on character, and the syntax associated with it would be
> the best thing that every happened to C++. What C++ could do without is
> the '#' symbol. That probably won't happen in the short term. But there
> is a good chance there will be means of confining the C preprocessor to the
> few places where legacy usage still prevails.
>
> I have an idea for how to accomplish the same thing headers do now with pure
> C++ code. There's one significant qualification to that which would
> require a change in the Standard to address. On that, more later.
> --
> STH
> Hatton's Law: "There is only One inviolable Law"
> KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
> Mozilla: http://www.mozilla.org[/color]

Again, with the exception of one of your previous items ("Platform-independent
system facilities") and that C# is compiled to an intermediate code, everything
that you are talking about (GC, no pre-processor, concurrency, etc.) are in
C#.

You should really spend more time examining C# for yourself (i.e. get a
compiler and write some code for a couple of weeks) rather than try and
advocate such changes to C++.

Think about it for a minute, if you added/removed the things that you are
advocating, you would have a completely different language that would be very
close to C#.

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Julie wrote:
[color=blue]
> "Steven T. Hatton" wrote:[color=green]
>>
>> Julie wrote:
>>[color=darkred]
>> > "Steven T. Hatton" wrote:
>> >> C#? I've looked at it briefly. The monodoc thing that came with it
>> >> is kind of nifty.
>> >
>> > Take a deeper look. It is a high-powered modern language w/ a
>> > billion-dollar backing and a lot of features.[/color]
>>
>> Looking over some of the metrics, I get the sense that C++ has a
>> significant edge over C# in expressive power per line of code (whatever
>> that's worth)
>> and raw performance. IMO C++ has two very serious problems, the C
>> preprocessor, and people who insult others for suggesting the former is a
>> problem. There are other problems such as exceptions. That can probably
>> be fixed in a forward-looking sense, but won't solve the problem of
>> existing C++ code using the flawed exception mechanism.
>>
>> I came across this comparison between C++ and C#. It seems reasonably
>> informed and objective from skimming it:
>> http://www.andymcm.com/csharpfaq.htm#1.5
>>
>> I believe C++ could, and should look a whole lot different than it
>> currently
>> does. Removing on character, and the syntax associated with it would be
>> the best thing that every happened to C++. What C++ could do without is
>> the '#' symbol. That probably won't happen in the short term. But there
>> is a good chance there will be means of confining the C preprocessor to
>> the few places where legacy usage still prevails.[/color][/color]
[color=blue]
> Again, with the exception of one of your previous items
> ("Platform-independent system facilities") and that C# is compiled to an
> intermediate code, everything that you are talking about (GC, no
> pre-processor, concurrency, etc.) are in C#.
>
> You should really spend more time examining C# for yourself (i.e. get a
> compiler and write some code for a couple of weeks) rather than try and
> advocate such changes to C++.[/color]

The item you are referring to was not from _my_ whish list. It was a direct
quote - as were the other items in that list - from Bjarne Stroustrup's
list of things he would like to see added to C++.
[color=blue]
> Think about it for a minute, if you added/removed the things that you are
> advocating, you would have a completely different language that would be
> very close to C#.[/color]

You are quite wrong if you stop and think about it. I advocate removing the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.

As for how to fix the naming system in the Standard Library, start by
removing one character and all that goes with it from the language. What
character? '#'.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Julie]

Re: Why code completion and early error checking are needed

"Steven T. Hatton" wrote:[color=blue]
> The item you are referring to was not from _my_ whish list. It was a direct
> quote - as were the other items in that list - from Bjarne Stroustrup's
> list of things he would like to see added to C++.[/color]

Noted. Your request for code completion and early error checking still apply
to C# (VS2003 IDE!) offerings.
[color=blue][color=green]
> > Think about it for a minute, if you added/removed the things that you are
> > advocating, you would have a completely different language that would be
> > very close to C#.[/color]
>
> You are quite wrong if you stop and think about it. I advocate removing the
> '#' symbol and all that goes with it from C++. C# has the same kind of
> preprocessing as C and C++ currently have. Cleaning up the naming system
> in C++ really means improving the way the Standard Library is organized.
> Then formalizing that organizational approach as a foundation for the
> creation of other libraries.[/color]

C# has no preprocessor. The only thing that it has that resembles the
preprocessor is conditional compilation using #if.

Third time: look into C#.

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Julie wrote:
[color=blue]
> "Steven T. Hatton" wrote:[color=green]
>> The item you are referring to was not from _my_ whish list. It was a
>> direct quote - as were the other items in that list - from Bjarne
>> Stroustrup's list of things he would like to see added to C++.[/color]
>
> Noted. Your request for code completion and early error checking still
> apply to C# (VS2003 IDE!) offerings.[/color]

But I've had those features for years with Java. I'm not looking for a
language that has these kind of IDEs. I'm trying to determine why C++
doesn't.

There is a true irony in all this for me. When I started programming in C
and then in C++ (one coures in C++) for my homework assignments back in the
90s, I found the features of the C++ IDE from Borland extremely useful.
Unfortunately I didn't go into programming right away, so I got out of
practice, and didn't continue to develop my skills until I picked up Java.
With Java, all I had at first was TextPad or Nedit. Emacs was completely
arcane to me at the time. It was C++ I looked to with envy because of it's
IDE features. Then JBuiler came along.

[color=blue][color=green][color=darkred]
>> > Think about it for a minute, if you added/removed the things that you
>> > are advocating, you would have a completely different language that
>> > would be very close to C#.[/color]
>>
>> You are quite wrong if you stop and think about it. I advocate removing
>> the
>> '#' symbol and all that goes with it from C++. C# has the same kind of
>> preprocessing as C and C++ currently have. Cleaning up the naming system
>> in C++ really means improving the way the Standard Library is organized.
>> Then formalizing that organizational approach as a foundation for the
>> creation of other libraries.[/color]
>
> C# has no preprocessor. The only thing that it has that resembles the
> preprocessor is conditional compilation using #if.[/color]

Call it what you like, C# has preprocessing directives according to
Microsoft's C# Language Specification.
[color=blue]
> Third time: look into C#.[/color]

Will C# provide me with an IDE for C++ that provides the features I've
described?

To try to explain to others why I believe these features are so important,
here are examples of the kinds of library I am likely to encounter
frequently and likely even together in the same project:

http://artis.imag.fr/Members/Yannick.Legoc/X3D/doc/html/hierarchy.html

http://www.web3d.org/x3d/specifications/ISO-IEC-19777-FCD-X3dLanguageBindings/index.html

http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/hierarchy.html

http://developer.kde.org/documentation/library/cvs-api/

http://xml.apache.org/xerces-c/apiDocs/inherits.html

http://doc.trolltech.com/3.3/classes.html

Note that I did not include the Standard Library, which certainly adds to
the complexity.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Old Wolf]

Re: Why code completion and early error checking are needed

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote:[color=blue]
>
> You are quite wrong if you stop and think about it. I advocate removing the
> '#' symbol and all that goes with it from C++. C# has the same kind of
> preprocessing as C and C++ currently have. Cleaning up the naming system
> in C++ really means improving the way the Standard Library is organized.
> Then formalizing that organizational approach as a foundation for the
> creation of other libraries.[/color]

Removing the mechanism to include one sourcefile within another,
is a serious loss of functionality.
[color=blue]
> As for how to fix the naming system in the Standard Library, start by
> removing one character and all that goes with it from the language. What
> character? '#'.[/color]

As is removing the ability to write platform-specific code for multiple
platforms, and the ability to work around compiler non-standard issues,
and removing the ability to have debug builds (assert, etc.), etc. etc.

Nobody is asking -you- to use '#'. If you don't like it , nobody is forcing
you. Write your code without it, and if you have to read someone
else's code, run it through the preprocessor first.

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Old Wolf wrote:
[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote:[color=green]
>>
>> You are quite wrong if you stop and think about it. I advocate removing
>> the
>> '#' symbol and all that goes with it from C++. C# has the same kind of
>> preprocessing as C and C++ currently have. Cleaning up the naming system
>> in C++ really means improving the way the Standard Library is organized.
>> Then formalizing that organizational approach as a foundation for the
>> creation of other libraries.[/color]
>
> Removing the mechanism to include one sourcefile within another,
> is a serious loss of functionality.[/color]

I took a look at the translation unit resulting from preprocessing a very
simple program. It was then that I realized how bad that system really is.
What most #includes are used for is either to provide access to the
components of the Standard Library, or to include headers in source files.
This is done so that some subset of the available declaration in the
#included Standard Header or header file are available to the source being
compiled. Thes declarations already have a name resolution mechanism
associated with them that is part of C++ proper. If the implementation were
required to locate these declarations on the basis of the C++ name
resolution mechanism, there would be no need for the #include directive. If
this name resolution were such that it mapped directly to object files,
code would, in many cases, compile orders of magnitude faster than it
currently does.

What is really needed is a mechanism to map between fully qualified
identifiers and resources external to the file where they are used, but not
declared.
[color=blue][color=green]
>> As for how to fix the naming system in the Standard Library, start by
>> removing one character and all that goes with it from the language. What
>> character? '#'.[/color]
>
> As is removing the ability to write platform-specific code for multiple
> platforms, and the ability to work around compiler non-standard issues,
> and removing the ability to have debug builds (assert, etc.), etc. etc.[/color]

It doesn't prevent code from porting. There is much code written in
languages that don't have the kind of preprocessor C and C++ have and ports
from one system to another. The same goes for debug builds. It only means
the currently used mechanisms would not be available. I don't know if it's
a formal part of the language, but Java used to honor the #include
directive, and may still. No one used it.

Conditional compilation could be handled by the compiler by not producing
object code for unreachable statements, and using constance which are made
available throughout the program using the C++ name resolution mechanism.
[color=blue]
> Nobody is asking -you- to use '#'. If you don't like it , nobody is
> forcing you. Write your code without it, and if you have to read someone
> else's code, run it through the preprocessor first.[/color]

Thanks, but I've seen the results of the latter. Rather disturbing to say
the least. Proting code should be done by isolating the system specific
variants in a separate part of the program from the core application. I'm
certain there are other, better mechanisms possible for accomplishing what
the preprocessor currently does. Even if there is an argument for having
preprocessor directives in that confined part of the program, they should
not be permitted beyond those confines. The preprocessor undermines the
inherent grammar of C++ and limits its usefulness and power without adding
anything that couldn't be provided by a better mechanism.

I'll have to investigate before I say much more on this, but there is a
whole lot of java code compiling on my Linux box without having
preprocessor directives.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Severin Ecker]

Re: Why code completion and early error checking are needed

> I'll have to investigate before I say much more on this, but there is a[color=blue]
> whole lot of java code compiling on my Linux box without having
> preprocessor directives.[/color]

well java simply compiles into bytecode, which is run within the java-vm, and this code is actually the same on _all_ platforms.
there's a huge difference between that, and native code, which actually is different on different platforms (at least when
system-calls and memory-allocations from the system are invoked).
so, strictly spoken, no java-program is platform independent, because it's using the javavm, which in fact always provides the same
api and the same bytecode interpretation on every platform.

so i don't think that java's portability can be used as argument in this.. hmm.. discussion.

as for the preprocessor,.. i do enjoy and use the possibility of having different builds with only setting a preprocessorfla g, or
something like that.

regards,
sev

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Severin Ecker wrote:
[color=blue][color=green]
>> I'll have to investigate before I say much more on this, but there is a
>> whole lot of java code compiling on my Linux box without having
>> preprocessor directives.[/color]
>
> well java simply compiles into bytecode, which is run within the java-vm,
> and this code is actually the same on _all_ platforms. there's a huge
> difference between that, and native code, which actually is different on
> different platforms (at least when system-calls and memory-allocations
> from the system are invoked). so, strictly spoken, no java-program is
> platform independent, because it's using the javavm, which in fact always
> provides the same api and the same bytecode interpretation on every
> platform.
>
> so i don't think that java's portability can be used as argument in this..
> hmm.. discussion.
>
> as for the preprocessor,.. i do enjoy and use the possibility of having
> different builds with only setting a preprocessorfla g, or something like
> that.
>
> regards,
> sev[/color]

I wrote /compile/ not /byte compile/.

This is from the history of my bash shell:

emacs -batch -f batch-byte-compile psgml/*.el 2>&1

http://www.xemacs.org/Documentation/21.5/html/internals_3.html#SEC8

"The new Java language holds promise as a better general-purpose development
language than C. Java has many features in common with Lisp that are not
shared by C (this is not a coincidence, since Java was designed by James
Gosling, a former Lisp hacker)."


--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Severin Ecker]

Re: [OT] Why code completion and early error checking are needed

> I wrote /compile/ not /byte compile/.

i'm not quite sure what you mean by "byte compile". compilation is simply the translation from source to destination language.
did you generate native code?
this does not prove my argument senseless. i'm obviously not the java-guru (and i don't really know what features, classes,.. the
java-standard supports), but there will be a great loss of functionality if you want to use the same java program on a windowing
system and on a console system (there you go,.. implementing 2 versions, only, of course if the java compiler isn't smart enough to
change all the windowing code to console code).

as i said before,. i don't think portability really is an argument here.
and i think it would be better to discuss missing features and not "java has this and that, why doesn't c++"
[color=blue]
> "The new Java language holds promise as a better general-purpose development
> language than C. Java has many features in common with Lisp that are not
> shared by C (this is not a coincidence, since Java was designed by James
> Gosling, a former Lisp hacker)."[/color]

so what? should everybody just drop C and start low-level programming in java?
and as for the quote anyway,.. i thought you wanted to change C++ not C?
this whole thread really smells trolling....

regards,
sev