 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> printf() - obviously.
>
> Any operation involving strings seems to require you to use functions
> with names like "strnmsx" or something. (What, you couldn't afford a few
> more octets for some extra letters?)
When C just started, function names were actually quite limited.
Nowadays, we just abbreviate for the hell of it :P
> Manual memory management is tricky in any language, but at least in
> (say) Pascal, strings are managed for you. And let's face it, strings
> are *the* most common reason for using variable-sized arrays.
In C++, there is a string class that manages most stuff for you.
string a = "foo", b = "bar";
string c = a + b;
> I spent about 3 days trying to figure out the syntax for making function
> pointers work. After endless segfaults, I just gave up. It was too hard.
Function pointers are far from an easy feature.
> 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.
Any good compiler will warn about it; at least if you explicitly ask for it
(it's annoying when the if(x=5) is intentional and you can't make the
compiler shut up about it, a common workaround is if ((x = 5)) which looks
kind of ugly)
> Boolean operators and bitwise operators. Which is which? Which ones are
> the short-circuit ones, and which aren't? I can never remember.
Think of bitwise operators as arithmetic operations.
int foo = 0 * func()
Would it be sane not to execute func() for its side effects just because the
expression is already 0 and it wouldn't change anything? I don't think so.
So the same happens for bitwise operators, they don't short-circuit.
if (foo != NULL && !foo->items.empty() && foo->items[0].isValid())
If foo is null, the first part of the expression is false. If the second
part is ran anyway, your program crashes (null pointer deference).
If foo->items is empty, the second part of the expression is false. If the
third part is ran anyway, your program may crash, or read random data from
memory, or behave unexpectedly (reading off bounds of a standard container
without bounds-checking is the same as reading off array bounds).
You *want* short-circuiting :)
> What's the difference between #include "" and include <>?
I'm not *completely* sure. I think "" searches in the current directory and
other directories listed in the compiler's include path (-I in Unix), while
<> searches in the system include path (/usr/include). So you'd use "" for
your own headers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Nicolas Alvarez <nic### [at] gmail com> wrote:
>> I think it was Linus Torvalds who said:
>
>> "It's like that while(*p++ = *q++) strcpy code. It works, sure, but it's
>> the worst code in the world."
>
> I wouldn't put too much weight on what Torvalds thinks is good code and
> bad code.
Neither me, but that quote was amusing.
And I might be wrong and it wasn't him who said it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I guess it works differently with a real OS. I've only ever compiled C
> code under MS-DOS, and there you don't get "segfaults"
MS-DOS has no memory protection at all. If you write into address 0x0000,
you might overwrite the operating system.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:32, Gail wrote:
>
> "andrel" <a_l### [at] hotmailcom> wrote in message
> news:48C### [at] hotmailcom...
>
>>
>> The ij is originally 'ii' with the second 'i' notifying that it is a
>> long vowel. Nowadays it is a single glyph (unless you are using
>> American software). The sound changed in the area where the official
>> dutch originates to be the same as the 'ei' 'vowel'.
>
> Afrikaans has the 'ji' construct, usually as part of the diminutive
> suffix 'tjie', but in other places too
we have 'je' or 'ie' as diminutibe also but the latter is spoken
language. I never realized that the 'ij' combined vowel would surprise
other people. You would than probably find the translation of '*you*'
even more strange: 'jij'. I immediately parse it as j-ij but if you see
it as j-i-j it may look strange.
>
>>> Die taal is maklik vergelyk its soos Zoeloe.
>>
>> Het blijft leuk om een taal van de andere kant van de wereld te zien
>> die je gewoon kan lezen. Al moet ik zeggen dat als iemand het spreekt
>> het meer dan een paar seconden kost om het te vertalen en ik dus elke
>> keer de draad kwijtraak.
>
> I'm gonna have to ask for a translation of that. Lost in the 2nd sentance.
> My afrikaans isn't as good as I made it out to be.
"I still find it interesting (lit. 'fun' but that does not cover the
meaning) to see a language from the other side of the world and still
being able to read it. I'll have to say that when somebody speaks it it
takes more than a few seconds to translate so I loose it (the thread?)
every time."
>>
>> BTW Gail, somewhere in october I will hear if there is a change to
>> visit SA in 2015. There is also a change that we will be involved in
>> preparations for that and be there in februari or so...
>
> Feb next year? Cool. It's a good time of the year to visit, if you like
> hot weather.
I absolutely hate it. I really do. Everything over 24 Celsius makes me
feel bad. At least here, in Brazil I managed, to my own great surprise.
> Joburg, Cape
both
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:01, Vincent Le Chevalier wrote:
> andrel a écrit :
>> On 12-Sep-08 21:14, Vincent Le Chevalier wrote:
>>> There is also a similarity between the behaviours of positive
>>> integers, multiplication and addition, and booleans, AND and OR. That
>>> is:
>>>
>>> Integers Booleans
>>> a*(b+c) = a*b + a*c a AND (b OR c) = (a AND b) OR (a AND c)
>>> 0 + a = a false OR a = a
>>> 0 * a = 0 false AND a = false
>>> if a>0, a+b>0 for all b if a is true, a OR b is true for all b
>>> And so on...
>>>
>>> It does not work out that well if you set true <-> 0.
>>>
>> If you take
>> true <-> 0
>> false <-> 1
>> OR <-> *
>> AND <-> +
>> it works again.
>
> No, it's not as perfect. For example the equality:
> (a AND b) OR (a AND c) = a AND (b OR c)
>
> would translate as:
> (a+b) * (a+c) = a*a + a*b + a*c + b*c
> = a * (1+b+c) + b*c
> != a + b*c
>
> because 1+b+c is not equal to 1 in all cases.
I think that should have been a+b+c. Anyway, the same argument could be
given for (a OR b) AND (a OR c) = a OR (b AND C) in the standard
interpretation.
>
> I agree it works in the boolean sense, that is if one side is zero, the
> other is too. But you do not have the equality that you have in the
> other approach.
>
> I'm nearly sure there is a deeper reason for that but I can't think of
> it right now.
Both interpretations should be interchangeable because of de Morgan's
law. I hope that is deep enough for you. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
> Both interpretations should be interchangeable because of de Morgan's
> law. I hope that is deep enough for you. ;)
Quite so :-) You've just shown me I had never given a good thought about
that... Funny how these things become so ingrained... I actually have a
hard time switching back and forth between the interpretations, I'll
have to train :-D
Thanks!
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:04, Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> scott wrote:
>
>>> 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.
Which really is simply because it is not taught at school. There is no
reason for that other than tradition. Trust me, it can be learned and be
as natural as Boolean algebra, base eight
(http://jp.youtube.com/watch?v=a81YvrV7Vv8) or finite state machines,
none of which is taught at highschool nowadays (anymore*).
* The Tom Lehrer song is from 1965 or so.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mueen Nawaz <m.n### [at] ieeeorg> wrote:
>> Warp wrote:
>>> The difference is that it will use a hash table rather than a binary tree.
>
>> I mistakenly thought the current map already did that...
>
> It's impossible to use a hash table and get the elements in increasing
> order with a linear traversal. (Ok, it *is* possible, but then you get an
> extremely inefficient hash table.)
>
>> So the onus of coming up with a function will be on the user?
>
> It's impossible to provide good (or even working) hash functions for
> all possible user-defined types.
>
>> Will it provide some defaults?
>
> I don't know.
Well, I was comparing this all with python dicts. It uses a hashing
function, and does not guarantee any particular order (no attempts of
returning in any sorted manner). The catch is that the key must be
either an number or a string.
I had assumed maps also used hashing function.
So I was just wondering if hashmaps may provide some function for
"common" use cases...
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The long and short is, I spent several months at college using C, and I
> always round it excrusiatingly difficult to get any of the programs to
> work properly. Unfortunately that's just the way C is designed; nothing
> is checked, the programmer is assumed to know exactly what they're
> doing, and if the programmer does something wrong... well that's just
> too bad.
I thought we were talking about C++.
> In C, just concatinating two strings is an ugly, complex operation. In
> fact, it seems to be easier to just write one string to stdout and then
> write the other, rather than trying to actually concatinate them. The
> language seems to make every tiny little operation really awkward and
> difficult. No thanks...
>
> Still, since I am the *only* person on the entire news server who thinks
> this, I guess I should just let it go.
Yes, but how much fun was Haskell 10 years ago? You're looking at the
state of the wrong language at the wrong time. Do you not think it has
been refined since then?
And besides, in C you have the STL which makes such operations somewhat
easier. Not as nice as C++, perhaps, but more manageable.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
