 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.itworld.com/government/105031/will-wall-street-require-python
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> http://www.itworld.com/government/105031/will-wall-street-require-python
Python must have the most idiotic block delimiter in the history of
programming languages: Whitespace indentation.
Why is it idiotic? Because whitespace is the one thing which gets most
easily and regularly lost in communication.
For example, someone might ask some question about Python in a forum or
blog post, and then someone might answer it with some Python code... and
the blog/forum software removes whitespaces from the beginning of lines,
completely changing the meaning of the program and making it inoperable.
There are also many other situations where whitespaces at the beginning
of lines might not be preserved (or might be changed somehow).
Also autoindentation of Python code is a physical impossibility.
The person who thought that it's a good idea to have indentation as
block delimiters should be shot.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The person who thought that it's a good idea to have indentation as
> block delimiters should be shot.
I'll go find out which member of the Haskell committee decided to do this...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escreveu:
> For example, someone might ask some question about Python in a forum or
> blog post, and then someone might answer it with some Python code... and
> *the blog/forum software removes whitespaces* from the beginning of lines,
> completely changing the meaning of the program and making it inoperable.
well, at least you recognize it's not Python's fault. ;)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/20/10 03:52, Warp wrote:
> Why is it idiotic? Because whitespace is the one thing which gets most
> easily and regularly lost in communication.
>
> For example, someone might ask some question about Python in a forum or
> blog post, and then someone might answer it with some Python code... and
> the blog/forum software removes whitespaces from the beginning of lines,
> completely changing the meaning of the program and making it inoperable.
> There are also many other situations where whitespaces at the beginning
> of lines might not be preserved (or might be changed somehow).
You know, for all the complaints people have about Python's whitespace,
not once in all the years of coding Python has it been an issue for me.
Well, OK - occasionally had issues with people mixing tabs with spaces,
but then I learned to use a proper editor.<G>
Know how often I've had issues compiling because of a missing brace or
semicolon? Orders of magnitude more frequently than whitespace issues in
Python.
Once I had spent just a short amount of time in the Python world, I
really hated semicolons in whatever other language I was coding in. A
royal pain to have to enter a mostly pointless character after each
statement.
Most online forums have a [code] tag or something similar to ensure
nothing gets formatted. Otherwise, use a pasting service.
> Also autoindentation of Python code is a physical impossibility.
Why would this be a concern?
> The person who thought that it's a good idea to have indentation as
> block delimiters should be shot.
Shoot me while you're at it, too ;-)
Python's the only whitespace sensitive language I've dealt with where
it wasn't an issue.
--
Growing old is mandatory; growing up is optional!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/20/10 04:15, nemesis wrote:
> Warp escreveu:
>> For example, someone might ask some question about Python in a forum or
>> blog post, and then someone might answer it with some Python code... and
>> *the blog/forum software removes whitespaces* from the beginning of
>> lines,
>> completely changing the meaning of the program and making it inoperable.
>
> well, at least you recognize it's not Python's fault. ;)
POTD.
--
Growing old is mandatory; growing up is optional!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan <m.n### [at] ieeeorg> wrote:
> Well, OK - occasionally had issues with people mixing tabs with spaces,
> but then I learned to use a proper editor.<G>
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 (which many editors will show as wide as
8 spaces, and in fact some editors will convert groups of 8 spaces into
tabs), how does the interpreter interpret that? And what happens if you
change the tab width in your editor settings?
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.
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).
> Know how often I've had issues compiling because of a missing brace or
> semicolon? Orders of magnitude more frequently than whitespace issues in
> Python.
I'm not concerned about typos. I'm concerned about whitespaces being lost
in transfer and different types of whitespace (spaces, different types of
tab characters..) being interpreted differently by different programs (the
text editor might be showing you something completely different than what
the Python interpreter is seeing).
Whitespace at the beginning of lines should be purely aesthetical, not
integral part of the syntax.
> Once I had spent just a short amount of time in the Python world, I
> really hated semicolons in whatever other language I was coding in. A
> royal pain to have to enter a mostly pointless character after each
> statement.
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.
> Most online forums have a [code] tag or something similar to ensure
> nothing gets formatted.
Except that many don't.
> 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?
> > Also autoindentation of Python code is a physical impossibility.
> 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).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Neeum Zawan" <m.n### [at] ieeeorg> a écrit dans le message de groupe de
discussion : 4bce01c9$1@news.povray.org...
> On 04/20/10 03:52, Warp wrote:
> Know how often I've had issues compiling because of a missing brace or
> semicolon? Orders of magnitude more frequently than whitespace issues in
> Python.
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).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran escreveu:
> 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).
LOL
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gil### [at] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Why?
>
>> Becuase no editor in existence can syntax hilight Haskell?
>
> I don't think that's true. http://www.haskell.org/haskell-mode/
So... that's Emacs then?
Perhaps I should rephrase my statement... uh... No easily usable editor
in existance can syntax hilight Haskell. How about that?
> Maybe it's because you program mostly in Haskell and not those other
> languages?
More likely it's because Haskell is the kind of language which is quite
easy to work with even without hilighting and other frills.
>> 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.
Well, maybe. Besides, my editor does some of the work for me; each line
is indented the same amount as the previous one, which is what you want
the majority of time. If for some reason I'm forced to use Notepad, I
really *really* miss this!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Nicolas Alvarez <nic### [at] gmailcom> 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.
Where *else* would you need to increase the indentation?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> More likely it's because Haskell is the kind of language which is quite
> easy to work with even without hilighting and other frills.
At least if you remember the five million standard library function
names by heart and hence can easily distinguish between standard library
calls and other function calls... (a task made easier by the fact that the
names are usually short, non-descriptive, and lack any kind of standard
naming convention or namespace).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> > Nicolas Alvarez <nic### [at] gmailcom> 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.
> Where *else* would you need to increase the indentation?
There are many situations where you need to re-indent code, either deeper
or shallower (and not always every line the same amount). And not only when
you want to end a code block in Python.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> More likely it's because Haskell is the kind of language which is quite
>> easy to work with even without hilighting and other frills.
>
> At least if you remember the five million standard library function
> names by heart and hence can easily distinguish between standard library
> calls and other function calls... (a task made easier by the fact that the
> names are usually short, non-descriptive, and lack any kind of standard
> naming convention or namespace).
Depends on the standard libraries.
If you're programming in Java, I'd estimate that you have approximately
a 0.02% change of ever doing this without constantly having the
documentation files open at your side (either electronic or paper). The
Java libraries are *vast*, horribly messy, vaguely documented, and it's
nearly impossible to keep track of which interfaces are depracated or
whatever.
If you're working with Haskell, it's comparatively easy. Maybe it's
because Haskell doesn't have many libraries, I don't know, but I don't
very often need to look things up. If I'm using Cairo, I'll probably
have the help file open. Or if I'm using some container that I don't use
very often. But in general, I don't need to look very much up. I don't
know if it's because the libraries are smaller or the names are better
or what.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Depends on the standard libraries.
Or if you are using an IDE with intelligent auto-complete, I find I very
rarely need to actually open the help files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Depends on the standard libraries.
>
> Or if you are using an IDE with intelligent auto-complete, I find I very
> rarely need to actually open the help files.
Then again, Java uses names like
java.lang.ArrayIndexOutOfBoundsException
(I find it especially amusing that they shortened "language" to "lang",
but they couldn't find a shorter class name...)
In Haskell, about the worst thing you might have to type is
Data.ByteString.Lazy.Char8.empty
If you're sensible, you'll alias this so you only write
BS.empty
or similar. Suddenly autocomplete seems a whole lot less necessary.
Of course, the *other* function of autocomplete is not to save typing,
but to help you look stuff up faster. Generally in Haskell, remembering
the name isn't the problem; it's remembering what the hell the
difference between "insert" and "update" is. The type signature will
usually tell you that; if not, you need the documentation. ASSUMING
THERE IS ANY! >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In Haskell, about the worst thing you might have to type is
>
> Data.ByteString.Lazy.Char8.empty
>
> If you're sensible, you'll alias this so you only write
>
> BS.empty
>
> or similar. Suddenly autocomplete seems a whole lot less necessary.
Still useful for when you write the alias though at the top of your
function/program.
> Of course, the *other* function of autocomplete is not to save typing, but
> to help you look stuff up faster. Generally in Haskell, remembering the
> name isn't the problem; it's remembering what the hell the difference
> between "insert" and "update" is. The type signature will usually tell you
> that; if not, you need the documentation. ASSUMING THERE IS ANY! >_<
AutoComplete in Visual Studio Express usually gives you a line or two of
explanation underneath the function name and parameter list - see attached
image. After you have chosen the function, you can scroll through the
various overloads if they exist to get more details.
Post a reply to this message
Attachments:
Download 'image1.png' (34 KB)
Preview of image 'image1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> 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.
Then they're broken, or you shouldn't use a prose-based interface to
transfer structured text.
> Tell that to all the forum and blog software out there.
Sure. That they're common doesn't mean they aren't broken.
You know what else is broken? Java assuming file names match class names,
and making class names case-sensitive. You deal with it. :-)
> 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.
Oh, auto-reindentation. Yes, there's no way to know where the block ends
without maintaining the whitespace.
Actually, the parser works with "indent" and "dedent", so you could in
theory store actual characters in the code to indicate that.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Anyways, semicolons are seldom lost when you post a response to an online
> blog post.
But < and > are. And python posts can translate to
> 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.
As long as you do it consistently, it's OK with Python. The only thing
python disallows is mixed tabs and spaces.
> 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.
Poor-man's intellisense. :-)
I've been restructuring some code in C#, and it's cool to scroll thru the
file looking for red underlines and fixing those up without even compiling
the stuff. "Oh, this isn't defined? I'll go over there and define it.
Whoops, I must have spelled it wrong because the underlines didn't go away.
Nope, it was taking a different class as an argument." All without even
saving the files.
> 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 with VIM, where you write regular expressions for when to indent and what
colors you want and etc.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> (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.)
Python too. I don't think you could put the whole program on one line,
because I don't think you can dedent except at the end of a line.
> I have never seen any text editor ever that converts spaces to tabs -
You can ask for it in most editors.
> Becuase no editor in existence can syntax hilight Haskell?
What's the extention for Haskell source files? Can you post a snippit of
Haskell here?
> (Besides, Emacs isn't a text editor, it's an operating system! :-P )
Out of curiousity, does elisp run outside of emacs? Can emacs run without a
window open? I.e., could you write a web server in elisp?
> That does actually sound quite nice. I've never seen an editor which can
> actually do that.
Uh, visual studio?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't think that's true. http://www.haskell.org/haskell-mode/
http://projects.haskell.org/haskellmode-vim/
> Indenting is easier when the editor does it for you.
You should try an IDE that indents Python for you. It's really actually
fewer keystrokes than C-like languages, because the start-of-indent is part
of the syntax. There's an indent key and a dedent key, and you use them
*instead* of { and }.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> AutoComplete in Visual Studio Express usually gives you a line or two of
> explanation underneath the function name and parameter list - see
> attached image. After you have chosen the function, you can scroll
> through the various overloads if they exist to get more details.
Plus, as you're typing the arguments, it gives you help for each argument.
image.Draw(screen, []
and the drop-down list will say something like
float rotation
Amount to rotate the image in radians
I.e., so you know whether it's radians or degrees expected.
And this works for your own code. Even before you save the file.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Python too. I don't think you could put the whole program on one line,
> because I don't think you can dedent except at the end of a line.
Even though the C and C++ languages don't require any newlines to be
used, the C preprocessor does (you can't put two #-directives in one line).
If you avoid using preprocessor directives completely (which is completely
possible, although inconvenient) you could write any C or C++ program in one
single line (or at least I can't think of any exception right now).
Not that this is a good thing per se and all in itself. Just commenting.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (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.)
>
> Python too. I don't think you could put the whole program on one line,
> because I don't think you can dedent except at the end of a line.
Haskell really will allow you to put the entire program on line (really
long) line.
But then, in Haskell, whitespace is *optional*. You can use semicolons
and curly braces instead if you prefer. It's just that nobody ever does
(except for sticking several items on one line).
>> I have never seen any text editor ever that converts spaces to tabs -
>
> You can ask for it in most editors.
Really? Why on earth would you want to? Tabs are evil and should never
have existed in the first place! o_O
>> Becuase no editor in existence can syntax hilight Haskell?
>
> What's the extention for Haskell source files?
Plain source is *.hs, "literate Haskell" is *.lhs (That's where all text
is comments be default, and source is quoted, rather than the usual way
around.)
> Can you post a snippit of Haskell here?
What, the other groups don't have enough Haskell source in them already?
qsort xs =
case xs of
[] -> []
[x] -> [x]
x:xs ->
let
ys1 = filter (x <) xs
ys2 = filter (x >) xs
in qsort ys1 ++ [x] ++ qsort ys2
>> (Besides, Emacs isn't a text editor, it's an operating system! :-P )
>
> Out of curiousity, does elisp run outside of emacs? Can emacs run
> without a window open? I.e., could you write a web server in elisp?
No idea mate, no idea. :-)
>> That does actually sound quite nice. I've never seen an editor which
>> can actually do that.
>
> Uh, visual studio?
As documented, VS doesn't indent things the way *I* like. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Plus, as you're typing the arguments, it gives you help for each argument.
>
> I.e., so you know whether it's radians or degrees expected.
Or find out what the hell the order of the argument is...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Also autoindentation of Python code is a physical impossibility.
>
>> No it's not.
>
> Clearly your definition of "autoindentation" is not the same as mine.
I guess not. I figured you meant "indenting as you type" or something. Not
"strip all indicators of block structure, followed by trying to replace
them." The editors one uses for python all indent when you start a block
automatically and keep that indent until you type the dedent character.
> No, it's not. Why not? Because whitespaces at the beginning of lines are
> a lot easier to lose than braces.
Only if the software you're using strips them out on purpose.
What you're saying is "Python using whitespace is stupid because a lot of
web sites don't treat whitespace as significant." Sure, OK, that's an opinion.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> There are many situations where you need to re-indent code, either deeper
> or shallower (and not always every line the same amount).
Your cut and paste has to be smart about reindenting the code, yes. But
that's no harder than indenting code based on { } markers.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Indenting is easier when the editor does it for you.
> You should try an IDE that indents Python for you. It's really actually
> fewer keystrokes than C-like languages, because the start-of-indent is part
> of the syntax. There's an indent key and a dedent key
In emacs there's one single key for indenting, which will indent new lines
or existing lines, regardless of where in the line the cursor is at the
moment and whether the line is currently over-indented or under-indented.
How is that "fewer keystrokes".
> and you use them *instead* of { and }.
{ and } have nothing to do with indentation. They aren't even necessary
for all code blocks.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Warp wrote:
> >>> Also autoindentation of Python code is a physical impossibility.
> >
> >> No it's not.
> >
> > Clearly your definition of "autoindentation" is not the same as mine.
> I guess not. I figured you meant "indenting as you type" or something.
That's only *part* of it. Autoindentation works on existing lines too.
> What you're saying is "Python using whitespace is stupid because a lot of
> web sites don't treat whitespace as significant." Sure, OK, that's an opinion.
I think it's a very valid opinion taking into account the amount of
programming forums and blogs out there.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>
>> Plus, as you're typing the arguments, it gives you help for each
>> argument.
>>
>> I.e., so you know whether it's radians or degrees expected.
>
> Or find out what the hell the order of the argument is...
Yep. Even better than type signatures, when you have three floats in a row.
Or it makes it easy to figure out you can do something like
Color newcolor = new Color(oldcolor, newalpha)
and see that there's an overload for constructing a color out of the RGB of
one color and a specific alpha value.
(And no, the "new" is syntactic noise there - it doesn't allocate anything
on the heap.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> How is that "fewer keystrokes".
That's "reindenting". I'm talking about indenting as you type. That kind of
indenting isn't useful in Python, any more than a macro to "add in the
missing braces" is useful.
>> and you use them *instead* of { and }.
>
> { and } have nothing to do with indentation. They aren't even necessary
> for all code blocks.
And indenting isn't necessary for all code blocks in Python. But, like { }
in C, indenting is necessary when you have several statements on separate
lines that you want as a block.
I'm saying that indenting isn't a tedious matter of typing the right number
of tabs on each line in Python.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> As documented, VS doesn't indent things the way *I* like. ;-)
Did you ever adjust it to your liking? There's a bunch of knobs to tweak,
you know.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> I guess not. I figured you meant "indenting as you type" or something.
> That's only *part* of it. Autoindentation works on existing lines too.
If existing lines are indented incorrectly, then your code is broken. The
reason that "auto indenting" is not possible in Python is the same reason
that "auto bracing" isn't possible in C.
>> What you're saying is "Python using whitespace is stupid because a lot of
>> web sites don't treat whitespace as significant." Sure, OK, that's an opinion.
>
> I think it's a very valid opinion taking into account the amount of
> programming forums and blogs out there.
Sure. It's just a question of whether you're fixing the wrong problem. It's
like saying everyone should learn English because most blogs only handle
ASCII. People fixed most of the web apps to not corrupt < and >. People
who post Python code should do it via web apps that don't corrupt leading
whitespace in python apps.
Now, I'll grant that the best thing would be to have indent and dedent
characters or sequences (like trigraphs in C perhaps). Cutting text from a
Python file should insert said trigraphs, and text editors that understand
python could turn them back into appropriate indentation. (Using the generic
"you":) But reducing *my* productivity during coding simply because *you*
are too lazy to not corrupt my source code is not a good thing.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> If existing lines are indented incorrectly, then your code is broken. The
> reason that "auto indenting" is not possible in Python is the same reason
> that "auto bracing" isn't possible in C.
Actually, I can't think why "auto-bracing" wouldn't be possible in C,
at least if you don't mind having braces even around single-statement blocks
(something which many programming guides actually recommend).
Every time you write a statement which is followed by a code block (even
if it's an empty one in rare cases), such as a for-loop, the editor could
automatically add the '{' and '}' characters and indent the code such that
you can just keep typing the contents of the loop. (The only think which
would slightly interrupt the flow would be that when you end writing the
code block you need to exit it by pressing the down cursor a couple of
times...)
Hmm, maybe I'll try to make emacs do exactly that. At least by binding
that functionality to some key...
A lesser variation of that would be that every time you write a '{' the
editor automatically adds (and indents) a '}'. The editor could actually
constantly keep matching braces auto-indented, even if one of the pair is
changed somehow (most editors, including emacs, can highlight matching
braces, so it shouldn't be a problem to auto-indent them as well).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>> http://www.itworld.com/government/105031/will-wall-street-require-python
>
> Python must have the most idiotic block delimiter in the history of
> programming languages: Whitespace indentation.
>
> Why is it idiotic? Because whitespace is the one thing which gets most
> easily and regularly lost in communication.
>
> For example, someone might ask some question about Python in a forum or
> blog post, and then someone might answer it with some Python code... and
> the blog/forum software removes whitespaces from the beginning of lines,
> completely changing the meaning of the program and making it inoperable.
> There are also many other situations where whitespaces at the beginning
> of lines might not be preserved (or might be changed somehow).
>
> Also autoindentation of Python code is a physical impossibility.
>
> The person who thought that it's a good idea to have indentation as
> block delimiters should be shot.
>
So you are saying that the programming language is no good unless it
allows production code to be floated around on blogs?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> So you are saying that the programming language is no good unless it
> allows production code to be floated around on blogs?
No, I'm saying that using whitespace as syntax is a bad idea.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> If existing lines are indented incorrectly, then your code is broken. The
>> reason that "auto indenting" is not possible in Python is the same reason
>> that "auto bracing" isn't possible in C.
>
> Actually, I can't think why "auto-bracing" wouldn't be possible in C,
> at least if you don't mind having braces even around single-statement blocks
> (something which many programming guides actually recommend).
This is why: Take all the braces out of a C program. Now put them back in
the right place. That's what you're asking.
Distinguish between "indent Python not knowing how much it should be
indented" and "indent changing python when the program is already correctly
indented so far."
Your editor can indent when necessary, and unindent with a keystroke, as you
type. This is the equivalent of your "you write a statement which is
followed by a code block" statement. Cut and paste can automatically put
things as the right indent level (with a python-aware editor, of course). Etc.
Statements that should be aligned that aren't can be fixed. If you have four
lines under your "if" with slightly varying indents but all indented
relative to the "if", then this is trivial to fix. (Python might already be
happy with that one, actually.)
The only failure is when you have something that should be indented relative
to a line above it somewhere but it isn't. This is precisely analogous to
having the wrong number of closing braces. Asking for this to be fixed
automatically is identical to asking for C code with too many closing braces
to get fixed automatically. You can't do it, because you don't know how
indented it is *supposed* to be, just like you don't know which closing
brace is the one that ought be removed. (I'm sure you've encountered this
at least once. :-)
Indeed, I wouldn't be surprised if it was trivial to program a python editor
that } at the start of a line translates to a dedent. :-)
> Every time you write a statement which is followed by a code block (even
> if it's an empty one in rare cases), such as a for-loop, the editor could
> automatically add the '{' and '}' characters and indent the code such that
> you can just keep typing the contents of the loop.
Lots of HTML editors do this too.
> A lesser variation of that would be that every time you write a '{' the
> editor automatically adds (and indents) a '}'. The editor could actually
> constantly keep matching braces auto-indented, even if one of the pair is
> changed somehow (most editors, including emacs, can highlight matching
> braces, so it shouldn't be a problem to auto-indent them as well).
Yep. Visual Studio does this.
Python doesn't need to. ;-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>> So you are saying that the programming language is no good unless it
>> allows production code to be floated around on blogs?
>
> No, I'm saying that using whitespace as syntax is a bad idea.
So is lower case letters, because EBCDIC doesn't support that. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Jim Charter <jrc### [at] msncom> wrote:
> >> So you are saying that the programming language is no good unless it
> >> allows production code to be floated around on blogs?
> >
> > No, I'm saying that using whitespace as syntax is a bad idea.
> So is lower case letters, because EBCDIC doesn't support that. :-)
Yeah, I see how EBCDIC is as popular as html.
(Besides, EBCDIC does support lowercase letters.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
