On 17/04/2012 08:51 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I'm still a bit baffled that this is a valid thing to do, however...
>
>    There's some baggage from C that would have better been dropped, but
> as you may know, backwards compatibility can be a real b***h sometimes...

Don't we all know it. ;-)

(Haskell isn't as ancient as C, so fortunately it has much less of this. 
It /does/ have it, however...)

>    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. If 
doesn't just look at a function and say "does it contain a return 
statement somewhere?" It actually statically analyses every possible 
flow of control, and checks that every individual one ends with a return 
(or throws an exception, which is also a valid way to terminate a function).

Of course, it's not perfect. Plausibly you could have if branches such 
that a particular sequence of branches is impossible due to the 
conditions in those branches, but the compiler wouldn't "see" that and 
would still insist that you have a branch that doesn't terminate 
properly. But I haven't seen that happen yet.

Post a reply to this message

On 18/04/2012 07:24 AM, Le_Forgeron wrote:
> Le 17/04/2012 14:13, Invisible a écrit :
>> Obviously this /isn't/ what's so special about classes. The /actual/
>> benefits don't appear to be mentioned.
>
> 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.

Indeed. Anybody who knows any OO theory will understand this. But, 
unfortunately, anyone who reads this book will have no idea.

Hey Warp, you ever think about writing a book? I bet you could do a 
better job than this idiot...

Post a reply to this message

> 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