Slashdot Mirror


User: wrygrin

wrygrin's activity in the archive.

Stories
0
Comments
32
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 32

  1. Re:Cygwin on The Best Linux Distro for a New User? · · Score: 1

    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.

  2. Re:Indentation syntax has its problems too on Guido van Rossum Unleashed · · Score: 3

    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.

  3. I had hints about this on Perl + Python = Parrot · · Score: 2

    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.)

  4. Re:Language Comparisons on Slashback: Lingualism, Cooperation, Re-entry · · Score: 3
    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!

  5. Re:Whitespace-sensitive on Python Development Team Moves to BeOpen.Com · · Score: 3
    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?).

    Voila.

  6. Re:Woohoo on Python Development Team Moves to BeOpen.Com · · Score: 1
    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.)

    Anyway, *i* enjoy the irony.

  7. Re:Hack or serious, this is out of hand... on Online Journal Publisher Raided by Police · · Score: 1

    Hmm - an obnoxious MIT hack? No less likely than the (obnoxious) possibility that it's real.