![](/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) |
>>> 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
|
![](/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:
> 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.
Where *else* would you need to increase the indentation?
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:
> 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
|
![](/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:
> Warp wrote:
> > 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.
> 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
|
![](/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:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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'
![image1.png](/povray.off-topic/attachment/%3C4bcf180b%40news.povray.org%3E/image1.png?preview=1)
|
![](/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:
> 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.
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
|
![](/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:
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |