Nicolas Sicard Wrote:
> It seems the main argument why Java is a good first language is that it lacks complexity (namely C++ complexity). I think it also lacks simplicity for absolute beginners. D can be both simple and complex, and it shares other features with Java that could make it a language for beginners: object-oriented, no pointers necessary, garbage collection, strict type checking, portable...
> 
> What feature would make D a worse choice than Java for a first language?
> 
> Nicolas

If you feel like you can teach D better than any other language, do it. You will do this work and you will be asked for results. Imperative languages don't differ in terms of basic concepts like execution flow, statements, operators, primitive data types, basic I/O. Do your students really need docs beyond basic syntax?
Hmm... python having biological libraries could interest them (which is good) if you plan to give them tasks on this library.

Chris R. Miller a écrit :
> Sean Kelly wrote:
>> Nicolas Sicard wrote:
>>> I am a teacher in a field where my students don't know what a programming language is! I need a language for a first approach of programming. I would say that Pascal, or BASIC even if a bit outdated, or even D would fit, but not Java.
>>>
>>> I can imagine my first lesson with Java:
>>>
>>>     public class HelloWorld {
>>>         public static void main(String[] args) {
>>>             System.out.print("Hello world!");
>>>         }
>>>     }
>>>
>>> I would have to explain what a class is. What a method is. What a public or private visibility means. What a static method is. What the dots in "System.out.print" mean... :) Then how to compile it. Why you can't run it without a virtual machine. A virtual what?
>>
>> The typical approach to this tends to be "just put this stuff in the file and ignore it--I'll explain it later.  I never understood why this is considered a good teaching method :-)
>
> There are so many concepts and mechanics that are at work with even the simplest Hello World in wee simple C that it's completely irrational to expect a student new to programming to comprehend what's going on.  Just think about it...
>
> #include <stdio.h>
>
> int main(){
>     printf("Hello, world!");
>     return 0;
> }
>
> Right there!  More concepts than can even be explained!  You have the concept of an include, and how the parser literally strings all the files together to create a processed source code, then how the compiler creates a new C run time in suspended animation which will then run the function main(), and how printf is supplied by the include directive earlier.  We get it 'cause we've been trained.  To a lot of kids it's a completely foreign thing.  I mean... gee, this computer is hecka dumb 'n stuff if we need to tell it where to find out how to talk through the display!  Not to mention the distinction of a constant character array, arrays in general, string literals, types, casting, return values, etc.  It's a crazy world!
>
> At a certain point you have to pedagogically ask the student to take certain things on faith until you can better explain it all.
Of course, and this is true for every teaching action in every field. I sureky wouldn't teach linguistics to babies learnig to talk. I would just tell them what the words mean. In your C example, as well as in the Java one, I would tell my students why they have to use these items and what for, but certainly not how they work. In this respect, there is much to say in Java's HelloWorld, and less in C/D/Pascal's, even less in Python's.

Jarrett Billingsley a écrit :
> On Sun, Sep 28, 2008 at 8:03 AM, Nicolas Sicard <dransic@free.fr> wrote:
>
>   
>> I can imagine my first lesson with Java:
>>
>>    public class HelloWorld {
>>        public static void main(String[] args) {
>>            System.out.print("Hello world!");
>>        }
>>    }
>>
>> I would have to explain what a class is. What a method is. What a public or
>> private visibility means. What a static method is. What the dots in
>> "System.out.print" mean... :) Then how to compile it. Why you can't run it
>> without a virtual machine. A virtual what?
>>     
>
> It's funny you mention this because I had this exact experience last
> year.  I worked as a student helper at my university, where students
> from classes I had already taken could come and ask questions about
> things they didn't understand and assignments they were doing.  For
> some reason, the simplest introductory programming course at my
> university is taught in Java.  And every week, there'd be at _least_
> two people asking me why we had to put the "public static void
> main(String[] args)", why variables had to be declared before use, why
> they had to compile and then run etc.  And these same people had
> problems grasping concepts of what a string was and that numbers were
> not infinitely precise.  It seems like throwing all this OO junk at
> people from the outset is way too much information at one time.
>   

Well, I have also experienced that curly braces, and specifically visualizing their nesting levels, is a hard thing for some of the novice programmers. Pascal's begin/end were a lot more expressive. Maybe Python's syntax is more beginner-friendly.
So OO is not for tomorrow ! :-)

== Quote from Chris R. Miller (lordsauronthegreat@gmail.com)'s article
> Sean Kelly wrote:
> > Nicolas Sicard wrote:
> >> I am a teacher in a field where my students don't know what a programming language is! I need a language for a first approach of programming. I would say that Pascal, or BASIC even if a bit outdated, or even D would fit, but not Java.
> >>
> >> I can imagine my first lesson with Java:
> >>
> >>     public class HelloWorld {
> >>         public static void main(String[] args) {
> >>             System.out.print("Hello world!");
> >>         }
> >>     }
> >>
> >> I would have to explain what a class is. What a method is. What a public or private visibility means. What a static method is. What the dots in "System.out.print" mean... :) Then how to compile it. Why you can't run it without a virtual machine. A virtual what?
> >
> > The typical approach to this tends to be "just put this stuff in the file and ignore it--I'll explain it later.  I never understood why this is considered a good teaching method :-)
> There are so many concepts and mechanics that are at work with even the
> simplest Hello World in wee simple C that it's completely irrational to
> expect a student new to programming to comprehend what's going on.  Just
> think about it...
> #include <stdio.h>
> int main(){
>      printf("Hello, world!");
>      return 0;
> }
> Right there!  More concepts than can even be explained!  You have the
> concept of an include, and how the parser literally strings all the
> files together to create a processed source code, then how the compiler
> creates a new C run time in suspended animation which will then run the
> function main(), and how printf is supplied by the include directive
> earlier.

And of course don't forget explaining how a compiler works since they'll be compiling the app, and how an OS works since it runs on an OS...

In all fairness, I think there's a happy medium here, where the stuff that the student sees is explained without involving related but extraneous details.  The big issue for me with Java is that I don't see any way around at least a simple explanation of OO, given the format of a Java "hello world" app.  That's significantly more material than discussing a "hello world" in C or D.  C++ would be kind of a mess as well, since IO there uses operator overloading, etc.

> At a certain point you have to pedagogically ask the student to take certain things on faith until you can better explain it all.

Fair enough.  But the amount each student is willing to take on faith varies. Some will accept pretty much anything as magic, while others want to know how a function call works mechanically (or in some cases conceptually, if they're math geeks) before they feel comfortable actually calling functions.


Sean

Sean Kelly wrote:
> == Quote from Chris R. Miller (lordsauronthegreat@gmail.com)'s article
>> Sean Kelly wrote:
>>> Nicolas Sicard wrote:
>>>> I am a teacher in a field where my students don't know what a
>>>> programming language is! I need a language for a first approach of
>>>> programming. I would say that Pascal, or BASIC even if a bit outdated,
>>>> or even D would fit, but not Java.
>>>>
>>>> I can imagine my first lesson with Java:
>>>>
>>>>     public class HelloWorld {
>>>>         public static void main(String[] args) {
>>>>             System.out.print("Hello world!");
>>>>         }
>>>>     }
>>>>
>>>> I would have to explain what a class is. What a method is. What a
>>>> public or private visibility means. What a static method is. What the
>>>> dots in "System.out.print" mean... :) Then how to compile it. Why you
>>>> can't run it without a virtual machine. A virtual what?
>>> The typical approach to this tends to be "just put this stuff in the
>>> file and ignore it--I'll explain it later.  I never understood why this
>>> is considered a good teaching method :-)
>> There are so many concepts and mechanics that are at work with even the
>> simplest Hello World in wee simple C that it's completely irrational to
>> expect a student new to programming to comprehend what's going on.  Just
>> think about it...
>> #include <stdio.h>
>> int main(){
>>      printf("Hello, world!");
>>      return 0;
>> }
>> Right there!  More concepts than can even be explained!  You have the
>> concept of an include, and how the parser literally strings all the
>> files together to create a processed source code, then how the compiler
>> creates a new C run time in suspended animation which will then run the
>> function main(), and how printf is supplied by the include directive
>> earlier.
> 
> And of course don't forget explaining how a compiler works since they'll
> be compiling the app, and how an OS works since it runs on an OS...
> 
> In all fairness, I think there's a happy medium here, where the stuff that
> the student sees is explained without involving related but extraneous
> details.  The big issue for me with Java is that I don't see any way around
> at least a simple explanation of OO, given the format of a Java "hello world"
> app.  That's significantly more material than discussing a "hello world" in
> C or D.  C++ would be kind of a mess as well, since IO there uses operator
> overloading, etc.

My teacher didn't explain that.  For four months I had no idea what this strange "class Main" was all about.  I knew that if the class name was different than the file name it didn't run, but beyond that I ignored it, since the assignments didn't require work outside the class. Anything I needed I could import.

>> At a certain point you have to pedagogically ask the student to take
>> certain things on faith until you can better explain it all.
> 
> Fair enough.  But the amount each student is willing to take on faith varies.

It doesn't matter what they're willing to take.  You are the instructor.    In due time you will make all things known.  For now they need to just shut up and do what they're told.

Yes, standardized education for nice little standardized children!

> Some will accept pretty much anything as magic, while others want to know
> how a function call works mechanically (or in some cases conceptually, if
> they're math geeks) before they feel comfortable actually calling functions.

I have seen many different kids from all three ends of this triangular spectrum do just fine with Java.  I got curious and started experimenting with it, trying to make my own classes at month 4. Eventually I figured out how they worked syntactically so I could use multiple classes in my programs (the files were getting too big for my tastes, I just wanted to split stuff up).  Later on the explanation of why and how they worked came and I had this great big "ah hah!" moment and I was ruined as  a Java pro ever since.  It's been four long years of deprogramming myself to get off of Java, so I'm doing well.  ;-)

Not sure why you dont give them a overview lecture on a number of languages, C, D, Java, Python, PHP, Javascript.

Then send them off to produce a simple program - hello world + count to 10 etc. in as many of the langauges as possible. - Then get feedback from the students on what they would prefer to learn about.... - Student focused teaching tends to work better...

Regards
Alan

Nicolas Sicard wrote:
> Hi,
> 
> I am new to D, and I think I have discovered a programming language close to my ideal one...
> 
> On the web site, it is said: "Who D is Not For [...] As a first programming language - [...] Java is more suitable for beginners.".
> Is this based on experience?
> 
> I am a teacher in a field where my students don't know what a programming language is! I need a language for a first approach of programming. I would say that Pascal, or BASIC even if a bit outdated, or even D would fit, but not Java.
> 
> I can imagine my first lesson with Java:
> 
>     public class HelloWorld {
>         public static void main(String[] args) {
>             System.out.print("Hello world!");
>         }
>     }
> 
> I would have to explain what a class is. What a method is. What a public or private visibility means. What a static method is. What the dots in "System.out.print" mean... :) Then how to compile it. Why you can't run it without a virtual machine. A virtual what?
> 
> It seems the main argument why Java is a good first language is that it lacks complexity (namely C++ complexity). I think it also lacks simplicity for absolute beginners. D can be both simple and complex, and it shares other features with Java that could make it a language for beginners: object-oriented, no pointers necessary, garbage collection, strict type checking, portable...
> 
> What feature would make D a worse choice than Java for a first language?
> 
> Nicolas

Sean Kelly wrote:
> The typical approach to this tends to be "just put this stuff in the file and ignore it--I'll explain it later.  I never understood why this is considered a good teaching method :-)

Because it lets you create toys without understanding, and thus gets you interested without you expending significant effort.

Alan Knowles:
> Not sure why you dont give them a overview lecture on a number of
> languages, C, D, Java, Python, PHP, Javascript.
> Then send them off to produce a simple program - hello world + count to
> 10 etc. in as many of the langauges as possible. - Then get feedback
> from the students on what they would prefer to learn about.... - Student
> focused teaching tends to work better...

I have done that (but not with so many languages) to students of molecular biology, and the answer was: Python! ;-)

Bye,
bearophile

== Quote from Christopher Wright (dhasenan@gmail.com)'s article
> Sean Kelly wrote:
> > The typical approach to this tends to be "just put this stuff in the file and ignore it--I'll explain it later.  I never understood why this is considered a good teaching method :-)
> Because it lets you create toys without understanding, and thus gets you interested without you expending significant effort.

Agreed, though I wouldn't necessarily phrase it in a way that smacks of intellectual laziness.  Personally, I've always felt that I learn much more quickly and much more thoroughly when I get to try to do something (preferably useful) with my new knowledge as I'm learning, even if my understanding is fairly shaky, rather than being forced to learn all the minutiae/background/theory before trying to use any of what I've learned.  For example, I would *never* read a book about a new programming language cover to cover before trying to write something in it.  I would probably skim the first chapter or two, try to do a project in it, use the book as a reference, and then read the book cover to cover later to learn some better ways of doing things after I'd gotten my hands dirty a little.

I feel that once I've actually tried to use a new piece of knowledge, I have a *much* better idea of what, specifically, I still don't get, and can ask much more intelligent questions than if I'm forced to learn large amounts of stuff passively from lectures/books before getting my hands dirty with any of it.  Furthermore, learning this way also makes it much easier for me to see how things fit into the bigger picture.  Not sure if this is universal, or just a personal preference.

"dsimcha" <dsimcha@yahoo.com> wrote in message news:gbrvb5$cdt$1@digitalmars.com...
> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>> Sean Kelly wrote:
>> > The typical approach to this tends to be "just put this stuff in the file and ignore it--I'll explain it later.  I never understood why this is considered a good teaching method :-)
>> Because it lets you create toys without understanding, and thus gets you interested without you expending significant effort.
>
> Agreed, though I wouldn't necessarily phrase it in a way that smacks of
> intellectual laziness.  Personally, I've always felt that I learn much
> more
> quickly and much more thoroughly when I get to try to do something
> (preferably
> useful) with my new knowledge as I'm learning, even if my understanding is
> fairly
> shaky, rather than being forced to learn all the
> minutiae/background/theory before
> trying to use any of what I've learned.  For example, I would *never* read
> a book
> about a new programming language cover to cover before trying to write
> something
> in it.  I would probably skim the first chapter or two, try to do a
> project in it,
> use the book as a reference, and then read the book cover to cover later
> to learn
> some better ways of doing things after I'd gotten my hands dirty a little.
>
> I feel that once I've actually tried to use a new piece of knowledge, I
> have a
> *much* better idea of what, specifically, I still don't get, and can ask
> much more
> intelligent questions than if I'm forced to learn large amounts of stuff
> passively
> from lectures/books before getting my hands dirty with any of it.
> Furthermore,
> learning this way also makes it much easier for me to see how things fit
> into the
> bigger picture.  Not sure if this is universal, or just a personal
> preference.

I'm not sure if that's universal either, but I suspect that it is (excapt maybe for some rare fringe cases). At the very least, I can say that my mind works that way too.