Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Orchid XP v8 wrote:
>>> make a typo in a C program, the program stops and says "error: 
>>> segmantation fault".
> 
>> *If* you're lucky.  What's worse is when it *doesn't*. :-)
> 
>   You seriously claiming that if you make a typo in Haskell, it always
> magically knows that and gives you an error message?

Me? No.

I'm saying you're lucky if when you make a mistake in C you get a segfault. 
If you're unlucky, you clobber some random unrelated variable that *is* 
allocated and things progress as normal except with totally undefined results.

If you make a mistake in Haskell such that the results are undefined, it 
stops in a way that's probably pretty easy to debug compared to a segfault in C.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Orchid XP v8 wrote:
> > C and C++ have debuggers which are actually useable. I'll give you that 
> > one.

> Because they need it, because when something goes wrong you have to step 
> outside the language into a different address space to be able to figure out 
> why. ;-)

  Can you name one language which would not benefit from a debugger (which
you can use, among other things, to insert breakpoints, execute the program
step-by-step and examine the values of all objects at current scope)?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Can you name one language which would not benefit from a debugger (which
> you can use, among other things, to insert breakpoints, execute the program
> step-by-step and examine the values of all objects at current scope)?

I know *I* would like it better if Haskell had a quality debugger.

They say if a Haskell program compiles, it usually works correctly. This 
is true, but note that the phrase is "usually".

(There *is* a debug feature in recent versions of GHC, but it doesn't 
seem to work terribly well. And crawling through a complicated piece of 
program using a CLI interface isn't much fun anyway...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
>   Can you name one language which would not benefit from a debugger (which
> you can use, among other things, to insert breakpoints, execute the program
> step-by-step and examine the values of all objects at current scope)?

No language per se, but environments. :-)

I just try to avoid languages where the primary debugging tools are outside 
the language. (Altho APL is cool, I can't imagine doing a production program 
in a language that needs something like OBSERVE[1], for example.)

I was pretty impressed at how VS lets you put breakpoints in code-behind 
pages so you can single-step a piece of code as it processes a web request, 
which is really a PITA in most of the other web-oriented languages like PHP.

So yeah, of course debuggers are *useful*. Do I want an external program to 
be the *only* way to track down bugs? Nah.  C is useful too. That doesn't 
mean I want C to be the only language I can use.



[1] Since Google is making it hard to find, the "observe" command sets a 
flag that makes each APL statement print the line it's running, puts a 
carret under the current operator it's evaluating, prints out both 
arguments, and then the result, essentially single-stepping the evaluation 
of a single expression with copious output.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>>>     ([] , _  ) -> Nothing
>>
>> Yeh, it's really clear what this line does to a non-Haskeller :-)
>
> It's pretty standard notation for functional languages. Erlang uses the 
> same notation. If you get a two-element tuple with the first element being 
> an empty list, the result is an arbitrary atomic value (not unlike an 
> "enum") called "Nothing".

Sure, I didn't doubt there was a pretty easy explanation behind it, it's 
just [], _ and the whole statement syntax had no meaning to me before it was 
explained.  I would imagine once Andrew knew what -- and * does in C (I 
think < and ! are common enough not to need to explain?) he would know what 
the statement he highlighted meant too.  I don't see much difference.

Post a reply to this message

scott wrote:

> Sure, I didn't doubt there was a pretty easy explanation behind it, it's 
> just [], _ and the whole statement syntax had no meaning to me before it 
> was explained.  I would imagine once Andrew knew what -- and * does in C 
> (I think < and ! are common enough not to need to explain?) he would 
> know what the statement he highlighted meant too.  I don't see much 
> difference.

I *already* know that * is pointer dereference and -- is decriment. But 
now I have to sit here and wonder "is that pre-decriment or 
post-decriment? And in why is it 'not (x < y)" rather than 'x >= y'?" 
And similar questions. (Why "for (;;)" rather than "while true"? Is 
there some difference?)

(Also... I just noticed how many one-letter variable names there are. So 
much for that being a bad thing.)

Post a reply to this message

> I *already* know that * is pointer dereference and -- is decriment. But 
> now I have to sit here and wonder "is that pre-decriment or 
> post-decriment?

Like I have to sit and wonder why it's (suffix,prefix) and not 
(prefix,suffix) in your example?

> And in why is it 'not (x < y)" rather than 'x >= y'?"

Aren't they the same? (btw the only reason I can see that you would use the 
first one is if the types being used don't have the >= operator defined). 
IIRC quite a lot of functions and libraries only assume that one of those 
operators is implemented, so that's probably why you'll see stuff like that.

> And similar questions. (Why "for (;;)" rather than "while true"? Is there 
> some difference?)

Not that I'm aware of.

Post a reply to this message

>> I *already* know that * is pointer dereference and -- is decriment. 
>> But now I have to sit here and wonder "is that pre-decriment or 
>> post-decriment?
> 
> Like I have to sit and wonder why it's (suffix,prefix) and not 
> (prefix,suffix) in your example?

No specific reason. I probably did it that way around because "split" 
takes the list in reverse order. (Working from the back towards the 
front is inefficient for a single-linked list, so I reversed the list so 
it can be processed from front to back instead.) Technically you could 
return the sublists either way around if you wanted. I just did it this 
way because if you take (x, y) and do x ++ y, you get the original 
(backwards) list. If you'd returned the components the other way around, 
you'd have to do y ++ x instead.

>> And in why is it 'not (x < y)" rather than 'x >= y'?"
> 
> Aren't they the same?

You'd certainly think so.

> (btw the only reason I can see that you would use 
> the first one is if the types being used don't have the >= operator 
> defined). IIRC quite a lot of functions and libraries only assume that 
> one of those operators is implemented, so that's probably why you'll see 
> stuff like that.

Hmm, I see.

Of course, we're working with *digits* here, for which both operators 
are definitely defined. However, it seems this part of the code is from 
a library, so presumably it's supposed to work with anything.

(In Haskell, it is impossible to define one ordering relation without 
also defining the others. Well, no, not impossible, but you'd have to 
purposely go out of your way to do it. So in Haskell it's not something 
a library needs to worry about it. But now I recall that in C++, these 
are all seperate, notionally unrelated operators.)

>> And similar questions. (Why "for (;;)" rather than "while true"? Is 
>> there some difference?)
> 
> Not that I'm aware of.

It's like when a Haskell programmer writes a new function that's 
equivilent to an existing one. You have to sit there and wonder why they 
did that. Was it personal taste, or is there actually some subtle 
difference you've missed?

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > And in why is it 'not (x < y)" rather than 'x >= y'?"

> Aren't they the same? (btw the only reason I can see that you would use the 
> first one is if the types being used don't have the >= operator defined). 
> IIRC quite a lot of functions and libraries only assume that one of those 
> operators is implemented, so that's probably why you'll see stuff like that.

  It is customary in the C++ standard library to demand as little as
possible from the types being handled. Anything requiring comparison of
element usually demands only operator< from the elements (if the algorithm
can be feasibly be implemented using that operator only).

  If you are making a generic algorithm or data container which compares
elements, it's also usually a good idea to demand as little as possible
from it, and stick to operator< exclusively, if possible.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> from it, and stick to operator< exclusively, if possible.

And other than readability, compilers these days are smart enough to 
generate the same optimal[1] code for it regardless.

[1] Funny how "optimized" no longer means what it used to, isn't it?

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message