Programming language for children

[Jay Daniels]

marc wrote:
> Knapp said:
> 
>>> That's not to say it's the only way; that C is much more intimidating
>>> that Java/PHP is a very valid point.  This is my personal opinion as to
>>> which route is easier in the long run.  Just because it differs from
>>> yours doesn't make it "appalling".
>> Having read your argument about learning C first makes me want to say
>> that people should just learn Assembly first. This is not sarcasm. My
>> second language was 6502 assembly and that understanding greatly helped
>> me to understand C.
> 
> For educational purposes, I agree. Particularly 6500 assembly, because it 
> is one of the less hieroglyphic assemblers.
> 
>> All this comes down to a top
>> down or bottom up approach to learning. What is best seems to be
>> dictated by personality type or learning type.
> 
> I don't agree. Even if you learn an OO language, a solid understanding of 
> OO principles is essential, regardless of the language, to use it 
> properly.
> 
>> People have often said
>> that learning basic first is bad but I don't think it ever hurt me.
> 
> As a maths dude, first principles are everything, and thus essential. But 
> folk don't need to know those principles nor the derivations to use the 
> results. Nor should they. It's quite valid for me to derive a theorem 
> based on any number of others without understanding the derivation of any 
> of them.
> 
>> What
>> is REALLY important is to document your programming as you do it and in
>> a way that it makes scene years latter! That is the one lesson my
>> computer teachers gave me that made any difference to me.
> 
> There are definitely two schools (at least) of thought on this, as 
> always. I sit in the camp of code being self documenting. This is a 
> skill, so has to be learned. But it is enabled by modern tools, which 
> allow arbitrarily long names because of code completion, and the 
> decomposition of code into classes and small, discrete methods.
> 
> Comments are essential, though, when something is not immediately clear 
> from the code - complex algorithms are a likely candidate - or code has 
> been frigged for performance.
> 
> Things are also made clearer by tests, which again modern tools make 
> ridiculously simple to implement.
> 

But yet more difficult to change after designed.  For instance, it's 
fairly simple to design a crud application in Netbeans, but change 
without breaking it (for a newbie at least) could prove more difficult 
than if you had started with vi and C++ from the beginning!


jay