If i weren't so happy with gentoo, i'd seriously consider using cygwin. (I would also need a better windows-rooted X11 than the XFree port i last tried in Cygwin, but maybe the wrinkles have been ironed out in the intervening months.)
I run gentoo, and increasingly feel rewarded by the amount of system familiarity it requires (and gracefully supports) in its users.
The advantage of the cygwin approach is that windows apps (for me, comprehensive linkage with my creative nomad Zen) and most of the drivers are there, or on CDs that come with your product.
The advantage of the linux approach is you're not depending on an OS from a crooked vendor. I'm not objecting out of some kind of purity - you wind up paying for things just to keep the system viable.
I may be misunderstanding you, but it looks like you're missing the point.
In a language like C, braces express grouping for the computer, and
people arrange their code with indentation to make the grouping
obvious to themselves (and other people). The problem with this is
that the two are not coupled - the braces and the indentation can
conflict, *misleading* people about how the compiler is interpreting
the program. The cited example is exactly a case in point:
> if (x == 4)
> x = 10;
> y = 6;
>
> Now how did I know that the writers intent was
>
> if (x == 4) { x = 10; }
> y = 6;
>
> or
>
> if (x == 4) {
> x = 10; y = 6;
> }
As C code, it means one thing according to the whitespace and
another thing according to the braces - so the programmers intent is
undecidable from the context. Even the programmer themselves,
rereading code, may be unable to reconstruct the reasoning. If the
example is python code, there is no room for doubt. This is a good
thing!
Most python programmers i know who came to python with substantial
experience had a moment of doubt about the whitespace structuring, and
then (sooner or later) an epiphany that not only _can_ it work, it
works well. Very well. It's no small bonus that it reduces
clutter/visual noise, besides.
I knew larry and guido didn't buy into the knee-jerk antagonism that some folk in their community pursue - but this is quite a big step.
I'm just writing to say i had one small hint about this - there was news circulating in the winux underground(*) about the *book*, of all things! It was apparently noteworthy because it was expected to be about the same size as all the other nutshell books - combined.
This is, um, a big day!
((*) winux underground - a group of computing heretics and general dabblers seeking merger of the windows and linux operating systems - to get the compactness and elegance of windows internals and the grace and ease-of-use of the linux desktop(s), all in one place.)
I would be interested in knowing the relative effort of creation for each of the languages.
Of course, this is a much more difficult question - but i, for one, think it is a much *much* more interesting one. For a rare and satisfyingly substantial example of a study concerned with just this question, see (postscript) "An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a Search/String-Processing Program". It involves much more than lines-of-code and wild-assed guessing - it's an extensive and rational empirical study that examines programming practice and productivity, and the way that different languages facilititate it. Cool!
Specifically, it prevents the inevitable discrepancies between braces and indentation that people accidentally do. This is unfortunate when the computer asseses structuring rigorously by the braces, while people tend to assess the structuring by the layout - the indentation. Sometimes it turns out to be syntactically correct, but not what the programmer *meant*. A nearly invisible bug.
The principle is that, whenver possible, computers should be made to do what's easiest for the person, and not vice-versa - and the indentation is easiest for the person to read. The layout manifests the programmer's intended structuring - for the programmer and and the computer.
As for not being able to do what you want - all python imposes is that separate lines at the same block level must have the same indentation, and increasing levels have greater indentation w.r.t. their containing blocks. (The amount of indentation is up to you, and can vary.) I would be surprised if this is contrary to the vast majority of seasoned programmers' personal styles. The only thing you have to lose is your braces (and you can use parens to force groups in expresions, besides) and semicolons (and you *can* use the semicolons, but why?).
Actually, the name "python 3000" is to be admired!
It's a provisional name, mocking the spectacularly ironic lateness of "Windows 95". The idea is that it's really really unlikely that python 3000 is going to be late. (And the real plan is to rename it when the release is at all drawing near - probably to a time-independent name. Something boring, like Python 2.0, or something more provocative, like The Spanish Inquisition.)
If i weren't so happy with gentoo, i'd seriously consider using cygwin. (I would also need a better windows-rooted X11 than the XFree port i last tried in Cygwin, but maybe the wrinkles have been ironed out in the intervening months.)
I run gentoo, and increasingly feel rewarded by the amount of system familiarity it requires (and gracefully supports) in its users.
The advantage of the cygwin approach is that windows apps (for me, comprehensive linkage with my creative nomad Zen) and most of the drivers are there, or on CDs that come with your product.
The advantage of the linux approach is you're not depending on an OS from a crooked vendor. I'm not objecting out of some kind of purity - you wind up paying for things just to keep the system viable.
So i run gentoo.
I may be misunderstanding you, but it looks like you're missing the point.
In a language like C, braces express grouping for the computer, and people arrange their code with indentation to make the grouping obvious to themselves (and other people). The problem with this is that the two are not coupled - the braces and the indentation can conflict, *misleading* people about how the compiler is interpreting the program. The cited example is exactly a case in point:
> if (x == 4)
> x = 10;
> y = 6;
>
> Now how did I know that the writers intent was
>
> if (x == 4) { x = 10; }
> y = 6;
>
> or
>
> if (x == 4) {
> x = 10; y = 6;
> }
As C code, it means one thing according to the whitespace and another thing according to the braces - so the programmers intent is undecidable from the context. Even the programmer themselves, rereading code, may be unable to reconstruct the reasoning. If the example is python code, there is no room for doubt. This is a good thing!
Most python programmers i know who came to python with substantial experience had a moment of doubt about the whitespace structuring, and then (sooner or later) an epiphany that not only _can_ it work, it works well. Very well. It's no small bonus that it reduces clutter/visual noise, besides.
I knew larry and guido didn't buy into the knee-jerk antagonism that some folk in their community pursue - but this is quite a big step.
I'm just writing to say i had one small hint about this - there was news circulating in the winux underground(*) about the *book*, of all things! It was apparently noteworthy because it was expected to be about the same size as all the other nutshell books - combined.
This is, um, a big day!
((*) winux underground - a group of computing heretics and general dabblers seeking merger of the windows and linux operating systems - to get the compactness and elegance of windows internals and the grace and ease-of-use of the linux desktop(s), all in one place.)
Of course, this is a much more difficult question - but i, for one, think it is a much *much* more interesting one. For a rare and satisfyingly substantial example of a study concerned with just this question, see (postscript) "An Empirical Comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a Search/String-Processing Program". It involves much more than lines-of-code and wild-assed guessing - it's an extensive and rational empirical study that examines programming practice and productivity, and the way that different languages facilititate it. Cool!
The principle is that, whenver possible, computers should be made to do what's easiest for the person, and not vice-versa - and the indentation is easiest for the person to read. The layout manifests the programmer's intended structuring - for the programmer and and the computer.
As for not being able to do what you want - all python imposes is that separate lines at the same block level must have the same indentation, and increasing levels have greater indentation w.r.t. their containing blocks. (The amount of indentation is up to you, and can vary.) I would be surprised if this is contrary to the vast majority of seasoned programmers' personal styles. The only thing you have to lose is your braces (and you can use parens to force groups in expresions, besides) and semicolons (and you *can* use the semicolons, but why?).
Voila.
It's a provisional name, mocking the spectacularly ironic lateness of "Windows 95". The idea is that it's really really unlikely that python 3000 is going to be late. (And the real plan is to rename it when the release is at all drawing near - probably to a time-independent name. Something boring, like Python 2.0, or something more provocative, like The Spanish Inquisition.)
Anyway, *i* enjoy the irony.
Hmm - an obnoxious MIT hack? No less likely than the (obnoxious) possibility that it's real.