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

[Ed Leafe]

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

Yeah, and it sucks! ;-)

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

 

[JohnBMudd]

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.

Natural languag (e.g. English) does not need documentation? Was there
a shortage of big fat text books in your English department at school??


I know you don't mean to but you're making my point for me.

John

 

[Fredrik Lundh]

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

people have posted more than just patches; see e.g.

http://www.google.com/search?q=corbascript

(and if someone has it disappeared without a ripple).

</F>

 

[Marc 'BlackJack' Rintsch]

Python could take over the programming world except one of it's best
features (scope by indent) is a primary reason why it never will. It's
not flexible enough. A large percentage of programmers won't even try
the language.

Their loss.

And nobody else sees the need for change? Oh, except those who think
Tabs are evil and should no longer be allowed.

How about (1) add some more flexibility for optional braces […]

Try this::

from __future__ import braces

Ciao,
Marc 'BlackJack' Rintsch

 

[JohnBMudd]

Try this:: from __future__ import braces


Thanks, that's funny.

John

 

[Guest]

I have never seen anyone suggest mixing tabs and spaces, and I
have read a lot of tabs-vs-spaces flamewars in my time.

Everyone agrees that mixing is bad. I might even go so far as to
say that the only real problem is mixing. The question is, if we
are trying to pick only one, which one causes fewer problems.

Actually using tabs for eight spaces and then filling out with spaces to
the correct indentation is the convention for Emacs Lisp. Of course,
since everyone coding Emacs Lisp does it with the same editor, it's no
problem.

 

[Paul Rubin]

Actually using tabs for eight spaces and then filling out with spaces to
the correct indentation is the convention for Emacs Lisp. Of course,
since everyone coding Emacs Lisp does it with the same editor, it's no
problem.

The variable `indent-tabs-mode' controls this. I like no tabs.

 

[Tim Roberts]

I'm starting to suspect that the same people who are zealous about
spaces are also the same people who look down on anyone who doesn't
agree with their choice of text editor.

Text editors are like underwear. Everyone has their own favorite brand,
and no rational argument will ever convince someone else to abandon their
brand.

 

[Tim Roberts]

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.

My high school sophomore would strongly disagree with your assertion that
natural language does not need documentation...

Both "The Design of Everyday Things" and "The Psychology of Everyday
Things" are fascinating books that should be mandatory reading for all
engineering students.

 

[Ben Sizer]

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?

You haven't suggested fixing a design defect. You've suggested changing
part of the design. Just because a few people dislike something,
doesn't make it a defect. I dislike child-proof medicine bottles, as
they're a slight inconvenience to me, but they serve an important
purpose.

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

Firstly, it's somewhat ironic that you have to cite a documented source
to back up your point. Some things simply require being put into words.
You make your point by referring to a book; I would make the case for
scope-indentation by referring to a paragraph in the docs.

Secondly, how is this at all relevant? Do you think that adding braces
to Python will mean we can remove part of the existing documentation?
That is the only logical conclusion to draw from what you're saying.

Thirdly, is a programming language an "Everyday Thing"? Computer
programs are, yes, but languages are not. They're targeted at a very
specific audience and are geared towards a very complex task. There is
only so much simplification that can be done before a tool becomes
useless.

The context of your quote is that that things should be
self-documenting and obvious.You simply can't do that with programming
languages. All you can do is try to make it as consistent as possible,
so that there are few surprises and as little documentation as
possible. Merging scope with indentation is one good example of doing
this.

 

[Guest]

The variable `indent-tabs-mode' controls this. I like no tabs.

Same here. It's still the convention for Emacs code, regrettably.

 

[Zeljko Vrba]

AGREE! AGREE! AGREE!

The day TABs are banned from the source, I drop python forever. It took me
too long to get used to indentation in the first place, now if you ban TABs
(which make code formatting a whole lot easier), I'm dropping python.

I've heard nice things about Ruby.. Maybe it's time to shift my primary
scripting language. I already made transition perl->python, and now I'm
observing pythong getting more and more hackish solutions and features..

 

[Paul McNett]

Same here. It's still the convention for Emacs code, regrettably.

I don't use Emacs, I do indent with tabs, and I do fill in the extra spaces of
continuation lines with spaces. Therefore, I break all the commandments and do
everything wrong.

FWIW, I've long struggled with my opinion on tabs versus spaces. When I started
programming in 1995, tabs seemed the logical choice because I was using
different editors all the time and I could tell each editor how many spaces to
give each tab. But then as I started reading more people's code I started seeing
patterns in source code that I couldn't emulate using pure tabs. This comes down
to horizontal "lining up" continuation lines with prior lines. Examples:

select customer.cfirst,
customer.clast
from customer
where customer.cstate in ("CA", "OR")
order by customer.clast

win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
Caption="Minesweeper Rules", SaveRestorePosition=True,
Centered=True, Modal=False)

Everyone that was writing "beautiful code" like this was using spaces only. So I
switched. But it was a real PITA to not be able to use any old editor, only ones
that could set how many hard spaces to make for each hard tab. And, I had to
remember to make that setting because I prefer 2 spaces per tab.

So now I'm back to tabs for indentation and spaces for lining up continuation
lines. Example:

win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
Caption="Minesweeper Rules", SaveRestorePosition=True,
Centered=True, Modal=False)

(if that didn't come over email correctly, that is one tab for indentation on
all three lines, followed by several spaces on lines 2 and 3 for getting the
arguments lined up with the previous line.)

I've been reluctant to admit to doing this since it violates the NEVER MIX TABS
AND SPACES commandment, but there you go. I found a way to reconcile the best of
both worlds, because let's face it, tabs do make slightly more sense.

Finding out that Emacs has been doing this by default makes me feel better about
admitting this publicly.

There are definitely issues with mixing whitespace like this, especially is
someone is encountering it without understanding it. But Python handles it just
fine.

 

[Christophe]

Paul McNett a écrit :

I don't use Emacs, I do indent with tabs, and I do fill in the extra
spaces of continuation lines with spaces. Therefore, I break all the
commandments and do everything wrong.

FWIW, I've long struggled with my opinion on tabs versus spaces. When I
started programming in 1995, tabs seemed the logical choice because I
was using different editors all the time and I could tell each editor
how many spaces to give each tab. But then as I started reading more
people's code I started seeing patterns in source code that I couldn't
emulate using pure tabs. This comes down to horizontal "lining up"
continuation lines with prior lines. Examples:

select customer.cfirst,
customer.clast
from customer
where customer.cstate in ("CA", "OR")
order by customer.clast

win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
Caption="Minesweeper Rules",
SaveRestorePosition=True,
Centered=True, Modal=False)

Everyone that was writing "beautiful code" like this was using spaces
only. So I switched. But it was a real PITA to not be able to use any
old editor, only ones that could set how many hard spaces to make for
each hard tab. And, I had to remember to make that setting because I
prefer 2 spaces per tab.

So now I'm back to tabs for indentation and spaces for lining up
continuation lines. Example:

win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
Caption="Minesweeper Rules",
SaveRestorePosition=True,
Centered=True, Modal=False)

(if that didn't come over email correctly, that is one tab for
indentation on all three lines, followed by several spaces on lines 2
and 3 for getting the arguments lined up with the previous line.)

I've been reluctant to admit to doing this since it violates the NEVER
MIX TABS AND SPACES commandment, but there you go. I found a way to
reconcile the best of both worlds, because let's face it, tabs do make
slightly more sense.

This is the only sane way to mix tabs with spaces anyway. Keep tabs as
an indentation counter and use spaces to fill up the remaining space for
the looks of the code.

 

[Christophe]

Zeljko Vrba a écrit :

The day TABs are banned from the source, I drop python forever. It took me
too long to get used to indentation in the first place, now if you ban TABs
(which make code formatting a whole lot easier), I'm dropping python.

Editors make code formatting easier, not TABs. Maybe it's time to leave
the 80s and use a code editor that works with you and not against you

 

[Fredrik Lundh]

The day TABs are banned from the source, I drop python forever. It took me
too long to get used to indentation in the first place, now if you ban TABs
(which make code formatting a whole lot easier), I'm dropping python.

luckily, python's not developed by random posters on the comp.lang.python
newsgroup, so I doubt you will ever have to drop Python for that reason...

</F>

 

[JohnBMudd]

Just because a few people dislike something,

doesn't make it a defect.

Actually, it does. Unless you're in the business of building security
systems. Then the goals are reversed.

I can accept that you like scope by indent and don't want to see any
changes gong forward. That's your choice.

it's somewhat ironic that you have to cite a documented
source to back up your point.

Somewhat.

Do you think that adding braces to Python will mean
we can remove part of the existing documentation?

No, it will add a little there. Where it will cut down is the
otherwise unending debate over the issue. Documentation is not just
what you find on a single web page.

And it might help bring Python into the mainstream. Granted, some
people have reasons against that too.

is a programming language an "Everyday Thing"?

No, the book helps by explaining design in terms that are easy to
grasp. Then it's possible to apply that basic understanding to other
areas.

...things should be self-documenting and obvious.
You simply can't do that with programming languages.

Maybe not completely. Trust me though, we can do better.

John

 

[Ben Sizer]

Actually, it does.

Whose definition of defect are we using? And how small a sample
population are we going to require in order to find a 'something' which
less than 'a few' people dislike?

Where it will cut down is the
otherwise unending debate over the issue. Documentation is not just
what you find on a single web page.

It will cut down debate but it would make the language more complex and
less consistent. I don't think that's a price worth paying.

And it might help bring Python into the mainstream.

I'd much rather educate the mainstream to be able to see the benefits
of this method, than drag Python down to meet them.

Maybe not completely. Trust me though, we can do better.

Of course. However I would argue that indented scope is one way of
doing so. Scope is instantly visible, and no longer a game of 'hunt the
punctuation character, which is in a different place depending on the
coder's style'.

 

[Antoon Pardon]

Actually, it does. Unless you're in the business of building security
systems. Then the goals are reversed.

I can accept that you like scope by indent and don't want to see any
changes gong forward. That's your choice.



Somewhat.


No, it will add a little there. Where it will cut down is the
otherwise unending debate over the issue. Documentation is not just
what you find on a single web page.

What I don't understand is, that most people who have a problem
with scope by indentation, want to introduce braces. I think
braces are the worst solution.

Python has clear constructs that mark where suites begin. There
is no need for an extra open brace. So if you don't want to
rely on indentation, something to mark the end of a suite
would be sufficient.

I personnaly don't like the forced indentation of python
and its lack of endmarkers for suits/blocks. I also think
it is not that a big deal. Just as I indent my code in
languages that don't enforce it, I generally put in
end markers when I program python.

In the past that was just by using comments like:

if ...:
...
#end

But lately I have been wondering about doing the following:

end = None

....

if ...:
...
end

IMO it looks better, but I'm reluctant because it suggest
some checking by the compilor, which just doesn't happen.

 

[Antoon Pardon]

Whose definition of defect are we using? And how small a sample
population are we going to require in order to find a 'something' which
less than 'a few' people dislike?


It will cut down debate but it would make the language more complex and
less consistent. I don't think that's a price worth paying.


I'd much rather educate the mainstream to be able to see the benefits
of this method, than drag Python down to meet them.


Of course. However I would argue that indented scope is one way of
doing so. Scope is instantly visible, and no longer a game of 'hunt the
punctuation character, which is in a different place depending on the
coder's style'.

There are situations in which indentation is not that visible.

The problem is that situations arise where your code can't be
read continuously. e.g. it can be spread over pages in a book.
It isn't always clear whether the code on the new space is
equally idented as the code on the previous space.

Other situations arise where indentation alone isn't a clear
indication of how many scopes are left.