 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> > I wouldn't call this straightforward:
> >
> > fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
> OK, well how about this:
> while (TRUE) { cont = (*cont)(); }
> I wouldn't exactly call that straightfoward either. It's not *actually*
> complicated, but it sure *looks* pretty baffling.
But the haskell code is normal, regular haskell. Your C example is
not code any sane person would write.
> Alternatively,
> while(*v++ = *s++);
> I mean, what THE HELL...?
At least it's easy to understand what it does (and why it works) when
it's explained. The haskell example isn't.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> >> while(*v++ = *s++);
> >>
> >> I mean, what THE HELL...?
> A nice example of language design inspired by hardware (and vice versa).
> May result in very fast code.
Actually a memcpy() call would probably be faster (at least if you know
the amount of data to copy).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I wouldn't exactly call that straightfoward either. It's not *actually*
>> complicated, but it sure *looks* pretty baffling.
>
> But the haskell code is normal, regular haskell. Your C example is
> not code any sane person would write.
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
some reason, there is a simple, well-known O(1) algorithm for that.
>> Alternatively,
>
>> while(*v++ = *s++);
>
>> I mean, what THE HELL...?
>
> At least it's easy to understand what it does (and why it works) when
> it's explained. The haskell example isn't.
Really? I mean, it's a little perplexing that the computer is actually
able to unravel it without getting stuck, but once you understand what
the machine is doing internally, it's not so hard.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:22, Invisible wrote:
>>> I wouldn't exactly call that straightfoward either. It's not
>>> *actually* complicated, but it sure *looks* pretty baffling.
>>
>> But the haskell code is normal, regular haskell. Your C example is
>> not code any sane person would write.
>
> 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
> some reason, there is a simple, well-known O(1) algorithm for that.
>
>>> Alternatively,
>>
>>> while(*v++ = *s++);
>>
>>> I mean, what THE HELL...?
>>
>> At least it's easy to understand what it does (and why it works) when
>> it's explained. The haskell example isn't.
>
> Really? I mean, it's a little perplexing that the computer is actually
> able to unravel it without getting stuck, but once you understand what
> the machine is doing internally, it's not so hard.
>
You mean that you not only understands how it works, but it even helped
you understand how compilers work?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo on Fri, 12 Sep 2008 09:16:07 +0100, Invisible <voi### [at] devnull> did
spake, saying:
>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>> complex language. I don't see how learning an easy language should
>>> enable me to learn a hard language.
>> Heh, Haskell looks complicated and hard to learn to me.
>
> Well, I guess there are probably people who look at something like
>
> x = (-b +- Sqrt(b^2 - 4ac)/2a
>
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
But look at the knowledge you need for that. We'll assume that the basics
are covered = + - x ÷ and that you recognise the x, a, b, and c parts of
the equation. First up we get - how can you start with a - symbol, what am
I subtracting b from? Next is a ±; okay you hopefully recognise that it's
a + and a - combined, but how do I add and subtract at the same time? Then
we get a √ um okay the shape of that gives no clue unless you just know
it. Then ² which we might know as shorthand for b x b as many times as the
number. Then we get an 4ac, is that a new character; you know a-z, aa-az,
etc? You have to know that it's shorthand for 4 x a x c. Then finally you
get a / or just one big line which you need to recognise as a ÷.
Spell out all the assumed shorthand plus symbols there and you can see why
it could legitimately be considered complicated.
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Really? I mean, it's a little perplexing that the computer is actually
>> able to unravel it without getting stuck, but once you understand what
>> the machine is doing internally, it's not so hard.
>>
> You mean that you not only understands how it works, but it even helped
> you understand how compilers work?
Well I mean *notionally*, the way Haskell executes is fairly simple. In
the case of the magic tail-chasing fibs definition, fibs starts out as a
list where some list cells are defined, and some haven't been computed
yet. And the ones that haven't been computed yet refer to the ones that
have. (If it were the other way round, you WOULD have a problem.) As you
ask for list cells, they get computed, one by one, until you get the one
you want.
It's a nice example of how lazy evaluation allows you to program in
unusual ways, but it's probably not terrifically practical unless you
only need a handful of Fibonacci numbers.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca500c@news.povray.org...
>>> while(*v++ = *s++);
>>>
>>> I mean, what THE HELL...?
>>>
>>
>> I doubt that's the recommended way of copying an array any longer
>
> I doubt that was *ever* the "recommended" way. And yet I, a person who
> doesn't know C very well, am aware of this example. What does that tell
> you? ;-)
That you're looking for examples of why the language is incomprehensible.
That you had a bad lecturer/textbook at university
That you're reading up on why C++ is bad and what constructs are known to
cause problems.
Taking the example to my prefered language, I'd say that 80% of people who
have worked much with SQL can and will use cursors, yet every expert in SQL
will tell people to never use them
Does that mean that SQL is incomprehensible to the average person and a
language that's easy to break things in?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I doubt that was *ever* the "recommended" way. And yet I, a person who
>> doesn't know C very well, am aware of this example. What does that
>> tell you? ;-)
>
> That you're looking for examples of why the language is incomprehensible.
Doesn't take much looking, does it?
> That you had a bad lecturer/textbook at university.
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'm sure this makes the compiler much easier to implement, and no doubt
it contributes to the efficiency and flexibility of the language, but...
I prefer having some kind of safety features in a programming langauge.
> That you're reading up on why C++ is bad and what constructs are known
> to cause problems.
Actually... no.
> Taking the example to my prefered language, I'd say that 80% of people
> who have worked much with SQL can and will use cursors, yet every expert
> in SQL will tell people to never use them.
> Does that mean that SQL is incomprehensible to the average person and a
> language that's easy to break things in?
I guess it depends what you're trying to do. SQL certainly has a few
known flaws (default column orderings, anyone?), but in general it makes
it quite simple and easy to do most things.
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:36, Phil Cook wrote:
> And lo on Fri, 12 Sep 2008 09:16:07 +0100, Invisible <voi### [at] devnull> did
> spake, saying:
>
>>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>>> complex language. I don't see how learning an easy language should
>>>> enable me to learn a hard language.
>>> Heh, Haskell looks complicated and hard to learn to me.
>>
>> Well, I guess there are probably people who look at something like
>>
>> x = (-b +- Sqrt(b^2 - 4ac)/2a
>>
>> and go "OH MY GOD! That looks SO complicated!" But actually, if you
>> know a little algebra, you discover that this contraption is actually
>> quite straight forward.
>
> But look at the knowledge you need for that. We'll assume that the
> basics are covered = + - x ÷ and that you recognise the x, a, b, and c
> parts of the equation. First up we get - how can you start with a -
> symbol, what am I subtracting b from? Next is a ±; okay you hopefully
> recognise that it's a + and a - combined, but how do I add and subtract
> at the same time? Then we get a √ um okay the shape of that gives no
> clue unless you just know it. Then ² which we might know as shorthand
> for b x b as many times as the number. Then we get an 4ac, is that a new
> character; you know a-z, aa-az, etc? You have to know that it's
> shorthand for 4 x a x c. Then finally you get a / or just one big line
> which you need to recognise as a ÷.
>
> Spell out all the assumed shorthand plus symbols there and you can see
> why it could legitimately be considered complicated.
>
For me the most interesting thing is the ±, that one is quite rare in
highschool maths. Here, and I assume also elsewhere, it is pronounced as
'plus or minus'. Where the 'or' apparently means that we have to
consider one *and* the other. An obvious question is: 'How can it be
that an equation has more than one answer'? There is also the often
overlooked complication that formula manipulating normally consists of
equivalent transformations. Here we have something that isn't, it is
more of a bifurcation resulting in two separate formulas, neither of
which is equivalent to the original equation. It is not obvious how to
run this process in reverse. I think I learned that one later
separately, without being told the intimate connection to the ± in this
formula (or more precise the boolean thing hidden in there somewhere).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, I guess there are probably people who look at something like
>>
>> x = (-b +- Sqrt(b^2 - 4ac)/2a
>>
>> and go "OH MY GOD! That looks SO complicated!" But actually, if you
>> know a little algebra, you discover that this contraption is actually
>> quite straight forward.
>
> But look at the knowledge you need for that.
>
> Spell out all the assumed shorthand plus symbols there and you can see
> why it could legitimately be considered complicated.
Presumably *any* language will _look_ cryptic if you don't understand
it. The question is how easy it is or isn't to _learn_. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Presumably *any* language will _look_ cryptic if you don't understand it.
> The question is how easy it is or isn't to _learn_. ;-)
I really don't understand why you find it so hard to learn C.
There are only a tiny number of core statements (like if, while, return etc)
and the syntax of them all is very similar. How to write functions you just
have to learn, but that's the same for any language. Writing mathematical
formulae is also very easy and similar to almost every other language (using
+ - / * etc).
If you want to get more advanced, then learn to handle arrays and what & and
* do (quite easy things to remember, not complex at all), and you're pretty
much set to understand 99.999% of C code out there - including things like
while(*v++ = *s++);
What's the problem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:16, scott wrote:
>> Presumably *any* language will _look_ cryptic if you don't understand
>> it. The question is how easy it is or isn't to _learn_. ;-)
>
> I really don't understand why you find it so hard to learn C.
>
> There are only a tiny number of core statements (like if, while, return
> etc) and the syntax of them all is very similar. How to write functions
> you just have to learn, but that's the same for any language. Writing
> mathematical formulae is also very easy and similar to almost every
> other language (using + - / * etc).
>
> If you want to get more advanced, then learn to handle arrays and what &
> and * do (quite easy things to remember, not complex at all), and you're
> pretty much set to understand 99.999% of C code out there - including
> things like while(*v++ = *s++);
>
> What's the problem?
>
How to translate from the concept in your mind to a working program.
That you can use a word processor and have a plot in mind does not
necessary imply that you can write a good story. Especially if the story
has to be written in a language that doesn't fit your preferences.
Exercise: rewrite your reply in Dutch. Hint: we use for all practical
purposes the same alphabet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:37, Invisible wrote:
>>> Really? I mean, it's a little perplexing that the computer is
>>> actually able to unravel it without getting stuck, but once you
>>> understand what the machine is doing internally, it's not so hard.
>>>
>> You mean that you not only understands how it works, but it even
>> helped you understand how compilers work?
>
> Well I mean *notionally*, the way Haskell executes is fairly simple. In
> the case of the magic tail-chasing fibs definition, fibs starts out as a
> list where some list cells are defined, and some haven't been computed
> yet. And the ones that haven't been computed yet refer to the ones that
> have. (If it were the other way round, you WOULD have a problem.) As you
> ask for list cells, they get computed, one by one, until you get the one
> you want.
>
> It's a nice example of how lazy evaluation allows you to program in
> unusual ways, but it's probably not terrifically practical unless you
> only need a handful of Fibonacci numbers.
>
That is not really an answer to the question. OTOH it does show that the
Haskell example can also be used to explain how the Haskell compiler (or
whatever it is) works.
Aside, the Haskell evaluation needs much more to explain that the C code
execution. That is of course because all processors have instruction
sets that are modelled on imperative languages (and vice versa). For
most programmers that seems to imply that imperative languages are more
natural perhaps even more fundamental.
I personally think imperative languages are also perceived as more
natural because of the way maths is taught. Teachers tell you to do this
and then do that. That imposes a sense of direction on the process that
is not actually there. It does however make it easy to understand such
things like x=x+1. To such an extend that I have never seen any student
object to such silliness.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Aside, the Haskell evaluation needs much more to explain that the C code
> execution.
You're probably right about that.
(OTOH, doesn't C have short-circuit Boolean operators?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.)
> There are only a tiny number of core statements (like if, while, return
> etc) and the syntax of them all is very similar. How to write functions
> you just have to learn, but that's the same for any language. Writing
> mathematical formulae is also very easy and similar to almost every
> other language (using + - / * etc).
>
> If you want to get more advanced, then learn to handle arrays and what &
> and * do (quite easy things to remember, not complex at all), and you're
> pretty much set to understand 99.999% of C code out there - including
> things like while(*v++ = *s++);
>
> What's the problem?
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?)
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.
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.
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!
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.
Boolean operators and bitwise operators. Which is which? Which ones are
the short-circuit ones, and which aren't? I can never remember.
Pointers in general usually result in disaster. I constantly get the
syntax wrong for pointer types, pointer dereferencing, and pointer creation.
Apparently you're not supposed to mutate strings encoded in the program
source code. It seems to make Strange Things happen.
What's the difference between #include "" and include <>?
Preprocessor macros. (Need I say more?)
Header files, make files, include files, "extern", the whole shooting
match. Wuh?
At least some of these things appear to be fixed in C++.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How to translate from the concept in your mind to a working program.
I didn't get the impression that is what Andy was complaining about, after
all he says he can program in Java, so converting from concept to C
shouldn't be very different from converting from concept to Java. I assume
he can also program POV SDL, and has dabbled in BASIC etc.
If you'd only ever programmed in Haskell or some other functional language,
then sure I can see how you might have a hard time writing some C even if
you knew all the commands and syntax.
> That you can use a word processor and have a plot in mind does not
> necessary imply that you can write a good story. Especially if the story
> has to be written in a language that doesn't fit your preferences.
> Exercise: rewrite your reply in Dutch. Hint: we use for all practical
> purposes the same alphabet.
Sure, teach me all the words you use and any grammar rules and it shouldn't
be too hard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> How to translate from the concept in your mind to a working program.
>
> I didn't get the impression that is what Andy was complaining about,
> after all he says he can program in Java, so converting from concept to
> C shouldn't be very different from converting from concept to Java.
You know what? In Java, if you reference a null pointer, a little
message pops up that says "hey, you just dereferenced a null pointer".
And it even tells you where it happened. In C, your program just behaves
bizarely.
Ditto for EOF, array index out of bounds, out of memory...
Java has a seperate Boolean type, so you can tell when a function
returns a numer and when it returns a Boolean. (And you don't have to
memorise whether 0 is true or false. And if you accidentally try to use
a number where a Boolean is expected, the compiler *tells* you about
this. And...)
Memory leaks? What memory leaks? No dangling pointers here either.
Need I go on?
In short, Java is a suck-ass language, but at least it's easier than C.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:33, Invisible wrote:
> andrel wrote:
>
>> Aside, the Haskell evaluation needs much more to explain than the C
>> code execution.
>
> You're probably right about that.
that is rather sparse quoting. The context was meant to imply that it
shouldn't (in an ideal world with no memory and fresh teachers very year).
> (OTOH,
?
> doesn't C have short-circuit Boolean operators?)
Not sure if the answer for an negated question should be yes or no.
Anyway C logical operators don't evaluate terms on the right if the
answer is already known. Perfectly sensible in a world without side effects.
At times like this I wish for a time machine and go back and shoot the
moron that first used the 'short-circuit Boolean operators' expression.
Mind you I am normally not an aggressive person.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:35, scott wrote:
>> How to translate from the concept in your mind to a working program.
>
> I didn't get the impression that is what Andy was complaining about,
> after all he says he can program in Java, so converting from concept to
> C shouldn't be very different from converting from concept to Java. I
> assume he can also program POV SDL, and has dabbled in BASIC etc.
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.
> If you'd only ever programmed in Haskell or some other functional
> language, then sure I can see how you might have a hard time writing
> some C even if you knew all the commands and syntax.
>
>> That you can use a word processor and have a plot in mind does not
>> necessary imply that you can write a good story. Especially if the
>> story has to be written in a language that doesn't fit your
>> preferences. Exercise: rewrite your reply in Dutch. Hint: we use for
>> all practical purposes the same alphabet.
>
> Sure, teach me all the words you use and any grammar rules and it
> shouldn't be too hard.
>
For fun I tried babelfish:
Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren. Er
is slechts een uiterst klein aantal kernverklaringen (als als, terwijl,
terugkeer enz.) en de syntaxis van hen allen is zeer gelijkaardig. Hoe
te om functies te schrijven moet u enkel leren, maar dat is het zelfde
voor om het even welke taal. Schrijven van wiskundige formules is ook
zeer gemakkelijk en gelijkaardig aan bijna elke andere taal die (+ -/*
enz. gebruikt). Als u geavanceerder wilt worden, dan leer om series te
behandelen en welke & en * (vrij gemakkelijke dingen zich te herinneren,
niet bij allen complex), en u bent vrij veel plaatst om 99.999% van de
code van C - met inbegrip van dingen als daar te begrijpen terwijl (*v++
= *s++); Wat is het probleem?
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). Language is much more than syntax and grammar. Which was
the point I wanted to make in the first place.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> 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.
I can write you programs in BASIC, Pascal, SDL, Tcl, Java, JavaScript,
PostScript, or even assembly if I have to. (Depends which processor.
Obviously.) But C and a few other highly complex and messy languages are
more than even I can cope with.
> For fun I tried babelfish:
> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren. Er
> is slechts een uiterst klein aantal kernverklaringen (als als, terwijl,
> terugkeer enz.) en de syntaxis van hen allen is zeer gelijkaardig. Hoe
> te om functies te schrijven moet u enkel leren, maar dat is het zelfde
> voor om het even welke taal. Schrijven van wiskundige formules is ook
> zeer gemakkelijk en gelijkaardig aan bijna elke andere taal die (+ -/*
> enz. gebruikt). Als u geavanceerder wilt worden, dan leer om series te
> behandelen en welke & en * (vrij gemakkelijke dingen zich te herinneren,
> niet bij allen complex), en u bent vrij veel plaatst om 99.999% van de
> code van C - met inbegrip van dingen als daar te begrijpen terwijl (*v++
> = *s++); Wat is het probleem?
My God... It's... It's like... [I'm searching for the HGTTG quote]...
It's like a psuedo-random assortment of letters!
Mind you, I would think _every_ language looks like that until you
understand the rules. ;-)
> 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.
For fun, I tried translating from and then to English with various
phrases on Google Translate. This yielded such gems as
"Leave the impact price-increase your body."
I cannot even begin to imagine how the hell it arrived at that... ;-)
With experimentation, it seems that the translation FROM English to
German significantly breaks sentences, while the translation the other
way is moderately reliable.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 17:08, andrel wrote:
>>> That you can use a word processor and have a plot in mind does not
>>> necessary imply that you can write a good story. Especially if the
>>> story has to be written in a language that doesn't fit your
>>> preferences. Exercise: rewrite your reply in Dutch. Hint: we use for
>>> all practical purposes the same alphabet.
>>
>> Sure, teach me all the words you use and any grammar rules and it
>> shouldn't be too hard.
>>
> For fun I tried babelfish:
> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren. Er
> is slechts een uiterst klein aantal kernverklaringen (als als, terwijl,
> terugkeer enz.) en de syntaxis van hen allen is zeer gelijkaardig. Hoe
> te om functies te schrijven moet u enkel leren, maar dat is het zelfde
> voor om het even welke taal. Schrijven van wiskundige formules is ook
> zeer gemakkelijk en gelijkaardig aan bijna elke andere taal die (+ -/*
> enz. gebruikt). Als u geavanceerder wilt worden, dan leer om series te
> behandelen en welke & en * (vrij gemakkelijke dingen zich te herinneren,
> niet bij allen complex), en u bent vrij veel plaatst om 99.999% van de
> code van C - met inbegrip van dingen als daar te begrijpen terwijl (*v++
> = *s++); Wat is het probleem?
>
After correcting the grammar and minor adjustments to restore the
meaning this is the back translation in english:
I do not understand really why you find it this way difficult for C. to
learn. There is only an extremely small number of core declarations
(such as if, while, return etc.) and the syntax of them all is very
similar. How functions must write you to learn, but that is it same for
any language. Letters of mathematical formulas are also very easy and
similar to almost each other language which (+ -/* etc. use). If you
want become more sophisticated, leathers then to treat arrays and which
& and * (to rather easy things remember, not at all complex), and you
are rather able understand 99,999% of the code of C - including things
as while (*v++ = *s++); What is the problem?
Good luck on applying grammar rules to correct 'How functions must write
you to learn, but that is it same for any language.' Not to mention the
first sentence that is (after exchanging understand and really) probably
grammatically correct English, but may not exactly express what you
intended.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 17:20, Invisible wrote:
> andrel wrote:
>
>> 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.
>
> I can write you programs in BASIC, Pascal, SDL, Tcl, Java, JavaScript,
> PostScript, or even assembly if I have to. (Depends which processor.
> Obviously.) But C and a few other highly complex and messy languages are
> more than even I can cope with.
I find the 'even I' amusing.
>
>> For fun I tried babelfish:
>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren.
[snip]
>> dingen als daar te begrijpen terwijl (*v++ = *s++); Wat is het probleem?
>
> My God... It's... It's like... [I'm searching for the HGTTG quote]...
> It's like a psuedo-random assortment of letters!
Is that the quote? From which book?
> Mind you, I would think _every_ language looks like that until you
> understand the rules. ;-)
even more so if the language uses a foreign alphabet or worse.
>
>> 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.
>
> For fun, I tried translating from and then to English with various
> phrases on Google Translate.
Didn't know google had also a translator. Well, not better than
babelfish. Different, but not better.
> This yielded such gems as
>
> "Leave the impact price-increase your body."
>
> I cannot even begin to imagine how the hell it arrived at that... ;-)
>
> With experimentation, it seems that the translation FROM English to
> German significantly breaks sentences,
how would you know?
> while the translation the other way is moderately reliable.
I can not imagine that it will translate the archetypal German sentences
with the verb that closes the sentence 5 lines below the subject in a
readable way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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...
> In most cases it considerably reduces memory usage and can potentially be
> much faster. (On the downside you have to be able to come up with a
> high-quality hash function for your elements. A poorly designed function
> can make the hash map very slow.)
So the onus of coming up with a function will be on the user? Will it
provide some defaults?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I can write you programs in BASIC, Pascal, SDL, Tcl, Java, JavaScript,
>> PostScript, or even assembly if I have to. (Depends which processor.
>> Obviously.) But C and a few other highly complex and messy languages
>> are more than even I can cope with.
> I find the 'even I' amusing.
Do you know how many people can code directly in PostScript? (Small
hint: not many.)
Do you know how many people can code in assembly? (Hint: even fewer.)
>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>> It's like a psuedo-random assortment of letters!
>
> Is that the quote?
Er, no.
>> With experimentation, it seems that the translation FROM English to
>> German significantly breaks sentences,
>
> how would you know?
Some of the Germans in this forum said so.
>> while the translation the other way is moderately reliable.
>
> I can not imagine that it will translate the archetypal German sentences
> with the verb that closes the sentence 5 lines below the subject in a
> readable way.
Search me.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 19:15, Orchid XP v8 wrote:
>>> I can write you programs in BASIC, Pascal, SDL, Tcl, Java,
>>> JavaScript, PostScript, or even assembly if I have to. (Depends which
>>> processor. Obviously.) But C and a few other highly complex and messy
>>> languages are more than even I can cope with.
>
>> I find the 'even I' amusing.
>
> Do you know how many people can code directly in PostScript? (Small
> hint: not many.)
been there, done that
>
> Do you know how many people can code in assembly? (Hint: even fewer.)
been there, done that (for at least 3-5 processors and the one I built
myself ;) )
I think less people coded postscript than assembly, at least when I was
young (it was part of our university course)
>
>>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>>> It's like a psuedo-random assortment of letters!
>>
>> Is that the quote?
>
> Er, no.
Ok, what were you looking for, what scene. I don't know which you mean
and I though I knew his material rather well.
>
>>> With experimentation, it seems that the translation FROM English to
>>> German significantly breaks sentences,
>>
>> how would you know?
>
> Some of the Germans in this forum said so.
Ah, ok. So you trust non-native speakers to judge how broken english is.
Makes sense.
>
>>> while the translation the other way is moderately reliable.
>>
>> I can not imagine that it will translate the archetypal German
>> sentences with the verb that closes the sentence 5 lines below the
>> subject in a readable way.
>
> Search me.
>
... Milton Keynes , am I close?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca7536$1@news.povray.org...
>
> I guess it depends what you're trying to do. SQL certainly has a few known
> flaws (default column orderings, anyone?), but in general it makes it
> quite simple and easy to do most things.
What column orderings?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca7536$1@news.povray.org...
>>
>> I guess it depends what you're trying to do. SQL certainly has a few
>> known flaws (default column orderings, anyone?), but in general it
>> makes it quite simple and easy to do most things.
>
> What column orderings?
Apparently some people consider it a bug that you can write queries that
depend on the order in which columns are returned (rather than by
explicit column names). Since relations are supposed to be sets, that
shouldn't be the case.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca7de8@news.povray.org...
>
> 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.
How often does a C/C++ programmer really need a function pointer? It's one
of those advanced features that 99% of the time isn't needed at all.
> 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!
0. Any other value is true.
> 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.
Most compilers will warn about that these days.
It's the same in Java, the same in C#
> Pointers in general usually result in disaster. I constantly get the
> syntax wrong for pointer types, pointer dereferencing, and pointer
> creation.
So don't use them. As Warp and others have shown, it's not necessary in any
way to use pointers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> wrote in message
news:48C### [at] hotmailcom...
> At times like this I wish for a time machine and go back and shoot the
> moron that first used the 'short-circuit Boolean operators' expression.
> Mind you I am normally not an aggressive person.
I'll help you.
I'm currently having a 'discussion' with an 'enlightened individual' who's
trying to tell me that T-SQL (as in the implementation in MS SQL Server)
does the same short-circuit evaluation that C++ and C# (and probably others)
do.
Please note the deliberate sarcasm in the above statement.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
> How often does a C/C++ programmer really need a function pointer?
Hopefully very rarely...
>> 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!
>
> 0. Any other value is true.
I remember that 0 is one thing and everything else is the opposite. But
I can never remember which is which.
>> 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.
>
> Most compilers will warn about that these days.
> It's the same in Java, the same in C#
In Java, unless x happens to be a bool, you'll get a compile-time error.
In C it's a perfectly valid construct.
>> Pointers in general usually result in disaster. I constantly get the
>> syntax wrong for pointer types, pointer dereferencing, and pointer
>> creation.
>
> So don't use them. As Warp and others have shown, it's not necessary in
> any way to use pointers.
It is in C. If you want printf() to print a string for you, you must
pass a pointer to a string.
Maybe this is one of the things they actually fixed in C++...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> At times like this I wish for a time machine and go back and shoot the
>> moron that first used the 'short-circuit Boolean operators'
>> expression. Mind you I am normally not an aggressive person.
>
> I'll help you.
> I'm currently having a 'discussion' with an 'enlightened individual'
> who's trying to tell me that T-SQL (as in the implementation in MS SQL
> Server) does the same short-circuit evaluation that C++ and C# (and
> probably others) do.
>
> Please note the deliberate sarcasm in the above statement.
...so, an "enlightened individual" is telling an MSVP how her product
speciality works?
That's interesting...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca88be$1@news.povray.org...
>> For fun I tried babelfish:
>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren. Er
>> is slechts een uiterst klein aantal kernverklaringen (als als, terwijl,
>> terugkeer enz.) en de syntaxis van hen allen is zeer gelijkaardig. Hoe te
>> om functies te schrijven moet u enkel leren, maar dat is het zelfde voor
>> om het even welke taal. Schrijven van wiskundige formules is ook zeer
>> gemakkelijk en gelijkaardig aan bijna elke andere taal die (+ -/* enz.
>> gebruikt). Als u geavanceerder wilt worden, dan leer om series te
>> behandelen en welke & en * (vrij gemakkelijke dingen zich te herinneren,
>> niet bij allen complex), en u bent vrij veel plaatst om 99.999% van de
>> code van C - met inbegrip van dingen als daar te begrijpen terwijl (*v++
>> = *s++); Wat is het probleem?
>
> My God... It's... It's like... [I'm searching for the HGTTG quote]... It's
> like a psuedo-random assortment of letters!
Dis nie soo erg nie. Dis amper die selfte as Afrikaans, behlawe van die 'ij'
konstruk. Die taal is maklik vergelyk its soos Zoeloe.
Wat is jou probleem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48caaeeb$1@news.povray.org...
> ...so, an "enlightened individual" is telling an MSVP how her product
> speciality works?
(MVP)
> That's interesting...
That's one way of putting it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48caab2e$1@news.povray.org...
> Gail wrote:
>>
>> "Invisible" <voi### [at] devnull> wrote in message
>> news:48ca7536$1@news.povray.org...
>>>
>>> I guess it depends what you're trying to do. SQL certainly has a few
>>> known flaws (default column orderings, anyone?), but in general it makes
>>> it quite simple and easy to do most things.
>>
>> What column orderings?
>
> Apparently some people consider it a bug that you can write queries that
> depend on the order in which columns are returned (rather than by explicit
> column names). Since relations are supposed to be sets, that shouldn't be
> the case.
Some people consider it a bug that the order of rows is undefined without an
order by statement.
Fortunatly for my sanity (and that of a few other people) in T-SQL columns
are always returned in the same order if SELECT * is specified. It's the
order of the column in the system tables.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 20:02, Orchid XP v8 wrote:
> Gail wrote:
>
>> How often does a C/C++ programmer really need a function pointer?
>
> Hopefully very rarely...
>
>>> 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!
>>
>> 0. Any other value is true.
>
> I remember that 0 is one thing and everything else is the opposite. But
> I can never remember which is which.
It's easy, booleans are a sort of integers following the normal
convention that 0 is false and 1 is true. That any other value also
works comes from the fact that most processors have a zero flag that you
can conditionally jump on. Another example of hardware influencing the
language.
AFAIK the only place where this convention is not used is in shell
scripts in UN*X. Here the reason is that they are originally not
booleans but error codes.
At least that is how I think where the conventions come from. Anyone
more knowledgeable can correct me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 20:10, Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca88be$1@news.povray.org...
>
>>> For fun I tried babelfish:
>>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren.
>>> Er is slechts een uiterst klein aantal kernverklaringen (als als,
>>> terwijl, terugkeer enz.) en de syntaxis van hen allen is zeer
>>> gelijkaardig. Hoe te om functies te schrijven moet u enkel leren,
>>> maar dat is het zelfde voor om het even welke taal. Schrijven van
>>> wiskundige formules is ook zeer gemakkelijk en gelijkaardig aan bijna
>>> elke andere taal die (+ -/* enz. gebruikt). Als u geavanceerder wilt
>>> worden, dan leer om series te behandelen en welke & en * (vrij
>>> gemakkelijke dingen zich te herinneren, niet bij allen complex), en u
>>> bent vrij veel plaatst om 99.999% van de code van C - met inbegrip
>>> van dingen als daar te begrijpen terwijl (*v++ = *s++); Wat is het
>>> probleem?
>>
>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>> It's like a psuedo-random assortment of letters!
>
> Dis nie soo erg nie. Dis amper die selfte as Afrikaans, behlawe van die
> 'ij' konstruk.
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'.
> 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.
> Wat is jou probleem?
Ask Andy, not me ;)
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...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
>>>> 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!
>>>
>>> 0. Any other value is true.
>>
>> I remember that 0 is one thing and everything else is the opposite.
>> But I can never remember which is which.
>
> It's easy, booleans are a sort of integers following the normal
> convention that 0 is false and 1 is true. That any other value also
> works comes from the fact that most processors have a zero flag that you
> can conditionally jump on. Another example of hardware influencing the
> language.
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.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 21:14, Vincent Le Chevalier wrote:
> andrel a écrit :
>>>>> 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!
>>>>
>>>> 0. Any other value is true.
>>>
>>> I remember that 0 is one thing and everything else is the opposite.
>>> But I can never remember which is which.
>>
>> It's easy, booleans are a sort of integers following the normal
>> convention that 0 is false and 1 is true. That any other value also
>> works comes from the fact that most processors have a zero flag that
>> you can conditionally jump on. Another example of hardware influencing
>> the language.
>
> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> Method overrides that don't actually override unless you insert special
>> code?
>
> I'm with Warp on this one: what?
I think he means "method overrides that don't actually override unless you
go through the enormous effort of typing the 'virtual' keyword in the
declaration" :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> I believe
> you can insert an element in the middle of a vector.
You can. It's O(n) where n is the number of elements between the insertion
point and the end; but you can.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Alternatively,
>
> while(*v++ = *s++);
>
> I mean, what THE HELL...?
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."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> I really don't understand why you find it so hard to learn C.
> There are only a tiny number of core statements (like if, while, return etc)
> and the syntax of them all is very similar. How to write functions you just
> have to learn, but that's the same for any language. Writing mathematical
> formulae is also very easy and similar to almost every other language (using
> + - / * etc).
Yet there are things in C which even expert C programmers have hard time
understanding. One good example: What does this mean (and why):
(******************putchar) (4 ["Hello"]);
(Yes, that's completely valid standard C.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> You know what? In Java, if you reference a null pointer, a little
> message pops up that says "hey, you just dereferenced a null pointer".
> And it even tells you where it happened. In C, your program just behaves
> bizarely.
Actually no. IIRC the C standard defines that accessing the null pointer
is illegal (and will usually cause a segmentation fault). If you are running
a proper debugger, it will tell you the exact line where the null pointer
was accessed.
> 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?
> array index out of bounds
Unless you use a proper debugger.
> out of memory...
Causes a null pointer access in C.
> (And you don't have to memorise whether 0 is true or false.
I see how that's such a hard thing to memorize.
> Memory leaks? What memory leaks?
Yeah. Java leaks memory constantly. In fact, *everything* is leaked.
> No dangling pointers here either.
Except for the null references.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 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.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> You know what? In Java, if you reference a null pointer, a little
> message pops up that says "hey, you just dereferenced a null pointer".
> And it even tells you where it happened. In C, your program just behaves
> bizarely.
In Java, if you deference a null pointer, it throws a NullPointerException
which basically kills your program if you don't catch it anywhere (and
usually you shouldn't).
In C, your program immediately segfaults, and if it was running under a
debugger you get the line of code where it did. Or at least the address of
the code it was executing.
> Java has a seperate Boolean type, so you can tell when a function
> returns a numer and when it returns a Boolean. (And you don't have to
> memorise whether 0 is true or false. And if you accidentally try to use
> a number where a Boolean is expected, the compiler *tells* you about
> this. And...)
C++ has a bool type. Although it's easy to accidentally convert it to a
number (true + true isn't a compiler error).
> Memory leaks? What memory leaks? No dangling pointers here either.
In Java, you're leaking memory all the time (quote from Warp), and the
runtime environment is trying to clean up the mess behind you. Forgetting
to set a reference to null when you don't plan to use it anymore would keep
it from being cleaned up, and would cause the same effect as not freeing
memory in C/C++.
C++ doesn't need garbage garbage collection because it generates so little
garbage (quote from Bjarne Stroustrup).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
(Of course it doesn't help that 90% of the keywords and standard library
function names are obfuscated. Sometimes the names are obscure because the
concept behind them is so obscure. 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.)
> 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?)
Have you looked at the standard library function names in haskell
recently?
(Besides, if you want easy string manipulation, use C++, not C.)
> 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.
I have programmed C/C++ for over 10 years, over half of that
professionally, and I have used function pointers probably less than
a dozen times.
> 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.
> 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.
> 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.
> What's the difference between #include "" and include <>?
Does it matter?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> 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. Sure, he developed the linux kernel, but his views of programming
and programming paradigms are just nuts.
(I'm not saying he is wrong in this particular case, just that I don't
consider him any kind of authority or expert on programming and programming
practices.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You know what? In Java, if you reference a null pointer, a little
>> message pops up that says "hey, you just dereferenced a null pointer".
>> And it even tells you where it happened. In C, your program just behaves
>> bizarely.
>
> Actually no. IIRC the C standard defines that accessing the null pointer
> is illegal (and will usually cause a segmentation fault). If you are running
> a proper debugger, it will tell you the exact line where the null pointer
> was accessed.
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". Pascal programs never, ever did that.
>> 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?
>> array index out of bounds
>
> Unless you use a proper debugger.
I've never seen a C debugger. Nor would I know where to find one.
(Although presumably it's a standard tool that a real C programmer would
know how to find and use.)
>> (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.
>> Memory leaks? What memory leaks?
>
> Yeah. Java leaks memory constantly. In fact, *everything* is leaked.
I was waiting for that one... ;-)
>> No dangling pointers here either.
>
> Except for the null references.
You can still forget to make a pointer point to something, but you can't
accidentally delete a chunk of memory that's still in use.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
>> 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.
>
> 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.
Joburg, Cape
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
