> 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