"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c0bspq$313t$1@digitaldaemon.com...
> This would not help you, when you want to type `[ 1.3 ]', but your keyboard spits out a `[ 1..3 ]' because of a temporary malfunction of the `.'-key.

I've had keyboards that started doing the stuttering after years of use. Stuttering makes them unusable for anything, not just D. They go right in the trash, and I pull out a new one (they're $9.95 each). In fact, I keep a couple of new spares in the basement for just such an emergency <g>.

Walter wrote:

[...]
> I haven't used color syntax highlighting editors myself, but such should make such errors stand out like a neon sign, and should help a lot in eliminating such coding errors from the start.

The problem is, that the so called syntax highlighters, as far as i have seen them, are only regular expression highlighters. So they can make standout `0..1' to something like `0##1', because the lack of a space to the left or right of `..'. But there is no regular expression to decide whether for example `[ 0.1 ]' is legal. So: if one makes it always standing out like `[ 0#1 ]' one will get false alarms and this will leed to ignoring them

hint(chernobyl):
| Defects of the system was that the designers did not foresee the awkward
| and silly actions by the operators

or it is like having no highlight at all.

So long.

> > This would not help you, when you want to type `[ 1.3 ]', but your keyboard spits out a `[ 1..3 ]' because of a temporary malfunction of the `.'-key.
>
> I've had keyboards that started doing the stuttering after years of use. Stuttering makes them unusable for anything, not just D. They go right in the trash, and I pull out a new one (they're $9.95 each). In fact, I keep a couple of new spares in the basement for just such an emergency <g>.

Ok, we can fight ".." problem with syntax highlighting and spare keyboard. But it's not the only critical security hole in the D language specifications. While we at it, let's address another serious problem.

In many fonts the glyphs for capital "O" and zero "0" looks exactly the same.
The glyphs for capital "I", small "l" and number "1" quite often looks just too damn similar.
And the worst part - if those questionable characters are in the identifier's name,
even syntax highlighting is powerless to warn you about imminent disaster.
One possible solution is to disallow capital "O", "I" and small "l" in the source code.
(zero ("0") and one ("1") cannot be removed easily since they are necessary for numeric literals)
This would make programmer's life a lot safer, but one would have to rename "Object".
Perhaps, Qbject? Than we will have QQ language.
More reasonable solution is to disallow overloaded identifiers different only by the questionable characters.
The conflicts should be resolved by explicitly qualifying scope,
like stream.In(...) and math.ln(...)

Now, if the font size is small enough, () and {}may look the same...

P.S
Hell, I've just tried 4pt size font. I could not distinguish the characters at all!
Perhaps, we should switch to writing programs in Morse code.
···· ·- ·--· ·--· -·--   -·-· --- -·· ·· --- --· ··--··

Serge K wrote:
> P.S
> Hell, I've just tried 4pt size font. I could not distinguish the characters at all!
> Perhaps, we should switch to writing programs in Morse code.
> ···· ·- ·--· ·--· -·--   -·-· --- -·· ·· --- --· ··--··
> 
··· --- ···

-- 
Justin
http://jcc_7.tripod.com/d/

On Thu, 12 Feb 2004 21:13:49 -0800 (02/13/04 16:13:49)
, Serge K <skarebo@programmer.net> wrote:

>> > This would not help you, when you want to type `[ 1.3 ]', but your
>> > keyboard spits out a `[ 1..3 ]' because of a temporary malfunction of 
>> the
>> > `.'-key.
>>
>> I've had keyboards that started doing the stuttering after years of use.
>> Stuttering makes them unusable for anything, not just D. They go right in
>> the trash, and I pull out a new one (they're $9.95 each). In fact, I keep a
>> couple of new spares in the basement for just such an emergency <g>.
>
> Ok, we can fight ".." problem with syntax highlighting and spare keyboard.
> But it's not the only critical security hole in the D language specifications.
> While we at it, let's address another serious problem.
>
> In many fonts the glyphs for capital "O" and zero "0" looks exactly the same.
> The glyphs for capital "I", small "l" and number "1" quite often looks just too damn similar.
> And the worst part - if those questionable characters are in the identifier's name,
> even syntax highlighting is powerless to warn you about imminent disaster.
> One possible solution is to disallow capital "O", "I" and small "l" in the source code.
> (zero ("0") and one ("1") cannot be removed easily since they are necessary for numeric literals)
> This would make programmer's life a lot safer, but one would have to rename "Object".
> Perhaps, Qbject? Than we will have QQ language.
> More reasonable solution is to disallow overloaded identifiers different only by the questionable characters.
> The conflicts should be resolved by explicitly qualifying scope,
> like stream.In(...) and math.ln(...)
>
> Now, if the font size is small enough, () and {}may look the same...
>
> P.S
> Hell, I've just tried 4pt size font. I could not distinguish the characters at all!
> Perhaps, we should switch to writing programs in Morse code.
> ···· ·- ·--· ·--· -·--   -·-· --- -·· ·· --- --· ··--··
>
>

April comes early this year ;-)


-- 
Derek

On Thu, 12 Feb 2004 21:13:49 -0800, Serge K wrote:

[...]
> Ok, we can fight ".." problem with syntax highlighting and spare keyboard.

ButUseTheRlghT0ne: hTTp://wWw.kaUfmann.NO/roLanD/DVorak/inDex.html

[...]
> The glyphs for capital "I", small "l" and number "1" quite often looks just too damn similar.

ThlSIstEchn1qUe2lfR0M; hTtP://minDprOD.cOm/uNmAINnAmInG.HTml

> P.S
[...]
> ···· ·- ·--· ·--· -·--   -·-· --- -·· ·· --- --· ··--··
anDa1waysUSEix1l=  HTtp://sv-fOrtYtwO.cOm/hhgTTg42.html

S010ng

syntax highlighting is like an enhancement over the actual displayed text. you see it while you type, and realise if it's the right text. if not, you correct it. with syntax highlighting, you directly see if the construct you've written gets interpreted as the statement you wanted, a.k.a. if its 1..2 or 1.2, because you expect it to be eighter yellow, or yellow-red-yellow, just as you expect to see the actual typing.

it's just enhanced visual control if what you write is what you thought.

thats all.

but thats much.

ever tried to code 100% blindly? i've had to do this once (just as a test:D). it was rather irritating to not see what you type.

i don't get what you have against syntax highlighting. i simply don't get it.

you should turn off your screen while you code. you have syntax-visualising on. thats evil. you don't need that.

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:c0hk0m$9af$1@digitaldaemon.com...
> Walter wrote:
>
> [...]
> > I haven't used color syntax highlighting editors myself, but such should make such errors stand out like a neon sign, and should help a lot in eliminating such coding errors from the start.
>
> The problem is, that the so called syntax highlighters, as far as i have seen them, are only regular expression highlighters. So they can make standout `0..1' to something like `0##1', because the lack of a space to the left or right of `..'. But there is no regular expression to decide whether for example `[ 0.1 ]' is legal. So: if one makes it always standing out like `[ 0#1 ]' one will get false alarms and this will leed to ignoring them
>
> hint(chernobyl):
> | Defects of the system was that the designers did not foresee the awkward
> | and silly actions by the operators
>
> or it is like having no highlight at all.
>
> So long.

Manfred Nowak wrote:
> Richard Krehbiel wrote:
> 
> [...]
> 
>>any kind of language
> 
> [...]
> 
> That is easy. For example the languages recognized by the following
> regular expressions:
> 
> 1)  ^$
> 2)  ^0|1$
> 3)  ^1*$
> 
> Make a system fool proof, and only fools will use it.
> 
> Have you obfuscated your own request? <g>

So is describing a language that is resistant to obfuscation, you use *regular* *expressions*?  I think your evidence supports my thesis.  :-)

"davepermen" wrote:

[...]
> i don't get what you have against syntax highlighting. i simply don't get it.
[...]

I dont have anything against highlighting. I use it myself, If you want to see how, then have a look at the attached zipped html.

However I do not type and watch as you do. And you have not proven, that everybody except me follows your style of typing.

I gave the example of a data typist, who transforms data written on paper directly into code. He does not visually control what he types, thereby reaching for example a speed of 400 chars per minute. You have not argumented against that.

I gave the example of randomly generated code, changed by one char at a critical place, which again is randomly choosen, and the unability of highlighting to visualize this change without having the original. You argumented, that you do not touch code, whos purpose is not known to you. I now hold against your argument, that for every maintenance programmer or successor in the job the already generated code is in the beginning nothing more than a bunch of random data, despite of the fact, that the purpose of the code has been made known to him.

I extend my examples to the well known assignment statement in an if-clause `if(a=b)'. Hard to find it, once it is there, somebody said in another thread. dmd generates an error for it: `does not give a boolean'. Why this error message? According to your wording such an error message is needless, because highlighting assures that the code is as intended. So why an error message instead of an implicit cast to boolean?

I drove this example together with your opinion of the power of higlighting to the limits: cancel all error messages in the compiler, that can be avoided by the suggested power of highlighting. You did not argument against this, but turned personal.

Several times in my job I had debates with colleagues that did not lead to a final result. However, because of working for a common goal, i.e. being somewhere in the same hierarchy, we always were able to make up a document stating the different positions, agree about a regulation of the conflict, usually maintaining the status quo, agree about a time span for which this regulation should hold and assign the person/role responsible for the resumption of the whole matter.

In the economics it is well known, why companies usual have hierarchical skeletons: partnerships are inefficient when trying to maximize the quotient of input, usual earned money, versus output, usually the work done.

Do try to not fall into this hole.

So long.

before replying to all parts.. uh, what the *** is that code? is that d? os the html ***ed? somehow i can't see anything except tons of garbage-tokens..

hm....

irritated. then again, i'm very tired:D

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:Xns948EA270627ECsvv1999hotmailcom@127.0.0.1...
> "davepermen" wrote:
>
> [...]
> > i don't get what you have against syntax highlighting. i simply don't get it.
> [...]
>
> I dont have anything against highlighting. I use it myself, If you want to see how, then have a look at the attached zipped html.
>
> However I do not type and watch as you do. And you have not proven, that everybody except me follows your style of typing.
>
> I gave the example of a data typist, who transforms data written on paper directly into code. He does not visually control what he types, thereby reaching for example a speed of 400 chars per minute. You have not argumented against that.
>
> I gave the example of randomly generated code, changed by one char at a critical place, which again is randomly choosen, and the unability of highlighting to visualize this change without having the original. You argumented, that you do not touch code, whos purpose is not known to you.
I
> now hold against your argument, that for every maintenance programmer or successor in the job the already generated code is in the beginning
nothing
> more than a bunch of random data, despite of the fact, that the purpose of the code has been made known to him.
>
> I extend my examples to the well known assignment statement in an
if-clause
> `if(a=b)'. Hard to find it, once it is there, somebody said in another thread. dmd generates an error for it: `does not give a boolean'. Why this error message? According to your wording such an error message is
needless,
> because highlighting assures that the code is as intended. So why an error message instead of an implicit cast to boolean?
>
> I drove this example together with your opinion of the power of
higlighting
> to the limits: cancel all error messages in the compiler, that can be avoided by the suggested power of highlighting. You did not argument against this, but turned personal.
>
> Several times in my job I had debates with colleagues that did not lead to a final result. However, because of working for a common goal, i.e. being somewhere in the same hierarchy, we always were able to make up a document stating the different positions, agree about a regulation of the conflict, usually maintaining the status quo, agree about a time span for which this regulation should hold and assign the person/role responsible for the resumption of the whole matter.
>
> In the economics it is well known, why companies usual have hierarchical skeletons: partnerships are inefficient when trying to maximize the quotient of input, usual earned money, versus output, usually the work done.
>
> Do try to not fall into this hole.
>
> So long.
>
>