![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> How does the Python interpreter/compiler even work with different types of
> whitespace?
I'm pretty sure most compilers complain if you mix tabs and spaces in the
same source file, at least at the beginning of lines. Pick one, stick with it.
> I bet it can become pretty confusing when the interpreter is giving you
> error messages or, much worse, it will parse ok but run complately wrongly,
> even though it *looks* to be ok.
nah. If you put tabs and spaces at the start of the line in the same source
file, you get an error message and you need to figure out why you're doing that.
> Relying on the use of whitespace for actual syntax is idiotic (with the
> exception of separating tokens with at least one whitespace character,
> while not being important how many).
I think distinguishing newline from other whitespace is reasonable.
> I'm not concerned about typos. I'm concerned about whitespaces being lost
> in transfer
Well, don't do that. :-) Treat python source code as something other than
prose, and you won't have that problem.
Really, if you're not using unicode, you're already behind the ball. So if
your transfer mechanism can't handle whitespace, you shouldn't be using it
to ship code around.
> You seem to assume that statements never get longer than a certain length,
> so that they will all nicely fit in one line. Sometimes it's useful to be
> able to split statements into several lines.
You don't need special characters to do this in most line-oriented
languages. Python, for example, happily continues the statement on the next
line if the current line isn't finished.
x = 27 +
15
is all one statement.
>> Otherwise, use a pasting service.
>
> Why should I have to use such things just because the language has a
> braindead idea of using whitespace as syntax?
The same reason you need to if your posting service has a braindead idea
about HTML-special tags. Why in the world would you use a language where <
and > are significant characters, when every web service out there might
corrupt them??
> Because when your editor can autoindent your code, it makes programming
> enormously easier (similarly to how syntax highlighting does).
Python editors auto-indent code. I'm not sure what you mean. An indent
always follows a line ending with a colon, and the dedent is no harder than
your closing brace in C.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> How does the Python interpreter/compiler even work with different types of
> whitespace? If, for example, one line as 4 spaces at the beginning and the
> next line has one tab character?
I don't know about Python. In Haskell, any file containing a single tab
character is immediately rejected (since tabs don't have any
standardised width). If you're coding in Haskell, you're just not
allowed to use tabs *at all*.
> Relying on the use of whitespace for actual syntax is idiotic (with the
> exception of separating tokens with at least one whitespace character,
> while not being important how many).
Actually it's pretty logical. You might argue that requiring the
programmer to manually type a semicolon at the end of each line when
it's obvious that each line is a seperate statement is illogical.
> I'm not concerned about typos. I'm concerned about whitespaces being lost
> in transfer and different types of whitespace.
The only real problem with using whitespace is that it tends to get
mangled in emails, forum posts, etc. This isn't a problem when you're
writing programs. This is *only* a problem if you try to post code
snippets on forums and so forth. (And yes, it's kind of irritating.)
> You seem to assume that statements never get longer than a certain length,
> so that they will all nicely fit in one line. Sometimes it's useful to be
> able to split statements into several lines.
I have no idea how Python works. What I do know is that Haskell is quite
sensible about this. If you have, say, an if/then/else expression, you
can write it all on one line, or on three seperate lines, or maybe on
even more lines than that. Hell, if you want to, you can write an entire
Haskell program on one line; whitespace is *optional*, and you can use
it the way you want to use it, provided that a few simple rules are
followed. It's really not that difficult.
>>> Also autoindentation of Python code is a physical impossibility.
Depends. I don't know Python's syntax rules. Haskell uses whitespace,
and it should be possible to autoindent it. (I'm not aware of any editor
which does it, but then I'm not aware of any editor which knows what the
hell Haskell is...)
>> Why would this be a concern?
>
> Because when your editor can autoindent your code, it makes programming
> enormously easier (similarly to how syntax highlighting does).
And to think that I do all my programming with an editor which doesn't
give me syntax hilighting *or* automatic indentation...
(Then again, I've yet to see an editor with auto-indent which actually
indents stuff the way that *I* want it to, rather than the way the guy
who wrote the editor wants it to.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > I'm not concerned about typos. I'm concerned about whitespaces being lost
> > in transfer
> Well, don't do that. :-) Treat python source code as something other than
> prose, and you won't have that problem.
Too bad that online forums and blogs won't.
> Really, if you're not using unicode, you're already behind the ball. So if
> your transfer mechanism can't handle whitespace, you shouldn't be using it
> to ship code around.
Tell that to all the forum and blog software out there.
> > Because when your editor can autoindent your code, it makes programming
> > enormously easier (similarly to how syntax highlighting does).
> Python editors auto-indent code. I'm not sure what you mean. An indent
> always follows a line ending with a colon, and the dedent is no harder than
> your closing brace in C.
Autoindentation is impossible for a program to do because it cannot know
where the block should end, as there is no keyword/character ending the block.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> > Relying on the use of whitespace for actual syntax is idiotic (with the
> > exception of separating tokens with at least one whitespace character,
> > while not being important how many).
> Actually it's pretty logical. You might argue that requiring the
> programmer to manually type a semicolon at the end of each line when
> it's obvious that each line is a seperate statement is illogical.
You don't type a semicolon at the end of each line. You type it at the
end of each statement. There may be more than one statement in a line, or
a statement may be split into several lines, and for example function
definitions are not ended with a semicolon.
Anyways, semicolons are seldom lost when you post a response to an online
blog post.
> > I'm not concerned about typos. I'm concerned about whitespaces being lost
> > in transfer and different types of whitespace.
> The only real problem with using whitespace is that it tends to get
> mangled in emails, forum posts, etc. This isn't a problem when you're
> writing programs. This is *only* a problem if you try to post code
> snippets on forums and so forth. (And yes, it's kind of irritating.)
Some editors also might convert spaces at the beginning of lines to tabs
(or the other way around) if you are not careful with the settings. This
doesn't really matter with normal programming languages.
> >> Why would this be a concern?
> >
> > Because when your editor can autoindent your code, it makes programming
> > enormously easier (similarly to how syntax highlighting does).
> And to think that I do all my programming with an editor which doesn't
> give me syntax hilighting *or* automatic indentation...
Why? Try some editor which is able to color your code, use it for a few
weeks, and you'll never switch back.
It naturally depends on the specific language, but with some languages
syntax highlighting and autoindentation actually help to catch typos as
you are writing your code. For example, if emacs starts autoindenting in
a completely crazy way, I immediately know that there's a typo somewhere
(maybe a missing curly bracket or semicolon). Likewise if the code gets
colored completely wrongly (for example if you forget to close a string).
Not that this happens often, but when it does, it's a great help.
> (Then again, I've yet to see an editor with auto-indent which actually
> indents stuff the way that *I* want it to, rather than the way the guy
> who wrote the editor wants it to.)
In many advanced editors you can configure how the autoindentation works.
For example emacs has quite a lot of configuration options. (Of course that
doesn't mean it's *easy* to configure.)
It's just really handy when a line is wrongly indented, I just press tab
(regardless of where the cursor is on that line currently, and regardless
of whether the line was indented too much or too little), and emacs indents
it just like I want.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gilles Tran <gil### [at] gmail com> wrote:
> Same experience here. I guess that's because it's easier to miss a semicolon
> or a brace in PHP than a whitespace in Python. I had to program in Python
> for a few days last year. At first I had the same WTF reaction as Warp about
> indentation but I found it much less error-prone in that respect than PHP. I
> like PHP, but its unability to cope with missing stuff is a time sink, as it
> outputs anything from a blank page to hebrew (unexpected
> T_PAAMAYIM_NEKUDOTAYIM).
If you keep having that problem with PHP, just use a smart editor which
autoindents your code. If the autoindentation goes haywire, you know that
you are missing some semicolon or brace.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Also autoindentation of Python code is a physical impossibility.
> No it's not.
Exactly how does the editor know where a block starts and where it ends,
unless it's *already* indented? How can you talk about autoindentation, if
it requires for the code to be already properly indented to begin with?
Clearly your definition of "autoindentation" is not the same as mine.
> Replacing indentation in python once the dedents have been
> lost is problematic. But that's like complaining if you delete all the
> closing braces in C then you can't figure out where to put them back.
No, it's not. Why not? Because whitespaces at the beginning of lines are
a lot easier to lose than braces.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Warp wrote:
>> Also autoindentation of Python code is a physical impossibility.
>
> No it's not. Replacing indentation in python once the dedents have been
> lost is problematic. But that's like complaining if you delete all the
> closing braces in C then you can't figure out where to put them back.
>
> But making all the indents a consistent amount? Pretty easy.
Also, many text editors automatically indent one more level after a line
finishing with a colon. I'd call that "autoindentation".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Actually it's pretty logical. You might argue that requiring the
>> programmer to manually type a semicolon at the end of each line when
>> it's obvious that each line is a seperate statement is illogical.
>
> You don't type a semicolon at the end of each line. You type it at the
> end of each statement. There may be more than one statement in a line, or
> a statement may be split into several lines, and for example function
> definitions are not ended with a semicolon.
Sure. But in reality, almost everybody writes one statement per line.
Sometimes you might put several on a line, but usually it's just one.
(Again, I can't comment on Python, but in Haskell you *can* in fact
still put multiple statements on a line, or spread one statement over
several lines. It's really not stopping you from doing that.)
> Anyways, semicolons are seldom lost when you post a response to an online
> blog post.
Granted.
>> The only real problem with using whitespace is that it tends to get
>> mangled in emails, forum posts, etc.
>
> Some editors also might convert spaces at the beginning of lines to tabs
> (or the other way around) if you are not careful with the settings. This
> doesn't really matter with normal programming languages.
I have never seen any text editor ever that converts spaces to tabs -
although I've seen loads that convert tabs to spaces. Which is really
fun when editing Makefiles, since they have this braindead idea of
having tab characters as part of the required syntax. :-P *That* is idiotic.
>> And to think that I do all my programming with an editor which doesn't
>> give me syntax hilighting *or* automatic indentation...
>
> Why?
Becuase no editor in existence can syntax hilight Haskell?
> Try some editor which is able to color your code, use it for a few
> weeks, and you'll never switch back.
I use a text editor which does support syntax hililghting, auto-indent
and a bunch of other things for XML, CSS, PostScript, TeX, JavaScript
and more. It just doesn't support Haskell, that's all. While it's nice
to have syntax hilighting and so on, it's hardly essential. I don't
really miss it all that much.
> It naturally depends on the specific language, but with some languages
> syntax highlighting and autoindentation actually help to catch typos as
> you are writing your code.
Sure. If you type "fro" instead of "for", it doesn't show up in bold. If
you're using an IDE rather than a mere text editor, it may even show you
mistyped identifiers. I get that.
> For example, if emacs starts autoindenting in
> a completely crazy way, I immediately know that there's a typo somewhere
> (maybe a missing curly bracket or semicolon).
You're saying "if it indents wrong, you've missed a delimiter". I'm
saying "if you indent it right, that's your delimiters". In a language
that uses whitespace delimiters, it's much harder to miss one in the
first place. (I will admit that it's very occasionally non-intuitive,
and just sometimes you'll see code that doesn't compile because of an
obscure spacing issue. But it's quite rare.)
>> (Then again, I've yet to see an editor with auto-indent which actually
>> indents stuff the way that *I* want it to, rather than the way the guy
>> who wrote the editor wants it to.)
>
> In many advanced editors you can configure how the autoindentation works.
> For example emacs has quite a lot of configuration options. (Of course that
> doesn't mean it's *easy* to configure.)
As you probably remember, I've never had much luck with either Emacs or Vi.
(Besides, Emacs isn't a text editor, it's an operating system! :-P )
> It's just really handy when a line is wrongly indented, I just press tab
> (regardless of where the cursor is on that line currently, and regardless
> of whether the line was indented too much or too little), and emacs indents
> it just like I want.
That does actually sound quite nice. I've never seen an editor which can
actually do that.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> >> And to think that I do all my programming with an editor which doesn't
> >> give me syntax hilighting *or* automatic indentation...
> >
> > Why?
> Becuase no editor in existence can syntax hilight Haskell?
I don't think that's true. http://www.haskell.org/haskell-mode/
> > Try some editor which is able to color your code, use it for a few
> > weeks, and you'll never switch back.
> I use a text editor which does support syntax hililghting, auto-indent
> and a bunch of other things for XML, CSS, PostScript, TeX, JavaScript
> and more. It just doesn't support Haskell, that's all. While it's nice
> to have syntax hilighting and so on, it's hardly essential. I don't
> really miss it all that much.
Maybe it's because you program mostly in Haskell and not those other
languages?
> > For example, if emacs starts autoindenting in
> > a completely crazy way, I immediately know that there's a typo somewhere
> > (maybe a missing curly bracket or semicolon).
> You're saying "if it indents wrong, you've missed a delimiter". I'm
> saying "if you indent it right, that's your delimiters".
Indenting is easier when the editor does it for you.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Also, many text editors automatically indent one more level after a line
> finishing with a colon. I'd call that "autoindentation".
If that's the only situation where it can, I wouldn't call it that.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |