|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |