Recommend a good free text editor?

[Daniele Futtorovic]

I disagree with this. In English, capitalization of a word can change
depending on its context, without changing the meaning. I'll
capitalize a word in a title that I would not capitalize in the
middle of a normal sentence. I don't think that makes English writers
sloppy - it just means capitalization does not have much to do with
word meaning in that language.

Well, my point was about programming languages, i.e. totally different
things than English. Consequently, what holds true for the former need
not be applicable to the latter, and what's a contradiction to the
latter needs not be a contradiction to the former.

I don't have a strong view about which is better for programming
languages, case sensitive or case insensitive. Either works well.

I'd agree either work equally well as far as the programming language is
concerned. I'd disagree either work equally well as far as the
/programmer/ is concerned.

What matters is for the programmer to match thinking and attitude to
the language - and that applies to a lot more than case sensitivity.

Why, certainly. Actually, one /automatically/ tends match their thinking
and attitude to the tool they use for (personal) productivity all day
long (IOW as long as they don't switch languages really often), since
that's a premice for maximizing effectiveness. This phenomenon is a
crucial part of my argumentation. I argue that there are languages which
are /better/ to match with your thinking than others.

If you are programming in a case sensitive language, it is important
to really see "String" and "string" as different words, even though
they would be the same word in English or in any case-insensitive
programming language. Equally, if you are programming in a
case-insensitive language, you need to see them as the same word.

Again, that's my point. If "String" and "string" are the same thing, you
have to do additional checks while reading. Think collated comparisions
versus plain ones. If you can be sure that a sequence of characters
you're looking for (say for instance you're tracking a variable's use in
an algorithm) will appear, if relevant, in exactly the same form you saw
it first in, then it's much less of a mental strain to find it.
Remember the topic which came up a while ago, about humans being able to
read a (-n English) sentence where the words' letters were in a slightly
different order? The explanation is that in order to read fast, one does
not look at the individual letters, but at the word as a whole. Take the
example I gave above again. You're looking for a variable. If the
language is case-sensitive, you can rely on the word's /shape/ and do
not have to look at the individual characters. Thus, you avoid a
sementical translation of the letter's graphical shape to the abstract
"letter". Easier. You can feel it.
Actually, the biggest point in my favor is brought by the makers of the
standard editor for the language the OP spoke about: Visual Basic/Studio
(I can't seem to get its name straight). By default, that editor will
change any word you type to match a certain case: capitalized for
keywords (IIRC) or the exact spelling of whatever variable matches the
word just typed when compared toLowerCase(). Now, guess why it does
that: because otherwise it's a pain in the ass (the size of moderately
large pumpkin) to read.
If they agree it's a necessity for the result, they should agree it had
even better be built into the language in the first place.

On the other hand, this really is the pathetic ranting of a pricky
old geezeress? geezerette? she-geezer? (What is the female of
"geezer" anyway?).

Patricia.

IMO, the most important trait of a programmer is mental flexibility,
including the ability to adjust thinking to fit the problem and
programming language. It is important to be disciplined about the
things that matter in the current context, and a waste of time and
effort to be unnecessarily precise about things that don't matter.

I don't disagree with that. However, note how, as an allegory,
gymnastics are seldom performed on quicksand. For you need firm ground
to be flexible.

df.

 

[Patricia Shanahan]

Daniele Futtorovic wrote:
....

Actually, the biggest point in my favor is brought by the makers of the
standard editor for the language the OP spoke about: Visual Basic/Studio
(I can't seem to get its name straight). By default, that editor will
change any word you type to match a certain case: capitalized for
keywords (IIRC) or the exact spelling of whatever variable matches the
word just typed when compared toLowerCase(). Now, guess why it does
that: because otherwise it's a pain in the ass (the size of moderately
large pumpkin) to read.
If they agree it's a necessity for the result, they should agree it had
even better be built into the language in the first place.

Indentation is not significant in Java, yet many programmers, myself
included, routinely use editors that ensure indentation consistent with
statement nesting. As indicated by protests in this newsgroup, some
programmers find unindented Java code somewhere between painful and
impossible to read. I tend not to bother to protest badly indented code
- if I care at all about the code, I'm too busy loading it into Eclipse
and running Source - Format on it.

Do you think that makes Java inferior to languages in which statement
nesting is controlled by indentation?

Patricia

 

[Lasse Reichstein Nielsen]

Do you think that makes Java inferior to languages in which statement
nesting is controlled by indentation?

I still can't decide on that one.

On one hand, having both indentation and block syntax ({...}) that
represent the same thing, is redundant. Being redundant, it's an
error waiting to happen when the two get out of sync.
Humans rely on indentation, and only use the block syntax for
verification. The compiler only understands the syntax.

if (foo == bar)
foo = 42;
bar = 43;

System.out.println(foo + ":" + bar);

It has happened to me at least once.

So yes, I do believe that a language where something as important
as block structure is only represented once is better at the DRY
principle, and is therefore superior.


On the other hand, whitespace having meaning really rubs me the
wrong way. Perhaps because I've been bitten by tab/space confusion,
and even \u0020 vs \u00a0.

/L

 

[Stefan Ram]

Humans rely on indentation

Then I am not human.

On the other hand, whitespace having meaning really rubs me the
wrong way. Perhaps because I've been bitten by tab/space confusion,
and even \u0020 vs \u00a0.

http://www.research.att.com/~bs/whitespace98.pdf

 

[Arne Vajhøj]

On the other hand, whitespace having meaning really rubs me the
wrong way. Perhaps because I've been bitten by tab/space confusion,
and even \u0020 vs \u00a0.

I have used a compiler (Fortran) that gave a fatal error
due to a blank line at the end.

Not so easy to spot.

Arne

 

[Arne Vajhøj]

However, the text editor it comes with is buggy (for example, doesn't
colorize syntax until file is saved) and doesn't really do what I
need, and I'm wondering if anyone knows of any java-aware freeware
editors that do what i need:

Several has suggested an IDE. And for you usage I think an IDE
is indeed the best choice.

Personally I prefer Eclipse. But that does not imply that you will
do the same.

If you insist on a general purpose editor with Java support, then I
will recommend JEdit. I use it for all my non-IDE editing and really
like it.

For example, I had compile errors a few times because I failed to
capitalize the word "String" and simliarly I named a method
"showAttributes" but when I called it in an application I accidentally
capitalized ShowAttributes and it did not recognize any time I used it
like that, until I changed them to lowercase the way it is written in
the method declaration.

The Java language is case sensitive.

If you use Eclipse, then in case of errors due to wrong capitalization,
then it will often be capable of suggesting a proper change to you.

Arne

 

[Wojtek]

Lasse Reichstein Nielsen wrote :

I still can't decide on that one.

On one hand, having both indentation and block syntax ({...}) that
represent the same thing, is redundant. Being redundant, it's an
error waiting to happen when the two get out of sync.
Humans rely on indentation, and only use the block syntax for
verification. The compiler only understands the syntax.

if (foo == bar)
foo = 42;
bar = 43;

System.out.println(foo + ":" + bar);

Ok, but that is why there are auto-formaters. For instance Ecplise will
format on save. So you press CTRL-S, the file is formatted and your
source is saved.

So the above would now look like:

if (foo == bar)
foo = 42;
bar = 43;

System.out.println(foo + ":" + bar);

 

[Lew]

Lasse Reichstein Nielsen wrote :

Ok, but that is why there are auto-formaters. For instance Ecplise will
format on save. So you press CTRL-S, the file is formatted and your
source is saved.

So the above would now look like:

if (foo == bar)
foo = 42;
bar = 43;

System.out.println(foo + ":" + bar);

There are two domains of discourse here when we speak of "meaning" in source
code. One is meaning for programmers working on that source. The other is
meaning for the machine that ultimately runs the program embodied in the source.

I shall call the first the "meaning" of the program, and the second the
"semantics" of the program. Just for discussion purposes - I doubt I'm using
these terms in any endorsed way.

Languages that enforce semantics via indentation presumably intend to enforce
consistency between the meaning and the semantics. Unfortunately in practice
over the years that style has turned out to be somewhat fragile. Overall,
most programmers find semantically-neutral indentation to be easier to use to
convey meaning. In other words, being loose about the semantics allows the
developer to be much more accurate conveying the meaning.

It does introduce that risk of having the meaning and semantics contradict
each other by failing to indent properly. This seems to be a concomitant cost
to gaining the power to control how the meaning is documented. It just
slightly adds to the burden of the source maintainer to be careful, thorough
and smart.

Since they're doing that anyway, it shouldn't be too egregious to match
meaning with indentation while they're about it.

 

[Wojtek]

Lew wrote :

Since they're doing that anyway, it shouldn't be too egregious to match
meaning with indentation while they're about it.

I sure hope not. Complier enforced white-space (other than as a
delimiter) is a Bad Thing.

I remember the first time I coded in COBOL. It took me several tries to
get a clean compile, and I was copying from an instructor supplied
sample. And it was ALL column positioning.

And it is the same with RPG, another column dependant language.

Program indentation problems with free form languages is all the
developers fault. And at that Ecplise flags empty bodies, so something
like

for ( int c = 0; c < max; c++);

would be caught.