>>> I really don't understand why you find it so hard to learn C.
> 
>> (I really don't understand why everybody else finds it so hard to learn 
>> Haskell, but there we are.)
> 
>   Because Haskell is not imperative and doesn't use modules. Haskell uses
> a paradigm which does not correspond to how normal people think.

Doesn't use modules? What on earth do you mean by that?

>   (Of course it doesn't help that 90% of the keywords and standard library
> function names are obfuscated.

I would suggest that 90% is an exaggeration. Truly, there *are* some 
pretty dumb name choices in there. (What the hell is "Ix" supposed to 
mean? Would an extra 3 characters really kill you?) Some of the 
heavily-used string functions have less-than-helpful names. (You called 
it "nub"? Is that even in the dictionary? What's wrong with "unique"?) 
But mostly it's actually not too bad.

> Sometimes the names are obscure because the
> concept behind them is so obscure.

The only example that springs to bind is "fold". Oh, or perhaps the 
wonderfully-named ">>=" operator...

> Other times it's simply this weird
> obsession Haskell people have with writing code which is as short as
> possible, even at the cost of clarity.)

Now if this isn't pure trolling, I don't know what is. :-P

>   Have you looked at the standard library function names in haskell
> recently?

Actually, no. I don't know what's in the Haskell standard libraries. I 
just type stuff at random, and it somehow works. ;-)

>   (Besides, if you want easy string manipulation, use C++, not C.)

Right. I think we've established that this works better in C++ (which, 
you'll remember, I've never tried using).

>> I spent about 3 days trying to figure out the syntax for making function 
>> pointers work.
> 
>   I can't even begin to imagine what do you need function pointers for,
> as a C beginner programmer.

FRACTINT uses them fairly heavily. (It's basically OOP, without the 
language support.) I guess if you wrote FRACTINT today, you'd use C++ 
and it would be way easier...

>> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but I 
>> can never ever remember which - and it's kind of important!
> 
>   You have a ridiculously bad memory if you can't remember such a trivial
> thing.

Did you know I also sometimes get left and right mixed up?

>> What insane nutcase thought that making assignment an expression as a 
>> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..." 
>> then my program will silently fail to work correctly, and I'll probably 
>> spend hours if not days trying to figure out why.
> 
>   Use a proper compiler.

How does that help?

>> Boolean operators and bitwise operators. Which is which? Which ones are 
>> the short-circuit ones, and which aren't? I can never remember.
> 
>   Says the person who has probably memorized over half of the most
> obscure functions and tricks in haskell.

In Haskell, 1) you don't need the non-shortcut versions at all, and 2) 
if you use a bitwise operator where a Boolean operator is expected (or 
vice versa), you'll get a compile-time error telling you of your 
mistake. (But then, the bitwise operators are in a special library that 
you have to manually import, whereas the logic ops are imported by 
default...)

>> What's the difference between #include "" and include <>?
> 
>   Does it matter?

I don't know - that would depend on what this answer is, wouldn't it? ;-)

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

Post a reply to this message