 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Mmm, and you think any sane Haskell programmer would implement the
> Fibonaci numbers that way in a real program? It's an interesting
> teaching example, but seriously, if you *want* Fibonacci numbers for
Thank you for repeating what I've said a few times already. The ugly
C/C++ code you're accustomed to are also "interesting teaching
examples". They teach you all that stuff with pointers and character
arrays because they want to make sure the students understand how things
work in a computer (and for good reason). It's not how programmers do
stuff typically.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> And besides, in C you have the STL which makes such operations somewhat
> easier. Not as nice as C++, perhaps, but more manageable.
How can you have a standard template library in C, given that C has
absolutely no support for templates?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> 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", you get "my
> program does something really weird which may even require me to reboot
> the whole PC to fix".
So let me get this straight: You are comparing C in a 10+ years old MS-DOS
system to higher-level programming languages (such as Java and Haskell) in
modern systems with modern OSes and modern compilers, and based on this you
have decided that C sucks?
(Don't get me wrong: C does suck. It's just that your comparison is not
completely fair.)
> >> Ditto for EOF
> >
> > You mean reaching the end of the file is such a fatal error, that the
> > program must be terminated with an exception?
> Well, it beats producing random garbage, surely?
Since when has the EOF value been "random garbage"? In standard C the EOF
value is -1 (integer, not char), and a file read past the end of file will
always return -1. How is that "random garbage"?
Besides, reaching the end of file (and getting that -1) is *not* an error.
It's a completely normal situation which all programs reading files have to
handle. How do you even detect the end of a file without a normal EOF
situation? If reaching the end of the file would cause a fatal error which
terminates the program, that would mean 90% of programs out there would not
work.
Sure, some programming languages might have libraries or other systems
which signal the program the end of file in some other ways, but it's still
not an error to reach the end of the file.
> >> array index out of bounds
> >
> > Unless you use a proper debugger.
> I've never seen a C debugger.
Thus you base all your prejudices on non-knowledge.
> Nor would I know where to find one.
Any decent compiler will have one.
> >> (And you don't have to memorise whether 0 is true or false.
> >
> > I see how that's such a hard thing to memorize.
> There are two possibilities which are apparently equally valid. It's
> very difficult to remember which one of them was arbitrarily selected by
> the language designers.
Luckily haskell doesn't have any arbitrarily selected features in it
which you need to memorize (such as for example some function names).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> 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.
What operating system?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> 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?
The compiler warns you that the sentence looks suspicious.
> >> 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.
You missed my point.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> > 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.
Usually no programming languages are taught in normal school (unless
you specialize), but imperative OO languages still correspond better to
how people naturally think of tasks.
People don't think of tasks with recursive mathematical definitions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 9:42, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>>> 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.
<restored context>
>> 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*).
</restored context>
>
> Usually no programming languages are taught in normal school (unless
> you specialize), but imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
>
They do to some extend, about as much as they naturally think in solving
equations*. Much of what we learn at maths and physics is some sort of
formalization of things we do when solving problems. The techniques and
theories we learn at school are just an arbitrary selection of the
available knowledge. Whether something was natural or not has not been a
reason to include something in the curriculum. If the teachers two or
more generations later try to suggest otherwise, they are more trying to
justify themselves than historically accurate.
Actually part of the motivation of the functional programming designers
was that functional programming better matches to mathematics than
imperative programming. More or less the same holds for declarative
languages that are meant to be a formalization of our logic reasoning.
In short: imperative, declarative, and functional programming (etc.) all
are meant to capture (parts of) normal human reasoning. If you think one
is more natural to people than another that mainly shows that you have
more experience in that style than in others.
*Which may be much more than you normally realize.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So let me get this straight: You are comparing C in a 10+ years old MS-DOS
> system to higher-level programming languages (such as Java and Haskell) in
> modern systems with modern OSes and modern compilers, and based on this you
> have decided that C sucks?
As far as I'm aware, C hasn't changed in 20 years, never mind 10.
>>> You mean reaching the end of the file is such a fatal error, that the
>>> program must be terminated with an exception?
>
>> Well, it beats producing random garbage, surely?
>
> Since when has the EOF value been "random garbage"? In standard C the EOF
> value is -1 (integer, not char), and a file read past the end of file will
> always return -1. How is that "random garbage"?
Really? I had assumed that after you read past the end of the file, it's
behaviour is simply undefined. I wasn't expecting the C standard to
actually bother to define the result of an operation you're not supposed
to perform.
> Besides, reaching the end of file (and getting that -1) is *not* an error.
No, reaching EOF is not an error - failing to check for EOF is an error.
>> I've never seen a C debugger.
>
> Thus you base all your prejudices on non-knowledge.
Yes - because having a debugger would make function names easier to
remember and pointer syntax less baffling and printf() would work
right... oh, wait...
>> Nor would I know where to find one.
>
> Any decent compiler will have one.
I would imagine so, yes.
>> There are two possibilities which are apparently equally valid. It's
>> very difficult to remember which one of them was arbitrarily selected by
>> the language designers.
>
> Luckily haskell doesn't have any arbitrarily selected features in it
> which you need to memorize (such as for example some function names).
Well at least you can easily look up Haskell function names.
Maybe that's part of the problem - I don't have any C programming
resources where I can actually look things up. So if something doesn't
work, there's the Borland C++ help file, or there's experimentation.
Neither of these things help terribly much.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
No, they don't. Generally.
However, people quite often do think in set-based terms. Most people
don't have too much of a problem learning SQL, for example. (Although
having said that, some people insist on processing tasks row by row
rather than using a set-based solution...)
Haskell makes set-based thinking quite easy and natural.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48cb8646$1@news.povray.org...
>
> Maybe that's part of the problem - I don't have any C programming
> resources where I can actually look things up. So if something doesn't
> work, there's the Borland C++ help file, or there's experimentation.
> Neither of these things help terribly much.
>
Such a pity that no free C/C++ language guide exists...
http://www.google.com/search?hl=en&q=C+language+guide
http://www.google.com/search?q=C%2B%2B+language+guide
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48cb8745$1@news.povray.org...
> However, people quite often do think in set-based terms. Most people don't
> have too much of a problem learning SQL, for example.
I beg to differ.
> (Although having said that, some people insist on processing tasks row by
> row rather than using a set-based solution...)
Because they don't understand the set-based way of thinking
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 11:47, Gail wrote:
>
> "Orchid XP v8" <voi### [at] devnull> wrote in message
> news:48cb8646$1@news.povray.org...
>>
>> Maybe that's part of the problem - I don't have any C programming
>> resources where I can actually look things up. So if something doesn't
>> work, there's the Borland C++ help file, or there's experimentation.
>> Neither of these things help terribly much.
>>
>
> Such a pity that no free C/C++ language guide exists...
>
> http://www.google.com/search?hl=en&q=C+language+guide
> http://www.google.com/search?q=C%2B%2B+language+guide
>
> Please note the deliberate sarcasm in the above statement.
<slighly worried>
That's the second day in a row. I hope all goes well with you and your
new job.
</slighly worried>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > So let me get this straight: You are comparing C in a 10+ years old MS-DOS
> > system to higher-level programming languages (such as Java and Haskell) in
> > modern systems with modern OSes and modern compilers, and based on this you
> > have decided that C sucks?
> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
Compilers, tools and operating systems have. Besides, C itself has changed
as well (the latest standard is from 1999).
Or are you telling me this isn't happening with haskell either? If I'm
not mistaken, haskell didn't even have a debugger until recently.
> Really? I had assumed that after you read past the end of the file, it's
> behaviour is simply undefined. I wasn't expecting the C standard to
> actually bother to define the result of an operation you're not supposed
> to perform.
How are you supposed to detect the end of file if you are not supposed
to ever reach the end of the file? That's kind of contradictory.
> > Besides, reaching the end of file (and getting that -1) is *not* an error.
> No, reaching EOF is not an error - failing to check for EOF is an error.
Since reaching EOF is completely valid, how is the compiler supposed to
make sure that you write a conditional which takes it into account? It can't
do this at runtime because returning EOF is completely valid and not an
error, and thus it cannot raise any exceptions at runtime because EOF was
returned. In fact, returning EOF multiple times is not an error either
(it can be perfectly possible for different parts of the program to read
the same file, and all of them get an EOF when there's nothing more to
read, and all of them still work properly).
So how is the compiler supposed to make sure that you do the "correct"
thing when EOF is returned? What *is* the "correct" thing to do?
> >> I've never seen a C debugger.
> >
> > Thus you base all your prejudices on non-knowledge.
> Yes - because having a debugger would make function names easier to
> remember and pointer syntax less baffling and printf() would work
> right... oh, wait...
Now you are twisting the argument, and arguing for the sake of arguing.
The above context had nothing to do with printf or function names.
> > Luckily haskell doesn't have any arbitrarily selected features in it
> > which you need to memorize (such as for example some function names).
> Well at least you can easily look up Haskell function names.
Yes, that's something not possible with C.
> Maybe that's part of the problem - I don't have any C programming
> resources where I can actually look things up.
Well, I don't have any haskell programming resources where I can
look things up.
(Before you write an answer to that, think about it for a second.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
>
> Compilers, tools and operating systems have. Besides, C itself has changed
> as well (the latest standard is from 1999).
My main problem with C is it's design. It isn't *designed* to be "safe"
or "easy", it's designed to be efficient. The result is a language which
offers really minimal assistance to programmers. Crawling through a
program with a debugger hardly compares to having a problem detected at
compile-time before the program even runs.
I'm sure compilers and debuggers have got better over time. But that
doesn't change the fundamental design of the language. It's unsafe by
design, and that causes me endless difficulties.
> Or are you telling me this isn't happening with haskell either? If I'm
> not mistaken, haskell didn't even have a debugger until recently.
(And FWIW, the debugger really isn't that good.)
>> Really? I had assumed that after you read past the end of the file, it's
>> behaviour is simply undefined. I wasn't expecting the C standard to
>> actually bother to define the result of an operation you're not supposed
>> to perform.
>
> How are you supposed to detect the end of file if you are not supposed
> to ever reach the end of the file? That's kind of contradictory.
It's different in every language of course, but what typically happens
is that you have a function that says "is this EOF yet?", and if it is,
you stop reading. And if you don't stop, that's a program bug, and
should be signalled as one.
Apparently in C it's arranged differently.
>>>> I've never seen a C debugger.
>>> Thus you base all your prejudices on non-knowledge.
>
>> Yes - because having a debugger would make function names easier to
>> remember and pointer syntax less baffling and printf() would work
>> right... oh, wait...
>
> Now you are twisting the argument, and arguing for the sake of arguing.
> The above context had nothing to do with printf or function names.
My point is that having a debugger doesn't magically solve all the problems.
>>> Luckily haskell doesn't have any arbitrarily selected features in it
>>> which you need to memorize (such as for example some function names).
>
>> Well at least you can easily look up Haskell function names.
>
> Yes, that's something not possible with C.
It wasn't when I was trying to learn it, no. Today, we have the Internet.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > How are you supposed to detect the end of file if you are not supposed
> > to ever reach the end of the file? That's kind of contradictory.
> It's different in every language of course, but what typically happens
> is that you have a function that says "is this EOF yet?", and if it is,
> you stop reading. And if you don't stop, that's a program bug, and
> should be signalled as one.
I fail to see how that's different from how C does it. You read a value
and check if it was EOF. What's the fundamental difference?
> > Now you are twisting the argument, and arguing for the sake of arguing.
> > The above context had nothing to do with printf or function names.
> My point is that having a debugger doesn't magically solve all the problems.
But it solves many of the problems you are complaining about.
> >> Well at least you can easily look up Haskell function names.
> >
> > Yes, that's something not possible with C.
> It wasn't when I was trying to learn it, no. Today, we have the Internet.
Exactly how is that different from haskell?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mueen Nawaz <m.n### [at] ieeeorg> wrote:
>> And besides, in C you have the STL which makes such operations somewhat
>> easier. Not as nice as C++, perhaps, but more manageable.
>
> How can you have a standard template library in C, given that C has
> absolutely no support for templates?
Good point. But don't they have something similar in function as the
C++ standard library?
--
When you die, you lose a very important part of your life.
-- Brooke Shields
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Good point. But don't they have something similar in function as the
> C++ standard library?
In the standard C library? Nope. The standard C library offers *nothing*
to help the programmer with handling dynamic data (except a few unsafe
string manipulation functions). It also offers no algorithms whatsoever
(except that horrid qsort() function).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous illumina en ce 2008-09-13 03:36 -->
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> 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.
>
> What operating system?
>
MS-DOS, from before Windows 95. You know, a black screen with white text, no
graphical user interface. Everything done from the command prompt.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you see something in the real
world and you think, "Hey! How did they get that effect?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> In the standard C library? Nope. The standard C library offers *nothing*
> to help the programmer with handling dynamic data (except a few unsafe
> string manipulation functions). It also offers no algorithms whatsoever
> (except that horrid qsort() function).
Wow. Crappy.
--
"Cashew?" "Gesundheit!"
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Warp nous illumina en ce 2008-09-13 03:36 -->
>> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>>> MS-DOS has no memory protection at all. If you write into address
>>> 0x0000, you might overwrite the operating system.
>>
>> What operating system?
>>
> MS-DOS, from before Windows 95. You know, a black screen with white text,
> no graphical user interface. Everything done from the command prompt.
I think he's saying MS-DOS doesn't deserve being called an operating
system :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes indeed, and if you look at what he writes about C it is not that he
> has problems with imperative languages in general but with this one for
> particular reasons.
But his reasoning always seems to be based on using some ancient compiler
for 5 minutes 20 years ago. I really don't believe that if he sat down for
an hour with a "learn C" book, he couldn't pick it up. Not given the number
of other more complex languages he's picked up. The mistakes that he always
cites (like printf crashing the machine with beeps etc) are common newbie
mistakes, but nothing that won't be caught by a modern OS/compiler and fixed
with a 1 minute lesson.
> Even after adjusting the grammar (Ik begrijp werkelijk niet waarom u het
> zo hard/moeilijk vindt om C. te leren...) it will still be on the edge of
> comprehensible and not something any Dutchman would write (though I really
> do like the kernverklaringen, we really should introduce that in the
> language).
Hehe, surprising how much of that I could understand given my knowledge of
German ;-) Not that I could write any of it, but reading it was almost ok.
> Language is much more than syntax and grammar. Which was the point I
> wanted to make in the first place.
But with the knowledge of syntax and grammar you can at least make a good
start that will work 99% of the time. It may not be the most efficient or
elegant way, but it will work. Only with experience will you become like a
"native" of the language.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> But his reasoning always seems to be based on using some ancient
> compiler for 5 minutes 20 years ago.
1. It was 10 years ago, not 20.
2. It was 6 months, not 5 minutes.
3. I think this horse is now well and truly dead. ;-)
> I really don't believe that if he
> sat down for an hour with a "learn C" book, he couldn't pick it up.
When I was a lad, I was always hearing about how C was this "ultimate
programming language" and how it was the "most powerful" language and
how BASIC and Pascal were mere toys for amatures. Anyway, when I heard
that next semester we'd be doing C, I took it upon myself to borrow a
book about it from the college library.
Frankly I lost interest when I learned that C doesn't even distinguish
Booleans from integers - but they don't let you pass a module just
because you've lost interest. So when the semester actually started, I
made an effort to learn.
I did eventually get a moderately complex program to work. But basically
every time my program didn't work, I'd replace the implementation with
an equivilent but differently worded one until the program actually
worked. (Presumably my idea of "equivilent" doesn't agree with C's.)
Fortunately, my program involved no string manipulation of any kind. In
fact, about all it did involve was doing calculations and writing pixels
to the screen using Borland's proprietry video API.
> Not given the number of other more complex languages he's picked up.
You are seriously claiming that there are languages which are "more
complex" than C?
> The
> mistakes that he always cites (like printf crashing the machine with
> beeps etc) are common newbie mistakes, but nothing that won't be caught
> by a modern OS/compiler and fixed with a 1 minute lesson.
I gather C++ fixes this anyway.
Given that C++ is supposed to be "like C but better" (or more exactly,
"like C but object-oriented"), this is also a language I took a look at.
My dad has a "learn C++ in 21 days" book. (Given my dad's inumerable
misunderstandings about computer technology, this is quite amusing.) So
one day I sat down and had a look.
The first few chapters look almost exactly like a C tutorial. There's no
printf(), but everything else seems exactly the same. Only much later in
the book does it even start to talk about features I haven't seen
before. It strikes me that this is very probably the wrong way to go
about learning C++.
Anyway, again when I learned that dynamic binding is an extra feature
that you have to manually tern on, I kind of lost interest. (Plus my
head was spinning by the time I'd finished reading about the inner
complexities of pointers vs references, copy constructors, etc.) I'm not
sure if C++ really is this hard or whether the book was just badly
written, but it sure did an efficient job of putting me off.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Anyway, again when I learned that dynamic binding is an extra feature that
> you have to manually tern on, I kind of lost interest. (Plus my head was
> spinning by the time I'd finished reading about the inner complexities of
> pointers vs references, copy constructors, etc.) I'm not sure if C++
> really is this hard or whether the book was just badly written, but it
> sure did an efficient job of putting me off.
Sounds like it tried to cram in too much too soon, something is wrong if you
find yourself wondering about dynamic binding before you understand what
while(*a++=*b++); does! YOu can get a very long way without ever needing to
know about dynamic binding or the detail of how copy constructors work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Anyway, again when I learned that dynamic binding is an extra feature
>> that you have to manually tern on, I kind of lost interest. (Plus my
>> head was spinning by the time I'd finished reading about the inner
>> complexities of pointers vs references, copy constructors, etc.) I'm
>> not sure if C++ really is this hard or whether the book was just badly
>> written, but it sure did an efficient job of putting me off.
>
> Sounds like it tried to cram in too much too soon
Well, it *is* named "learn C++ in 21 days". ;-)
> something is wrong if
> you find yourself wondering about dynamic binding before you understand
> what while(*a++=*b++); does! YOu can get a very long way without ever
> needing to know about dynamic binding or the detail of how copy
> constructors work.
It did seem complex and unecessary. I kept asking myself "why the hell
do I need to care about such things?" At the time, I assumed it was
because C++ is badly designed. From what Warp has said, maybe it was
just that the book was badly designed. It presented the information as
being stuff that every beginner C++ programmer absolutely must know.
From the sound of it, that's not actually the case.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> 3. I think this horse is now well and truly dead. ;-)
That's probably true. You have decided that you have, and will always
have, a strong prejudice against C and C++, and absolutely nothing will
ever convince you otherwise.
> Anyway, again when I learned that dynamic binding is an extra feature
> that you have to manually tern on, I kind of lost interest.
This I simply cannot comprehend.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> My dad has a "learn C++ in 21 days" book. (Given my dad's inumerable
> misunderstandings about computer technology, this is quite amusing.) So
> one day I sat down and had a look.
http://norvig.com/21-days.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I did eventually get a moderately complex program to work. But basically
> every time my program didn't work, I'd replace the implementation with an
> equivilent but differently worded one until the program actually worked.
This is the sort of thing I was referring to when I said you need to know
what you don't know about your code. You can't just guess your way to an
understanding; you must first learn why your original code is broken. This
isn't always possible but it's a good goal. You learn a lot more that way.
> 1. It was 10 years ago, not 20.
Surely the things you've learned about programming in the last 10 years
would be helpful. Personally, I failed to learn C++ the first time I tried
but succeeded the second time after years of working with other languages.
Anyway, if you're not interested in learning C++, that's cool. I had thought
you were interested. I just see a pattern in your posts where there are
things you want (in this case a programming job), and when people encourage
you to get them, you list reasons why you're not able to, or why it's
difficult. You need to learn to ignore or deal with the hurdles and push
yourself until you get where you want to be.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> 3. I think this horse is now well and truly dead. ;-)
>
> That's probably true. You have decided that you have, and will always
> have, a strong prejudice against C and C++, and absolutely nothing will
> ever convince you otherwise.
What, you mean... a bit like you and every programming language that
isn't C++? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> I did eventually get a moderately complex program to work. But basically
>> every time my program didn't work, I'd replace the implementation with an
>> equivilent but differently worded one until the program actually worked.
>
> This is the sort of thing I was referring to when I said you need to know
> what you don't know about your code. You can't just guess your way to an
> understanding; you must first learn why your original code is broken. This
> isn't always possible but it's a good goal. You learn a lot more that way.
I guess the problem was not having anybody to ask nor any documentation
to look at. My mental model of what the code should be doing was clearly
broken, or the code would have done what I intended. But without any way
to figure out why... there's not a lot you can do.
>> 1. It was 10 years ago, not 20.
>
> Surely the things you've learned about programming in the last 10 years
> would be helpful.
I somewhat doubt that knowing Smalltalk, Java, Tcl, PostScript and
Haskell is going to be of any help in learning either C or C++.
> Anyway, if you're not interested in learning C++, that's cool. I had thought
> you were interested. I just see a pattern in your posts where there are
> things you want (in this case a programming job), and when people encourage
> you to get them, you list reasons why you're not able to, or why it's
> difficult. You need to learn to ignore or deal with the hurdles and push
> yourself until you get where you want to be.
It's just very difficult to find motivation when
1. all your endevours fail
2. nobody except you actually gives a damn anyway
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I somewhat doubt that knowing Smalltalk, Java, Tcl, PostScript and Haskell
> is going to be of any help in learning either C or C++.
I think they will. Not in specific ways, just in that you've learned to wrap
your mind around a lot of different types of languages. But I guess we've
already discussed this. =)
> It's just very difficult to find motivation when
>
> 1. all your endevours fail
Learn to recognize the things you *are* good at and build some confidence in
yourself. Don't spend all your time focusing on the things you can't do yet;
look at what you've done that other people wouldn't even bother to try. When
you fail, make a conscious effort to learn from your mistakes.
> 2. nobody except you actually gives a damn anyway
Sometimes you only need to please yourself!
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> 1. all your endevours fail
>
> Learn to recognize the things you *are* good at and build some confidence in
> yourself. Don't spend all your time focusing on the things you can't do yet;
> look at what you've done that other people wouldn't even bother to try. When
> you fail, make a conscious effort to learn from your mistakes.
>
>> 2. nobody except you actually gives a damn anyway
>
> Sometimes you only need to please yourself!
It just feels like my life is like Groundhog Day, you know? If I do
something well, nobody comes up to me and says "Hey Andrew, you did that
really well." If I have a bad day, nobody comes up to me and says "Don't
worry Andrew, it'll be better next time." Basically no matter what I do,
the outcome is always the same: nobody comes up to me and says anything.
You say I should have more confidence in my abilities, but when nobody
ever tells you you've done something well, you start to wonder whether
you really have, or whether you're just overestimating your achievements.
It's just really hard to find motivation when no matter what, whether
you did really well or really badly, the outcome is always exactly the
same. You start to wonder why you're bothering...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Apparently there are people who know
> the Secret Techniques for debugging C programs, and even writing C
> programs that are correct in the first place
Sadly, those are the same two things. :-) The kinds of bugs that are
hard to track down are the ones you need to aboid in the first place.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It's impossible to use a hash table and get the elements in increasing
> order with a linear traversal.
Will the hashmap guarantee equal traversals for hashmaps with equal
contents, or will it depend on the order of insertion and deletion?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> It's not how programmers do stuff typically.
One thing I haven't worked out. Warp keeps saying "don't use new", by
which he means "let the experts who understand C++ deeply write the
libraries that use new, and you just use the libraries." OK, I can
handle that.
But ... how realistic is that in a large program with complex data?
Consider something like POV-Ray - isn't that going to have to be using
"new" as it builds the scene, as it calculates bounding boxes, and stuff
like that?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Since reaching EOF is completely valid, how is the compiler supposed to
> make sure that you write a conditional which takes it into account?
Some languages can do this, actually, just like some can look at an enum
and tell you when your switch statement doesn't cover all possibilities.
:-) It's pretty cool, but certainly not something you could do in a
language based on the machine level, like C is.
> In fact, returning EOF multiple times is not an error either
> (it can be perfectly possible for different parts of the program to read
> the same file, and all of them get an EOF when there's nothing more to
> read, and all of them still work properly).
Actually, from the keyboard, you can read data, get an eof, read more
data, and get another eof, just by typing ctrl-D twice.
> So how is the compiler supposed to make sure that you do the "correct"
> thing when EOF is returned? What *is* the "correct" thing to do?
Not compile a program that tries to read past EOF?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Will the hashmap guarantee equal traversals for hashmaps with equal
> contents, or will it depend on the order of insertion and deletion?
I have no idea. Knowing how hash tables are usually implemented,
I wouldn't be surprised if it didn't guarantee anything. After all,
it *is* called "unordered map". That might literally mean "no order
guaranteed" (not even for two hash maps with the same elements).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > So how is the compiler supposed to make sure that you do the "correct"
> > thing when EOF is returned? What *is* the "correct" thing to do?
> Not compile a program that tries to read past EOF?
The compiler has to guess how much data there is in a possible input file?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> Not compile a program that tries to read past EOF?
> The compiler has to guess how much data there is in a possible input file?
No. The compiler does something called typestate analysis (not too
unlike data flow analysis) to ensure that once the function returns EOF
you don't invoke the read function any more.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> No. The compiler does something called typestate analysis (not too
> unlike data flow analysis) to ensure that once the function returns EOF
> you don't invoke the read function any more.
Given that in a Turing-complete language it's impossible to prove
in the generic case whether a certain piece of code is ever executed
or not, that would mean that the language would have to be less
expressive than a Turing machine.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Given that in a Turing-complete language it's impossible to prove
> in the generic case whether a certain piece of code is ever executed
> or not, that would mean that the language would have to be less
> expressive than a Turing machine.
I think you're overgeneralizing. Is it not possible to prove that you
never use a variable before you assign to it, or that every path to exit
a value-returning-function actually returns a value? Of course it is.
Why is it harder to prove you never read from a file handle after it has
hit EOF?
You might not be able to tell whether a program *will* get to any
particular point in the code, but you can certainly make it illegal for
it to get to particular places in the code and hence guarantee it does
*not* get to that point.
Every implementation of typestate I've seen where people rely on it
(i.e., require the semantics for the language to work, rather than just
issuing warnings) includes annotations on module-spanning APIs. In other
words, when you open a file, the returned file handle is marked at
"open", and when you read the EOF, it's actually an exception (meaning
the execution returns to a different place in the code rather than
returning a flag), so it's easy to tell at each particular line in the
code whether a file is open or not. I.e., if you have a function that
returns a file handle, you have to say whether that file handle is
already at EOF or not, for example.
It also rules out constructs like
int z;
if (x == y)
z = 0;
my_func(z);
That doesn't make it less turing complete.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
