roxen.lists.pike.general

Subject Author Date
Re: Pike & Python Dave Walton <dw-pike[at]digger[dot]net> 13-12-2008
Martin Bähr wrote:
> On Thu, Dec 11, 2008 at 01:01:12PM -0800, Dave Walton wrote:
>> Hehe, truly.  Guess I was thinking more about something like qbasic.
> 
> yeah, i learned basic on the trs-80, machines from the early 80s

Ah yes...  We had a Model I at school, back in the day.  I had some
little space game I typed in from a magazine, that used carefully tuned
assembly routines to generate RF interference that would produce sound
effects on an AM radio held near the computer.  The next year we got
Commodore PETs, with an actual speaker.  Such luxury!

> have you run into this? it has never been a problem here. but then i
> insist on using only spaces in pike as well so my indenting is always
> consistent.

I always use tabs, for the same reason.  :)

Yes, I actually have run into this.  Several years ago I was considering
learning Python, and started reading a tutorial on the web.  I copied a
sample program from my browser into an editor to tinker with, and
somehow whitespace got mangled in the process.  That's when I realized
that without understanding exactly what the code did, and how, line by
line, there simply was not enough information to fix the program.
Imagine someone took a Pike program and stripped out all the {} and
indentation.  How would you fix it?

Since then, every time I see a mixture of spaces and tabs in a file
(which happens pretty easily with different programmers and different
editors), I realize that if it was a Python script it would be broken.
The Python community has standardized on 4-space indents to work around
the problem, but that only reduces the likelihood of corruption and you
are still dependent on the editor and other things to not bite you.

A hypothetical example:  You write some Python code for your company's
server.  A JavaScript programmer comes to you because of some problem
he's having with calls to your code, so you go over to his workstation
to see what's happening.  There you realize you left out an important
line and, being late for a meeting, quickly add it on his workstation
and check it in.  Unfortunately, since he's not a Python programmer, the
auto-indent feature in his editor inserts tabs, not spaces.  Sure, it
LOOKED correctly indented on-screen, but...

Probably not the best example, but the point is that there are all kinds
of ways for whitespace to get corrupted.  And some of them you might not
even notice when looking at the code.  So I'm a firm believer that
pretty formatting is for the sake of the reader, and the computer should
only care about visible characters.

Clearly, not everyone agrees with me.  :)

> hehe, there is something positive about the culture that comes out of
> this. having tests inline encourages writing tests right away.

And you are much more likely to update them when the code changes.

> we don't do this here at work, and as a result most tests are written as
> an afterthought...

Same here, if they get written at all.  While I'm not convinced it fits
well in all circumstances, there's definitely something to be said for
the notion of writing the tests first.

Dave