uh, yeah, show obfuscated examples to show how stupid the language is.

thats what obfuscation is good for. showing that it doesn't matehr what, where, how, and how ever the designers tried to prevent it. you can ALWAYS write unreadable, ugly code.

you're babling.

though its fun babling.

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:c0c1t1$7v5$1@digitaldaemon.com...
> J C Calvarese wrote:
>
> > Seriously...
> [...]
> > (If a person only wants to complain, then they can just complain.)
>
> http://remus.rutgers.edu/~rhoads/Obfuscated_C/bright
>
> How quick can you tell the public, what the meaning of the comments in the example referenced above is?
>
> So long.

if its a real that is used, then its dark yellow, both the numbers, and the . in between.

if its a slice, its two dark yellow numbers, and two red dots in between.

if i don't know the purpose of the code, then i should not touch it. but even so. i can quicky seen what is written. it can still take ages to detect if it's right, or wrong, what is written.

but that can be the case everytime.

fact is, i have no problems determining if its opSlice or opIndex(real).

determining if something is a bug, that is another story. most the time, in this situation, it will yield a bug, because it simply doesn't work (opIndex doesn't take a real, returnvalues are different (array against one value)), but of course, it can be made up to show an example where it does work.

but you're mixing two points:
a) its not visible to determine the difference
b) thus its very difficult to find the bug

a) is not true, i can see it clearly. and if you can't set your dev-env to
make it visible, then you have a serious problem.
b) most the time it isn't difficult to find that bug. but the difficulty of
finding a bug is not depending on the fact of a, the readability. it's only
based on managability.

and now, have fun searching even more such stupid bugs. or get some real stuff done, and show us examples on what bugs happen, and you have difficulties to find. trying to solve those directly by the language is more useful.

oh, and, enable ****ing syntax highlighting.

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:c0br6p$2ud9$1@digitaldaemon.com...
> davepermen wrote:
>
> > use ****ing syntax highlighting!! :D
> > yes, i can see it definitely
>
> I do not believe you. Do you know of a system or site where the time between download and upload of files is recorded?
>
> If such system or site exist I propose that you are not able to do the
> following:
> 1. you download a file that I would have produced in the following way:
> 1.a. defining a class `C' containing something like opSlice(int, int) and
>      opIndex(real)
> 1.b. declaring a variable `c' of class `C' in the `main' function
> 1.c. randomly generating 2 million lines of code containing calls of the
>      form c[int..int] and c[real] in the body of `main'
> 1.d. changing one call c[int..int] to c[real] _or_ one call c[real] to
>      c[int..int] by inserting or deleting a `.'
> 2. you find in appropriate time the error, i.e. the line which I have
>    changed in step 1.d., and correct it by either deleting or inserting a
>    `.'
> 3. you proove the appropriate time of finding the error by uploading the
>    corrected file
> 4. the file you uploaded and my unmodified randomly generated file are
>    identical
>
> So long.
>
>

Manfred Nowak wrote:
> J C Calvarese wrote:
[...]
> http://remus.rutgers.edu/~rhoads/Obfuscated_C/bright
> 
> How quick can you tell the public, what the meaning of the comments in
> the example referenced above is?

Come on. He didn't even remove the whitespace. Obviously, it's a hex editor. Walter has promised that code like this will be impossible in D due to the lack of a preprocessor.

By the way, which year did you win?

> 
> So long.

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

davepermen wrote:

> if its a real that is used, then its dark yellow, both the numbers, and the
> . in between.
> if its a slice, its two dark yellow numbers, and two red dots in between.

You already told about your syntax highlighter. I know that you can
distinguish between `.', `..' and `,'. But that does only help you out if
you already know, that there is an error. Why do you think dmd is still
buggy in version 79? Do you think, that Walter does not use a syntax
highlighter?

> if i don't know the purpose of the code, then i should not touch it. but even so. i can quicky seen what is written. it can still take ages to detect if it's right, or wrong, what is written.

Do I remember the GPL correctly, that it states that the sources realeased under it do not fit for any particular use? Consequently you do not touch any GPL-ed software?

[...]
> or get some real stuff done

I see that you are a man of action. But men of action seldomly decide what
tools to take, when organizing a team of lets assume 2000 IT
professionals. And the management of such a team must be prepared
for the simple question of its board of directors or supervisory
board "why did you choose this tool" in case something went seriously
wrong. A manager might very well get as red as a beetroot if it turns
out, that the QA team gave out a warning in time. Last time I did that,
Smalltalk was cancelled.

> and show us examples on what bugs happen, and you have difficulties to find.

Are you shure, that you got my messages right? The bugs that are detected by the coder alone are of no problem. Bugs that pass coding, walkthroughs, code reviews, code integration and whatever else is used to assure quality and finally reach the released product are the problem.

In my simple example changing the declaration of `foo' to `char[4] foo= "1221";' could render the bug undetected, because then the output `22' would be identical to the expected output.

Do you really believe, that the russian aerospace agency did not make any QA for its mars probe that finally crashed in 1971?

So long.

> You already told about your syntax highlighter. I know that you can distinguish between `.', `..' and `,'. But that does only help you out if you already know, that there is an error. Why do you think dmd is still buggy in version 79? Do you think, that Walter does not use a syntax highlighter?

all i want to state is your problem is a logic error. and those are the errors that can, from time to time, let mars-probes crash. if it's NOT a logic error, but a typing error, i immediately spot the error while typing. that is what the syntax highlighting is made for.

i will never have an error like [1.2] instead of [1..2] or vice versa as a TYPO. and thats what you want to warn that could happen to come, and pass because it can get compiled.

this, in a good dev-env, will never be a typo. it can still be a logic error, but logic errors can be in every statement.

a language cannot prevent all sort of typos. it can prevent most. good dev-tools can help for the rest.

> Do I remember the GPL correctly, that it states that the sources realeased under it do not fit for any particular use? Consequently you do not touch any GPL-ed software?
in general, no. most the time i just use it as a lib, with headers (in c++),
or as converted lib, with rewritten d library "headers" (in D).

i normally don't work with the actual code of such libs, no. i prefer to bugreport and let the coders that work with the lib daily do the job. they know it bether.

> I see that you are a man of action. But men of action seldomly decide what
> tools to take, when organizing a team of lets assume 2000 IT
> professionals. And the management of such a team must be prepared
> for the simple question of its board of directors or supervisory
> board "why did you choose this tool" in case something went seriously
> wrong. A manager might very well get as red as a beetroot if it turns
> out, that the QA team gave out a warning in time. Last time I did that,
> Smalltalk was cancelled.
uhm.. i'm talking about a ****ing texteditor with colours instead of notepad. it's their job. and the management doesn't ever need to bother.

i don't know of any ide that does not have syntax highlighting. the only
case is, if you don't have an ide, and have to use something like notepad.
and there, replacing it with a notepad that has colours is something that
doesn't mean a lot of change, can be made for free, the management can sure
be aranged to support it (just tell it about the big COBOL issue and how
syntax highlighting could possibly have prevented it and they will love
you).
and the ones that use it in your company will hell-fast adopt it. they have
now the choise to go to Start->Programs->Notepad, or
Start->Programs->TextPad, to do the same, in exactly the same way. one time
with, one time without, colours.

> Are you shure, that you got my messages right? The bugs that are detected by the coder alone are of no problem. Bugs that pass coding, walkthroughs, code reviews, code integration and whatever else is used to assure quality and finally reach the released product are the problem.
you always show us possible typos that can pass and result in big bugs. i always can show you that those things don't happen as typos in a normal dev-environment. if it's wrong, then it's a logic error, a.k.a. a REAL error. as such, nothing can prevent it from slipping trough. it can result in no problem, in strange crashes, in wrong data, etc. but thats not a problem of this certain case, but programming in general.

> Do you really believe, that the russian aerospace agency did not make any QA for its mars probe that finally crashed in 1971?
do you really believe we live in 1971?

show me one place where we use such primitive tools to work with. i know no
place where you can't use a windows or linux or mac or what ever gui to work
in and develop, and then up/download the compiled code to your prefered
device.
and for all those platforms with their guis, there do exist (thanks,
scintilla:D), syntax hightighting notepads.

this is a standard today. you may or may not adopt it. fact is, most people use msvc, and they will never step back to non-coloured coding.

Manfred Nowak wrote:
> davepermen wrote:
> 
> 
>>if its a real that is used, then its dark yellow, both the numbers, and the
>>. in between.
>>if its a slice, its two dark yellow numbers, and two red dots in between.
> 
> 
> You already told about your syntax highlighter. I know that you can
> distinguish between `.', `..' and `,'. But that does only help you out if
> you already know, that there is an error. Why do you think dmd is still
> buggy in version 79? Do you think, that Walter does not use a syntax
> highlighter?
Um, I think it's because walter has more difficult issues to deal with than . versus ..

Sam McCall wrote:

> Um, I think it's because walter has more difficult issues to deal with than . versus ..

I see. Would you have had a look at his code, then you would have noticed, that he codes as if D has already more than the proposed change incorporated: always two spaces around `..' while one space would suffice. Whereas in comments he follows the natural way of specifying slices: mostly without surrounding spaces.

And you would have found only three lines, where no spaces are between
numbers and `,':
| ./phobos/std/date.d:    [ 0,31,59,90,120,151,181,212,243,273,304,334 ];
| ./phobos/std/zlib.d:    static ubyte[] data = [1,2,3,4,5,6,7,8,9,10];
| ./phobos/std/zlib.d:    static ubyte[] data = [1,2,3,4,5,6,7,8,9,10];

As you can see a special case. Why do you think he avoids to run into problems between `.' versus `..' or `,'?

So long.

because he prefers that style?

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:c0d8o6$2ab7$1@digitaldaemon.com...
> Sam McCall wrote:
>
> > Um, I think it's because walter has more difficult issues to deal with than . versus ..
>
> I see. Would you have had a look at his code, then you would have noticed, that he codes as if D has already more than the proposed change incorporated: always two spaces around `..' while one space would suffice. Whereas in comments he follows the natural way of specifying slices: mostly without surrounding spaces.
>
> And you would have found only three lines, where no spaces are between
> numbers and `,':
> | ./phobos/std/date.d:    [ 0,31,59,90,120,151,181,212,243,273,304,334 ];
> | ./phobos/std/zlib.d:    static ubyte[] data = [1,2,3,4,5,6,7,8,9,10];
> | ./phobos/std/zlib.d:    static ubyte[] data = [1,2,3,4,5,6,7,8,9,10];
>
> As you can see a special case. Why do you think he avoids to run into problems between `.' versus `..' or `,'?
>
> So long.

davepermen wrote:

[...]
> if it's NOT a
> logic error, but a typing error, i immediately spot the error while typing.

And why do you require, that your coding style is adopted by everyone? Not allowing for example data typists to transfer data from paper directly into code?

I am getting tired of this discussion: as far as I understand you, you do not bring up any arguments that the tokenizing of D must stay as it is; you agree, that typos of the form pointed out may happen, but you insist, that other tools surrounding the main tool `dmd' will help to capture them.

To me this is like wanting to drive a car built before 1971 with nearly no passive safety but equipping it with an electronic approaching warner and expounding, that the digital display of that device will clearly expose every danger when monitored constantly.

So long.

i just see no real life situation where this problem can occur, as i see no point in using non-suitable tools..

there is a reason we can display different fonts, colours, images, etc. they help us everywhere, as they do in coding.

i don't see your point simply. i simply don't.

if its a typing error you want to prevent, fine. if it's a logic error, you can't prevent it. they can never be.

but for the typing error i gave you a simple fact. today is not the day of console based edit, or vi, but the days of emacs, visual studio, textpad, dide, whatever. that moodens your point. it doesn't make it non-valid. it just makes it much less important than you may want it to be.

if you get tired, leave, or bring up reasons why it really is a problem. i still haven't seen a situation where it in fact can be an issue.

and in what way do i force my coding style to everyone?. this is not about coding style, just about the program you use to edit simple plain text files. give me one reason to not use a syntax highlighting editor instead of a non-syntax hightlighting. or places where we could not use one.

this has nothing to do with coding style. it's about proper tools for your job. as you choose the right language for your task.

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag news:c0dash$2drh$1@digitaldaemon.com...
> davepermen wrote:
>
> [...]
> > if it's NOT a
> > logic error, but a typing error, i immediately spot the error while
typing.
>
> And why do you require, that your coding style is adopted by everyone? Not allowing for example data typists to transfer data from paper directly into code?
>
> I am getting tired of this discussion: as far as I understand you, you do not bring up any arguments that the tokenizing of D must stay as it is; you agree, that typos of the form pointed out may happen, but you insist, that other tools surrounding the main tool `dmd' will help to capture
them.
>
> To me this is like wanting to drive a car built before 1971 with nearly no passive safety but equipping it with an electronic approaching warner and expounding, that the digital display of that device will clearly expose every danger when monitored constantly.
>
> So long.