> IDEs are only really useful for OO languages.

I do not agree.

> You know, you have a
> variable holding an instance of a class, then you type "." and get a
> list of methods available... no such thing in functional programming
> where the order is reversed: you have a function and want to apply
> arguments to it. You may list arguments that match that function
> definition and you may even know their types (assuming "intellisense"
> got type inference), but most likely you're not directly applying those
> arguments to the function, but applying some other function to it first.
> It sounds too much of hassle to use "intellisense" in those situations...

Did you know that there's a program called Djinn which can take any 
Haskell type signature and generate Haskell source code for it, if it's 
possible to write it without recursion?

Of course, there's usually more than one possible expression for a given 
type signature. So the code you get may well not be the code you 
actually wanted. But still, it's interesting that just a type signature 
is sometimes enough to generate useful, runnable code. (Try doing /that/ 
in a normal programming language...)

> I fear IDEs are really only useful at getting away with lesser
> languages' weaknesses
>
> so, all that would seem to rest of usefulness for an IDE is project
> management.

I do not agree.

Consider the things that a typical IDE does:

- Syntax highlighting. Bracket pairing.

- Generate parts of an expression as you type. (E.g., generate the 
matching close bracket, generate the "then" and "else" keywords when you 
type "if".)

- Highlight any syntax errors, mismatched brackets, unused variables.

- Allow you to compile the whole project with one keypress.

- Highlight the line of source code that the compiler is complaining about.

- Display a summary of what entities are defined in each file, what 
their types are, whether they're public or private, etc.

- Let you navigate to each entity in the list.

- Run the document extraction tool.

- Take you to the documentation for a given entity (regardless of 
whether its in your project or an installed 3rd party library).

- Easily launch your application.

- Run your test suite and log the results.

- Integrate with your source control system. Show interactive diffs. 
Show the history tree. Manage commits and reverts and branches.

- Integrate with the debugger. Let you single-step through your code. 
Let you create watches, inspect variables in scope, drill down through 
complex data structures.

Tell me, how do any of these things stop being useful if your 
programming language isn't object-oriented?

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    It can be argued using the same logic as with uninitialized variables,
> > though: There are situations where execution never reaches the end of the
> > function, and hence having a 'return' statement there would be useless.

> Sure. But like I said, the Java compiler seems to detect this.

  But the C++ compiler cannot break the standard by making the situation
an error. It can only issue a warning.

  (And besides, any kind of detection of this cannot be 100% accurate,
as the problem "will this line of code ever be reached?" is unsolvable
in the general case.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> The benefit of class over a simple struct/collection is in the
> private/protected parts, and the mandatory centralisation of the
> prototypes of all related functions (until you start playing with
> friend, but that's another story).

  Well, classes also support inheritance and dynamic binding, which
is sometimes useful.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hey Warp, you ever think about writing a book? I bet you could do a 
> better job than this idiot...

  There already exist good books.

  If you want to read something actually useful about C++, try the
"Effective" book series by Scott Meyers (or at the very least "Effective
C++" and "More Effective C++"). They actually contain some competent and
easy to understand information.

  "Effetive STL" is probably also good.

-- 
                                                          - Warp

Post a reply to this message

On 18/04/2012 12:13 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>>     It can be argued using the same logic as with uninitialized variables,
>>> though: There are situations where execution never reaches the end of the
>>> function, and hence having a 'return' statement there would be useless.
>
>> Sure. But like I said, the Java compiler seems to detect this.
>
>    But the C++ compiler cannot break the standard by making the situation
> an error. It can only issue a warning.

Sure. I understand that. The problem is that the standard requires this 
to be permissible. I was just pointing out that "because it's impossible 
to detect" is not a valid reason for the standard being written this 
way. (Backwards compatibility is, of course.)

>    (And besides, any kind of detection of this cannot be 100% accurate,
> as the problem "will this line of code ever be reached?" is unsolvable
> in the general case.)

Sure.

Post a reply to this message

On 18/04/2012 12:17 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Hey Warp, you ever think about writing a book? I bet you could do a
>> better job than this idiot...
>
>    There already exist good books.

Well, I guess.

>    If you want to read something actually useful about C++, try the
> "Effective" book series by Scott Meyers (or at the very least "Effective
> C++" and "More Effective C++"). They actually contain some competent and
> easy to understand information.
>
>    "Effetive STL" is probably also good.

Noted.

(Basically the only reason I'm persisting with this poorly written and 
probably outdated text is that we've already bought it. But I'm thinking 
it might be better to just save myself the trouble and go read a real 
explanation...)

Post a reply to this message

Invisible escreveu:
>> IDEs are only really useful for OO languages.
> 
> I do not agree.
> 
>> You know, you have a
>> variable holding an instance of a class, then you type "." and get a
>> list of methods available... no such thing in functional programming
>> where the order is reversed: you have a function and want to apply
>> arguments to it. You may list arguments that match that function
>> definition and you may even know their types (assuming "intellisense"
>> got type inference), but most likely you're not directly applying those
>> arguments to the function, but applying some other function to it first.
>> It sounds too much of hassle to use "intellisense" in those situations...
> 
> Did you know that there's a program called Djinn which can take any 
> Haskell type signature and generate Haskell source code for it, if it's 
> possible to write it without recursion?
> 
> Of course, there's usually more than one possible expression for a given 
> type signature. So the code you get may well not be the code you 
> actually wanted. But still, it's interesting that just a type signature 
> is sometimes enough to generate useful, runnable code. (Try doing /that/ 
> in a normal programming language...)

AFAIK, the hindley-milner type system is turing complete, so it's not 
surprising at all.  So, if you want you may indeed just provide 
mind-boggling complex types and let djinn extract the program behaviour 
from that, just as a C++ programmer can go overkill and write with 
templates a compile-time lisp interpreter and run factorial 100 on it 
and just output 
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

at run-time.

It's all feasible, just not very useful.

>> I fear IDEs are really only useful at getting away with lesser
>> languages' weaknesses
>>
>> so, all that would seem to rest of usefulness for an IDE is project
>> management.
> 
> I do not agree.
> 
> Consider the things that a typical IDE does:
> 
> - Syntax highlighting. Bracket pairing.
> 
> - Generate parts of an expression as you type. (E.g., generate the 
> matching close bracket, generate the "then" and "else" keywords when you 
> type "if".)

all common features of the most featureless text editors out there 
besides scumbag notepad.

> - Highlight any syntax errors, mismatched brackets, unused variables.

that requires a bit more working, specially unused variables. 
Mismatched brackets is a (mis)feature of languages that are not lisp. ;)

> - Allow you to compile the whole project with one keypress.

that's only useful for languages still in the old edit-compile-test 
cycle... ;)

in any case, even humble C can do that, provided a Makefile is ready. 
heck, Makefiles are language-agnostic even...

> - Highlight the line of source code that the compiler is complaining about.

emacs and vim both allow that kind of integration with external tools 
such as compilers... I'm sure other featureful text editors too.

> - Display a summary of what entities are defined in each file, what 
> their types are, whether they're public or private, etc.

For C/C++ that's as easy as simply taking a look at each header file. :)

> - Let you navigate to each entity in the list.

ever heard of exhuberant C-tags?  I'm sure it got support for haskell 
too, and is such a tool that generates for a codebase a tags file and 
lets you navigate through source code using those tags.  Support for it 
in both emacs and vim at least.

> - Run the document extraction tool.

what's wrong with man? ;)

> - Take you to the documentation for a given entity (regardless of 
> whether its in your project or an installed 3rd party library).
> 
> - Easily launch your application.

like ./out ?

> - Run your test suite and log the results.

like ./test > log.txt ?

> - Integrate with your source control system. Show interactive diffs. 
> Show the history tree. Manage commits and reverts and branches.

well, I'm stopping now.  It's clear you're just a button masher who 
enjoys mashing buttons than simply harnessing from an integrated textual 
development environment.

> - Integrate with the debugger. Let you single-step through your code. 
> Let you create watches, inspect variables in scope, drill down through 
> complex data structures.

you are not even talking like a haskeller anymore!  Is there such a 
haskell debugger?  Last time I heard, debugging and lazy evaluation were 
at odds...

> Tell me, how do any of these things stop being useful if your 
> programming language isn't object-oriented?

They are all very useful and none requiring a bloated and costly IDE. 
Intellisense is the only really thing useful in such IDEs, and, like I 
said, it's only really useful for OO languages.

Post a reply to this message

>> Did you know that there's a program called Djinn which can take any
>> Haskell type signature and generate Haskell source code for it, if
>> it's possible to write it without recursion?
>
> AFAIK, the hindley-milner type system is turing complete, so it's not
> surprising at all.

Basic Hindley-Milner isn't Turing-complete, no. Add a few extensions and 
it can be /made/ Turing-complete, however.

> So, if you want you may indeed just provide
> mind-boggling complex types and let djinn extract the program behaviour
> from that, just as a C++ programmer can go overkill and write with
> templates a compile-time lisp interpreter
>
> It's all feasible, just not very useful.

Not really.

Suppose I have two Maybe values, and I want a utility function to pick 
the first one which has a value in it. I run Djinn and say

   select ? Maybe x -> Maybe x -> Maybe x

It immediately replies

   select a b =
     case a of
       Nothing -> b
       Just c  -> Just c

which is the correct way to do this. (Although ever so slightly more 
verbose than necessary.)

Now actually there are /several/ possible functions with this type 
signature, and in a sense it's just a fluke that Djinn happens to have 
picked the one I wanted. However, this is not exactly a "mind-boggling 
complex type". Actually it's a pretty damned /simple/ type. :-P

So far I've fed all sorts of stuff into Djinn, and mostly it produces 
the code I wanted. The killer limitation is that it can't handle 
recursion. You can't have recursive types, you can't generate recursive 
code. That's a pretty big limitation. But for simple boilerplate that 
just involves lots of type conversions, it works great!

>> - Allow you to compile the whole project with one keypress.
>
> that's only useful for languages still in the old edit-compile-test
> cycle... ;)

Compiling a program is a useful way to check for errors, even if you 
don't intend to actually /run/ it. (Well, it is if you aren't coding in 
C anyway...)

> in any case, even humble C can do that, provided a Makefile is ready.
> heck, Makefiles are language-agnostic even...

Makefiles only work on Unix. :-P But hey, you can write a simple script 
to build your project under Windows.

The /real/ problem, of course, is that you have to open a command 
window, CD to the right folder, and type in "make program1" or whatever. 
This takes significantly longer than pressing F7 (or whatever).

Heck, KDevelop lets you have the terminal window embedded right there in 
the text editor, and it /still/ takes longer switching back and forth 
between windows than it would to just jab a key.

>> - Display a summary of what entities are defined in each file, what
>> their types are, whether they're public or private, etc.
>
> For C/C++ that's as easy as simply taking a look at each header file. :)

...and skipping over all the preprocessor directives, comments, inline 
functions, and other cruft. :-P

>> - Let you navigate to each entity in the list.
>
> ever heard of exhuberant C-tags?

What are "tags"?

>> - Run the document extraction tool.
>
> what's wrong with man? ;)

Oh Jesus, where do I even *start* with that??

>> - Easily launch your application.
>
> like ./out ?

Sure, once you take your hands off the keyboard and onto the mouse to 
switch from the text editor window to the command prompt window. :-P

> well, I'm stopping now.

...that's not what it looks like from here. ;-)

>> - Integrate with the debugger. Let you single-step through your code.
>> Let you create watches, inspect variables in scope, drill down through
>> complex data structures.
>
> you are not even talking like a haskeller anymore! Is there such a
> haskell debugger?

Yes, there is. OK, it doesn't actually /frigging work properly/, but it 
exists. And has a horrifyingly bad UI, BTW. Mainly because trying to do 
interactive program exploration using a CLI is really unintuitive.

>> Tell me, how do any of these things stop being useful if your
>> programming language isn't object-oriented?
>
> They are all very useful and none requiring a bloated and costly IDE.
> Intellisense is the only really thing useful in such IDEs, and, like I
> said, it's only really useful for OO languages.

Bloated I'll give you. But costly? Do you have any idea how many free 
IDEs there are?

Basically, what you've just said is "you can recreate some of the 
features of an /integrated/ development environment by manually linking 
tools together yourself". Sure, you can, it's just harder.

For the most part, I use a non-integrated development environment when 
I'm coding Haskell. That doesn't mean I don't see the value in something 
like Leksah.

An IDE is way, way more than just code completion.

Post a reply to this message

>> in any case, even humble C can do that, provided a Makefile is ready.
>> heck, Makefiles are language-agnostic even...
>
> Makefiles only work on Unix. :-P But hey, you can write a simple script
> to build your project under Windows.

WAT?

http://gnuwin32.sourceforge.net/packages/make.htm
http://msdn.microsoft.com/en-us/library/dd9y37ha%28VS.71%29.aspx

>
> The /real/ problem, of course, is that you have to open a command
> window, CD to the right folder, and type in "make program1" or whatever.
> This takes significantly longer than pressing F7 (or whatever).
>

Which you only have to do once... After that you only need to hit 
ALT-TAB and the up arrow.

> Heck, KDevelop lets you have the terminal window embedded right there in
> the text editor, and it /still/ takes longer switching back and forth
> between windows than it would to just jab a key.
>

Starting notepad++ and a command prompt take significantly less time 
than starting any IDE.  So you still have quite a few 
"F7-is-faster-than-alt-tab" to do before you catch up...

>>> - Easily launch your application.
>>
>> like ./out ?
>
> Sure, once you take your hands off the keyboard and onto the mouse to
> switch from the text editor window to the command prompt window. :-P
>

As mentioned previously,  ALT-TAB.  Much faster - and a lot easier on 
your elbow and shoulder tendons - than lifting your right hand going 
over the numeric keypad and using the mouse.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>> in any case, even humble C can do that, provided a Makefile is ready.
>>> heck, Makefiles are language-agnostic even...
>>
>> Makefiles only work on Unix. :-P But hey, you can write a simple script
>> to build your project under Windows.
>
> WAT?

To tell you the truth, I don't even /like/ Make all that much. (I think 
it's the tab characters. Or the slightly clunky way it deals with 
targets that aren't files.) I only really use it for building C, because 
it's either that or work out how to invoke the compiler manually...

But as I say, a tiny amount of shell scripting will automate most tasks, 
without the need for Make.

>> The /real/ problem, of course, is that you have to open a command
>> window, CD to the right folder, and type in "make program1" or whatever.
>> This takes significantly longer than pressing F7 (or whatever).
>
> Which you only have to do once... After that you only need to hit
> ALT-TAB and the up arrow.

That works great - /until/ your command history has more than one 
command in it. E.g., if you use the same window to run the compiler, run 
the main program, and control your SCM. Then you end up jabbing up-arrow 
endlessly, or executing the wrong command, or both. Very annoying.

(I wonder why nobody has yet thought of making an editor where you can 
add buttons to the toolbar and kind arbitrary commands to them? You 
could even give them keyboard shortcuts...)

> Starting notepad++ and a command prompt take significantly less time
> than starting any IDE.

Depends on the IDE. Some are slower than others. I do take your point 
though - some of them do take an absurd amount of time to start. Then 
again, "you only do that once". :-P

>> Sure, once you take your hands off the keyboard and onto the mouse to
>> switch from the text editor window to the command prompt window. :-P
>>
>
> As mentioned previously, ALT-TAB. Much faster.

And if in the middle of your coding session, you quickly switch to your 
email client to check something, next time you try to use Alt+Tab, it 
takes you to the wrong window.

It sounds trivial, but it's really very, very annoying.

(It becomes even more fun when what you're working on involves more 
windows. E.g., right now I'm writing some TeX, so I have my text editor 
open, my command window open, and my DVI window open. You can 100% 
guarantee that almost every time I change window I change to the wrong 
one...)

Post a reply to this message