ANN: Dao Language v.0.9.6-beta is release!

[Sybren Stuvel]

Steven D'Aprano enlightened us with:

It seems to me that "one tab per indent level" is far more logical
than "some arbitrary number, N, of spaces, often a multiple of
eight, or four, or two, per indent level, and hope that the number
of spaces is a multiple of that arbitrary N". But maybe that's just
me.

It's me too. One tab per indent makes perfect sense.

went back to tabs, got frustrated with people complaining that
indentation was being mangled by various webmail and News clients

This is about the only place where I use four spaces (typed as one
tab, expanded by Vim): email and Usenet. The reason? I don't want my
post to become too wide. If my stuff is read by someone with tab sizes
larger than four, it might become too wide, so to prevent that I use
spaces. For all other things (like real source code instead of a
pasted snippet) I use tabs.

I'm almost fired up enough about this to start the Society For The
Treatment Of Tabs As First Class Characters. *wink*

LOL count me in ;-)

Sybren

 

[JohnBMudd]

It seems to me that the tabs-vs-spaces thing is really about who controls
the indentation: with spaces, it's the writer, and with tabs, it's the
reader.

Agreed.

if [scope by indent] really is scaring off

potential converts, then a dumbed-down dialect of python which uses
curly
brackets and semicolons might be a useful evangelical tool.

Yes, that's how I see it too.

 

[anthon]

How is that a problem that some editors use 8 columns for tabs and
others use less? So what?
A bigger problem I see is people using only 2 or 3 spaces for indenting.
That makes large amounts of code much less readable. And of course it
is a problem if you mix tabs and spaces at the beginning of the same line.
Tabs are easier to type (one keystroke each) and lead to visually better
results (greater indentation unless you like hitting 8 spaces for each
indent level).

Where does that misconception that 2-3 spaces for indenting makes
things less readable come from? There was an article in Comm. of the
ACM on research into readability back in 1984 or so, that indicated 2-4
spaces has very similar readability and 8 spaces significantly less
than that. IIRC they took care of personal preferences/what one was
used to in the research. So disallowing tabs which could be set to 8
spaces (positions?) does make sense to me.
I switched from using 2 to using 4 spaces for Python recently, and the
big pain was to deal with lines that no longer fitted in 80 columns :-(

 

[Ben Sizer]

Which is not to say that it's a bad idea - if it really is scaring off
potential converts, then a dumbed-down dialect of python which uses curly
brackets and semicolons might be a useful evangelical tool.

If we're going to be creating evangelical tools, I think a decent
description or tutorial explaining why scoping through indentation is a
better idea, rather than capitulating to the ignorance of those who
won't try something different.

If you repeat a piece of functionality, you factor it out into a single
function.
If you repeat a piece of data, you normalise it into a separate table
or object.
If you consistently find yourself having to enter a new scope and
indent at the same time, and close scopes and unindenting at the same
time, the sensible approach is to combine these concepts into one.

Surely any programmer worthy of the term can see benefits to the
approach when it is not just mentioned as a bizarre and arbitrary
limitation of the language.

 

[JohnBMudd]

a decent description or tutorial... is better

Sound good but... we're programmers, not documentation specialist or
motivational speakers. Why, when I suggest fixing a design defect with
code, do so many programmers want to respond with... documentation and
arguments instead of code?

From "The Design of Everyday Things", docs are a sign of poor design.

Even a single word, such as the word "Push" on the face of a door, is
an indication that the design can be improved. Please, rethink the
design instead of trying to compensate with more documentation.

John

 

[Magnus Lycka]

Where does that misconception that 2-3 spaces for indenting makes
things less readable come from? There was an article in Comm. of the
ACM on research into readability back in 1984 or so, that indicated 2-4
spaces has very similar readability and 8 spaces significantly less
than that. IIRC they took care of personal preferences/what one was
used to in the research. So disallowing tabs which could be set to 8
spaces (positions?) does make sense to me.
I switched from using 2 to using 4 spaces for Python recently, and the
big pain was to deal with lines that no longer fitted in 80 columns :-(

Bigger indentation steps *are* more obvious, but on the other
hand, smaller indentation allows you to use more indentation
levels without using up all of your line width. (Using more than
80 chars per line is typically a bad idea.)

In general, I find that you rarely need so many indentation
levels in Python as in e.g. C or C++. I rarely run out of line
width in Python, even though I use 4 space indents and use fairly
long names. Remember that you can freely break lines within pairs
of (), [] and {}, and that adjacent string literals are concatenated.

If you try to squeeze something like...

self.logger.log(log_level, "Blaha bla bla bla bla"
"at: %s:%i caused a %s with message\n%s\n" %
(file_name, row, error, error_message))

....into one line, it doesn't matter what indentation depth you use...

 

[Rick Wotnaz]

(e-mail address removed) wrote in

Sound good but... we're programmers, not documentation
specialist or motivational speakers. Why, when I suggest fixing
a design defect with code, do so many programmers want to
respond with... documentation and arguments instead of code?

Even a single word, such as the word "Push" on the face of a
door, is an indication that the design can be improved. Please,
rethink the design instead of trying to compensate with more
documentation.

So, for instance, even a single character (like an opening or
closing bracket or a semicolon) is an indication that the design
can be improved. Please, rethink your opposition instead of trying
to impose your design defect on a better, cleaner design.

Seriously. What you call a design defect and what other call a
design feature are one and the same.

I will concede this much: I would like a guarantee that helpful
software would not strip leading whitespace (as has happened with
some mail clients), which trashes logic-by-indention.

Alternatively, it might be useful to have brackets and semicolons
to overcome sadistic software interactions, but I don't *really*
expect Python to be willing and able to predict and prevent all the
crazy things other programs might do. And I certainly hope that
Python doesn't ever *require* the brackets and semicolons that add
so little value and so much clutter.

 

[JohnBMudd]

even a single character (like an opening or closing bracket or a semicolon) is an indication that the design can be improved.

Close, there are two principles for good design: Afford proper use and
Don't afford improper use. I could argue that not having to type extra
characters falls into the first category and so is part of why Python
is a better design. Not having to type extra characters makes it
easier (affords me) to enter source code in the first place and there's
less to maintain in the long run. That's probably why nobody in the
thread, including myself, has advocated "*require* the brackets".

But, like a lot of "solutions", in solving one problem Python has
created another one. Many people, for whatever reasons, feel that the
solution (scope by indent) prevents them from using the tool. Hence
Python has not really made it easier to type and maintain source code
for the general audience, it's has only polarized the audience. There
are many people who would say it definitely does NOT afford proper use.


Python is the superior design, today. But, like Betamax tape format,
Python isn't mainstream yet. And, sadly, maybe it never will be. I
want that changed. I want Python to take over the world so I don't
have to beg my next boss to let me use it. And if adding an optional
"dumbed-down" format will help then that might be an improvement in the
big picture.

John

 

[Richard Brodie]

Which is not to say that it's a bad idea - if it really is scaring off
potential converts, then a dumbed-down dialect of python which uses curly
brackets and semicolons might be a useful evangelical tool.

I doubt it: a lot of people have asserted something similar over
the years but I don't remember anyone ever bothering to post
a patch (and if someone has it disappeared without a ripple).

I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because
{ and } aren't intuitive.

 

[Steve Holden]

Close, there are two principles for good design: Afford proper use and
Don't afford improper use. I could argue that not having to type extra
characters falls into the first category and so is part of why Python
is a better design. Not having to type extra characters makes it
easier (affords me) to enter source code in the first place and there's
less to maintain in the long run. That's probably why nobody in the
thread, including myself, has advocated "*require* the brackets".

But, like a lot of "solutions", in solving one problem Python has
created another one. Many people, for whatever reasons, feel that the
solution (scope by indent) prevents them from using the tool. Hence
Python has not really made it easier to type and maintain source code
for the general audience, it's has only polarized the audience. There
are many people who would say it definitely does NOT afford proper use.


Python is the superior design, today. But, like Betamax tape format,
Python isn't mainstream yet. And, sadly, maybe it never will be. I
want that changed. I want Python to take over the world so I don't
have to beg my next boss to let me use it. And if adding an optional
"dumbed-down" format will help then that might be an improvement in the
big picture.

But you don't want it to be Python, is all.

regards
Steve

 

[Paul McNett]

Python is the superior design, today. But, like Betamax tape format,
Python isn't mainstream yet. And, sadly, maybe it never will be. I
want that changed. I want Python to take over the world so I don't
have to beg my next boss to let me use it. And if adding an optional
"dumbed-down" format will help then that might be an improvement in the
big picture.

I couldn't disagree more. I most certainly do *not* want Python to take over the
world. I want .NET and Java to prevail, so that large companies with money to
throw away at such technologies will continue to do so, and so that I can still
fly in under the radar to my small clients and be able to provide them with the
simplest solution that works at a price they can afford and a price that I can
live on. Having .NET and Java in the world makes me into more of a hero when I
can swoop in and get the real business problem solved using Python.

Now, say Python were to usurp everything else and become the dominant language.
Everyone would learn Python. Python would become all the rage and get all the
hype. Sun, Oracle, Microsoft, IBM, Apple, and SCO would all evangelize on their
new Python initiatives. Microsoft would attempt to release their version with
just a few non-standard things added on. Sun would sue them for not sticking
with standards. Books and articles would be written. Middle-level management
would start identifying places that Python is deficient in their eyes. CIO
Insight would start making recommendations. Everyone would be pumping so much
energy into so many different places that, like Java, Python would stall out and
be consumed by its own hype, and the programmers that made Python what it is
would burn out on it (read: they'd be busy counting all their stock options).

Plus, there would now be a deluge of Python programmers in the market place,
competing with my billing rate.

No, I like Python just where it is, thank you very much. If someone doesn't want
to give Python a second look because of their own bigoted ideas, I say Python
doesn't want that type of person to begin with. Perhaps that sounds a bit
elitist, but if people would just put their preconceptions aside, they'd quickly
realize that Python really does get block indentation (and a whole host of other
things besides) right.

 

[JohnBMudd]

If someone doesn't want

to give Python a second look because of their own bigoted ideas, I say Python
doesn't want that type of person to begin with.

Some days I feel the same way. I've described Python as a filter where
only the best get through. That's leads to a concentration of talent
and good taste which has great value and can even eclipse any
shortcomings in the flawed tool that initially drew the crowd together.
This is from a paper I started a long time ago, entitled "The Value of
Bad Design". I never finished it but I do think it might be valid.

John

 

[Paul Boddie]

I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because
{ and } aren't intuitive.

Indeed. Meanwhile, see Tools/scripts/pindent.py in the Python source
code distribution for a tool which understands block end delimiters and
can output normal Python programs from those using such delimiters. It
can also perform the transformation in reverse, converting those
indentation-happy source files to the rigid world of the block
delimiter.

Paul

 

[Sybren Stuvel]

Richard Brodie enlightened us with:

I'm sure some folk can remember local coding styles that suggested
using BEGIN and END as macros for curly brackets in C because { and
} aren't intuitive.

I think that if you sink that low, you shouldn't be programming
anyway. Come on, if someone can't even grasp the concept of having
symbols and understand their meaning, how is such a person going to
write a proper program?

Sybren

 

[Christopher Subich]

Having .NET and Java in the world makes me into more of a hero when I
can swoop in and get the real business problem solved using Python.

+1QOTW

 

[D H]

So, for instance, even a single character (like an opening or
closing bracket or a semicolon) is an indication that the design
can be improved.

Or a colon

 

[JohnBMudd]

Meanwhile, see Tools/scripts/pindent.py

Yes, thanks, that's very close to what I was thinking of.

If it just went a little further and used semi-colons and braces then
it would be complete. Granted, that might still not be enough for
people who don't like scope by indent. It would be interesting though
to see how people react to the option. Would they suddenly give Python
a try or simply look for another excuse? Such a little program could
make the test feasible.

John

 

[JohnBMudd]

But you don't want it to be Python, is all.

No, the opposite. I'm pro-Python but anti-stagnant, anti-dogma and
anti-bad design.

If Python never changes that will be okay too. It *is* great!

John

 

[Christopher Subich]

Even a single word, such as the word "Push" on the face of a door, is
an indication that the design can be improved. Please, rethink the
design instead of trying to compensate with more documentation.

This quote, with a naive reading, would seem to imply that "needing
documentation is evidence of bad design." I think we can all agree that
this interpretation is ludicrous: the only programming language, for
example, which does not need documentation is the natural language, and
that contains so many ambiguities that humans often get instructions wrong.

If nothing else, documentation is necessary to explain "why X instead of
Y," when both X and Y are perfectly valid, but mutually exclusive
choices (CamelCase versus underscore_names).

IMO, the correct interpretation of this reduces exactly to the principle
of least surprise. If a door needs to have a sign that says "push," it
means that a fair number of people have looked at the door and thought
it was a pull-door. But they expect it to be a pull-door based on
/experience with other doors,/ not some odd Platonic ideal of door-osity.

Some surprise, however, (especially in Python) is necessary because the
same feature can be seen more than one way: see the ever-present
discussion about func(arg=default) scoping of default arguments. While
"that's the way it is" shouldn't cover up true design flaws, arbitrary
replacement with another behaviour doesn't work either: the other way
will, ultimately, need the same order of documentation to catch
surprises coming from the other way.

 

[Paul McNett]

This quote, with a naive reading, would seem to imply that "needing
documentation is evidence of bad design." I think we can all agree that
this interpretation is ludicrous: the only programming language, for
example, which does not need documentation is the natural language, and
that contains so many ambiguities that humans often get instructions wrong.

Indeed, there is only one user interface that needs no documentation whatsoever.