|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|