www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Java as a first programming language

reply Nicolas Sicard <dransic free.fr> writes:
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
Sep 28 2008
next sibling parent Matt <matt matt.matt> writes:
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?


Given the described target audience, I would suggest Python or Ruby as the
first language. Even D might have too much initial knowledge to gain for them.

Matt
Sep 28 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Nicolas Sicard:

 What feature would make D a worse choice than Java for a first language?


Choosing the "right" language to teach programming is difficult. Once Pascal
(or Logo for young ones) was a safer bet (but even in the past Scheme was
present and not bad). The first thing to ask is what's the age of your students.
If they are very young then D is unfit and Python/NetLogo/etc are probably
better.

If they are college students then Java isn't that bad choice, because it has
uniform syntax, very few special cases, works well, it's the most used language
in the world, it has tons of libs, IDEs, you can find lot of books, lot of
answers and docs on the net, the HotSpot today runs programs quite quickly, and
so on. So it's a rigid, boring language that makes you write very long
programs, but it has its advantages.

D is less safe, it doesn't have a really standard library yet, and compared to
Java no one uses it, and no one uses it to work (compared to java still), and
the compilers have lot of bugs still, so after your courses the things they
know become less useful for them, and you they have more problems producing
working programs.

To be truth, I think D is a nice language, but it's closer to the CPU than
languages like Python and Java. This has both downsides and upsides. If your
students don't know any other language, I think D is too much complex (it's a
system language still).

Scheme is nice, but it makes you go mad a little.

New languages like Clojure, Scala, ecc too are nice, but too much unripe yet.

So beside asking the age of your students, a second important question to ask
you is the kind of things you want to teach, and the kind of students you have.
If your purpose is to teach just programming, then Java may be better. If your
purpose is to teach some math too, to think in a flexible way, logical
thinking, recursivity, functional programming, parallel thinking, and so on,
then maybe Scheme is a better choice, despite it's almost useless compared to
Java.

If your purpose is to teach lot of programming with the minimal problems, then
probably a language like Python is better. When they know Python then they can
learn C or Java or even some basics of Haskell...

If you answer those two questions I can give you a better answer.

Bye,
bearophile
Sep 28 2008
next sibling parent reply Nicolas Sicard <dransic free.fr> writes:
bearophile a =C3=A9crit :

 Nicolas Sicard:
  =20

 What feature would make D a worse choice than Java for a first languag=




e?

    =20


 Choosing the "right" language to teach programming is difficult. Once P=


ascal (or Logo for young ones) was a safer bet (but even in the past Sche=
me was present and not bad). The first thing to ask is what's the age of =
your students.

 If they are very young then D is unfit and Python/NetLogo/etc are proba=


bly better.

 If they are college students then Java isn't that bad choice, because i=


t has uniform syntax, very few special cases, works well, it's the most u=
sed language in the world, it has tons of libs, IDEs, you can find lot of=
 books, lot of answers and docs on the net, the HotSpot today runs progra=
ms quite quickly, and so on. So it's a rigid, boring language that makes =
you write very long programs, but it has its advantages.

 D is less safe, it doesn't have a really standard library yet, and comp=


ared to Java no one uses it, and no one uses it to work (compared to java=
 still), and the compilers have lot of bugs still, so after your courses =
the things they know become less useful for them, and you they have more =
problems producing working programs.

 To be truth, I think D is a nice language, but it's closer to the CPU t=


han languages like Python and Java. This has both downsides and upsides. =
If your students don't know any other language, I think D is too much com=
plex (it's a system language still).

 Scheme is nice, but it makes you go mad a little.

 New languages like Clojure, Scala, ecc too are nice, but too much unrip=


e yet.

 So beside asking the age of your students, a second important question =


to ask you is the kind of things you want to teach, and the kind of stude=
nts you have. If your purpose is to teach just programming, then Java may=
 be better. If your purpose is to teach some math too, to think in a flex=
ible way, logical thinking, recursivity, functional programming, parallel=
 thinking, and so on, then maybe Scheme is a better choice, despite it's =
almost useless compared to Java.

 If your purpose is to teach lot of programming with the minimal problem=


s, then probably a language like Python is better. When they know Python =
then they can learn C or Java or even some basics of Haskell...

 If you answer those two questions I can give you a better answer.

 Bye,
 bearophile
  =20


They are college students. They are biologists and most of them won't=20
need programming skills after they graduate.

I really don't think D is necessarily more complex (though it surely can =

be). Pascal was as close to the CPU than D, and about as safe, wasn't=20
it? But the poor documentation on the net compared to Java is the best=20
point, I think. As could be the small audience, and the stability.

I think Python is the right alternative: large audience and docs, easy=20
for beginners, libs designed for biological science are available... I=20
just need to start learning it myself ;-)=20

Thanks for the answers

Nicolas
Sep 28 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nicolas Sicard:

 They are college students. They are biologists and most of them won't 
 need programming skills after they graduate.


Then D is probably a bit too much complex for them. They can surely learn it,
but probably there are better languages for them.

But remember that students aren't all the same. Each one has a different
mindset/brain, so probably for some of them Scheme is better, for some other
C/Pascal/D are maybe fitter, and so on. There are many kinds of languages not
just because problems are different, but also because the brain of the
programmers is different, and such differences are often present in student
brains already :-)



 I really don't think D is necessarily more complex (though it surely can 
 be). Pascal was as close to the CPU than D, and about as safe, wasn't 
 it?


I think modern ObjectPascals, like FreePascal, are a little safer than D still,
but the difference isn't much, I think. Java is safer than both.



 and the stability.


The stability isn't much of a problem, I think.



 I think Python is the right alternative: large audience and docs, easy 
 for beginners, libs designed for biological science are available... I 
 just need to start learning it myself ;-)


For them Python is probably one of the the best things, then. There are lot of
people that use Python for biology, me too. But note that I also use D for
bioinformatics, mostly because sometimes Python is too much slow. But your
students have to learn programming first, so performance is not important.



 I just need to start learning it myself ;-)


Few months may suffice. You need a good large book on it. There's the newsgroup
too, where you can ask things.

Bye,
bearophile
Sep 28 2008
prev sibling parent torhu <no spam.invalid> writes:
Nicolas Sicard wrote:
  > I think Python is the right alternative: large audience and docs, easy

 for beginners, libs designed for biological science are available... I 
 just need to start learning it myself ;-) 
 


Don't forget about the ability to be used interactively. Check out IDLE, 
the interactive IDE that comes with the standard Python download.
Sep 28 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 So beside asking the age of your students, a second important
 question to ask you is the kind of things you want to teach, and the
 kind of students you have. If your purpose is to teach just
 programming, then Java may be better. If your purpose is to teach
 some math too, to think in a flexible way, logical thinking,
 recursivity, functional programming, parallel thinking, and so on,
 then maybe Scheme is a better choice, despite it's almost useless
 compared to Java.


That's a very good point. If my students intended to become top 
professionals and had a keen interest, I'd start them with assembler, 
and follow up with D. If they were 9 year old kids wanting to toy 
around, I'd probably start with a language with instant gratification, 
like javascript.
Sep 28 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 bearophile wrote:

 So beside asking the age of your students, a second important
 question to ask you is the kind of things you want to teach, and the
 kind of students you have. If your purpose is to teach just
 programming, then Java may be better. If your purpose is to teach
 some math too, to think in a flexible way, logical thinking,
 recursivity, functional programming, parallel thinking, and so on,
 then maybe Scheme is a better choice, despite it's almost useless
 compared to Java.


 
 That's a very good point. If my students intended to become top 
 professionals and had a keen interest, I'd start them with assembler, 
 and follow up with D. If they were 9 year old kids wanting to toy 
 around, I'd probably start with a language with instant gratification, 
 like javascript.


Also, different people learn best in different ways.  Some can't focus 
on high-level issues unless they understand what's going on under the 
covers, while others are the opposite.  If I were to design a curriculum 
I'd suggest the bottom-up approach (ie. architecture to assembler to D), 
but leave students the option of doing the reverse as well.  At least 
insofar as these first few courses are concerned.


Sean
Sep 28 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 bearophile wrote:

 So beside asking the age of your students, a second important
 question to ask you is the kind of things you want to teach, and the
 kind of students you have. If your purpose is to teach just
 programming, then Java may be better. If your purpose is to teach
 some math too, to think in a flexible way, logical thinking,
 recursivity, functional programming, parallel thinking, and so on,
 then maybe Scheme is a better choice, despite it's almost useless
 compared to Java.


 That's a very good point. If my students intended to become top 
 professionals and had a keen interest, I'd start them with assembler, 
 and follow up with D. If they were 9 year old kids wanting to toy 
 around, I'd probably start with a language with instant gratification, 
 like javascript.


 
 Also, different people learn best in different ways.  Some can't focus 
 on high-level issues unless they understand what's going on under the 
 covers, while others are the opposite.  If I were to design a curriculum 
 I'd suggest the bottom-up approach (ie. architecture to assembler to D), 
 but leave students the option of doing the reverse as well.  At least 
 insofar as these first few courses are concerned.
 
 
 Sean


Starting programming in C/C++ without having assembler or processor 
architecture knowledge is indeed probably not the best. But truly 
high-level languages should shield (abstract) you from that, so that you 
can start programing right away without having to learn a lot of 
low-level stuff first.

In my university, the curriculum is designed so that one starts learning 
from both ends (top and bottom). The first semester has an introductory 
programming course with Scheme where you learn the basics of programming 
and data abstraction, and on the other end a Digital Systems course 
(flip-flops and boolean logic, not yet programming). On the second 
semester the students have courses on assembler programming (and 
microprocessor architecture), and on C programming. Only on the third 
one there is a course about Java and Object Oriented programming.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 06 2008
prev sibling next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Nicolas Sicard wrote:


 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 think Python replaced Pascal and BASIC in the succession of horrible
languagues that you learn in school and are hard to unlearn later...

Should be great for non-programmers. ;-)
--anders
Sep 28 2008
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Nicolas Sicard (dransic free.fr)'s article

 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


I second the vote for Python.  I would avoid toy languages like BASIC, etc.  I
think that most people are more motivated to learn something that is directly
practical and might be directly useful outside the classroom.  Python is unique
in
that it's intuitive enough for beginners, but has enough cool stuff
(metaclasses,
list comprehension, etc.) that those who do end up programming after your class
will not outgrow it fast. Heck, even "real programmers", such as Eric Raymond,
use
and praise it.  My only real knock against it is performance, but that's not
even
a problem in most cases.

I certainly agree that Java is a terrible beginner language (and not a
particularly good language period) because it makes you jump through too many
hoops to do simple things (see your own hello world example), and yet doesn't
have
very many advanced features, such as metaprogramming, advanced programmers to
play
with.

However, D has its own problems as a beginner language.  First, although it
doesn't seem like it to someone coming from C/C++, it's a fairly close to the
metal language.  Although it's relatively easy to avoid, there is undefined
behavior.  Integers can overflow. Static typing, while necessary for high
performance and of debatable value in catching errors, isn't the most intuitive
thing in the world for a novice programmer.  Furthermore both of the common ways
to make a statically typed language more flexible (templates, polymorphism) are
probably too advanced for a first course.  Lastly, D is still fairly young, and
the occasional compiler bug or need to roll your own <insert data
structure/algorithm for which there is no decent library yet here> requires
having
some programming experience under your belt to deal with.

Having helped a few friends who were struggling with very simple (to anyone
who's
been programming for a while) assignments, it seems to me that most of the time,
programming teachers fail to explain the most basic stuff because it seems too
obvious to someone who's been programming for a while.  For example, I've known
several people to whom the whole concept of nesting just didn't make sense
until I
backed up the truck and actually explained it explicitly.  Furthermore, if the
syntax is complex, such as in a C++ class I took in high school, I've seen
students spend so much time at first thinking about the syntax that they can't
think about higher level concepts. Therefore, I think a language with simple
syntax and not too much excess stuff that makes it hard to illustrate the basics
is the way to go.
Sep 28 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Nicolas Sicard wrote:

 What feature would make D a worse choice than Java for a first language?


As languages, I argue that D is a better first choice than language. But 
I was thinking of infrastructure. D doesn't have shelves full of 
tutorial books written about it, and Java does.
Sep 28 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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?


In my experience there is a prevailing belief that students have 
difficulty with low-level issues and so it's common to begin by teaching 
high-level programming and then go on to explain what's happening behind 
the scenes.  "The Art of Assembly Language," for example, teaches 
assembly via a higher-level meta-language for this reason, and the 
decision was made based on a great deal of experience teaching students 
assembly.

Personally however, I think this approach is a mistake.  Some students 
aren't willing to overlook the "magic" and focus on high-level logic at 
the outset.  Also, I think that it's important to teach good habits at 
the outset, because re-training later is much more difficult.  Teaching 
with Java, for example, may be convenient in that it obscures most of 
the irrelevant details that plague C++ programmers--pointer errors, 
etc--but at the same time the students aren't given the opportunity to 
develop an understanding of issues that will be crucial to their success 
later on.


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


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


This is why I think D is a perfect teaching language.  It's possible to 
get very low-level by using inline assembler and writing C-style code, 
or to use objects, delegates, etc, all in the same language.  If I were 
teaching imperative programming and didn't care about the lack of 
published teaching materials I'd use D.


 What feature would make D a worse choice than Java for a first language?


Shaky debugger / IDE support and a lack of published documentation.  I 
suppose I could plug "Learn to Tango with D" here, but its target 
audience is really someone who knows at least one other imperative 
language.  An alternative would be to start with Pascal, C, or C++, 
depending on your preference of syntax, safety, and complexity.

Alternately, you could begin with a language like Lisp, Scheme, Haskell, 
Erlang, etc.  I can't see this being terribly successful if your class 
is full of would-be web designers, but it's a definite option if you're 
targeting BS Comp Sci. or Comp Engineering students.  I think it's 
generally a good idea to get a functional language in early, because 
students seem to have a lot more trouble learning them if they've 
already spent a year or two doing strictly imperative programming.


Sean
Sep 28 2008
next sibling parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
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.
Sep 28 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Sep 29, 2008 at 9:12 AM, Chris R. Miller
<lordsauronthegreat gmail.com> wrote:

 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.


You forgot the "\n" in your printf, which is another thing to explain
to the poor helpless students.

--bb
Sep 28 2008
prev sibling next sibling parent Nicolas Sicard <dransic free.fr> writes:
Chris R. Miller a =C3=A9crit :

 Sean Kelly wrote:

 Nicolas Sicard wrote:

 I am a teacher in a field where my students don't know what a=20
 programming language is! I need a language for a first approach of=20
 programming. I would say that Pascal, or BASIC even if a bit=20
 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=20
 public or private visibility means. What a static method is. What=20
 the dots in "System.out.print" mean... :) Then how to compile it.=20
 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=20
 file and ignore it--I'll explain it later.  I never understood why=20
 this is considered a good teaching method :-)


 There are so many concepts and mechanics that are at work with even=20
 the simplest Hello World in wee simple C that it's completely=20
 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=20
 concept of an include, and how the parser literally strings all the=20
 files together to create a processed source code, then how the=20
 compiler creates a new C run time in suspended animation which will=20
 then run the function main(), and how printf is supplied by the=20
 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=20
 computer is hecka dumb 'n stuff if we need to tell it where to find=20
 out how to talk through the display!  Not to mention the distinction=20
 of a constant character array, arrays in general, string literals,=20
 types, casting, return values, etc.  It's a crazy world!

 At a certain point you have to pedagogically ask the student to take=20
 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=20
sureky wouldn't teach linguistics to babies learnig to talk. I would=20
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=20
what for, but certainly not how they work. In this respect, there is=20
much to say in Java's HelloWorld, and less in C/D/Pascal's, even less in =

Python's.
Sep 29 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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
Sep 29 2008
parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
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.  ;-)
Sep 29 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Chris R. Miller wrote:

 Sean Kelly wrote:

 == Quote from Chris R. Miller (lordsauronthegreat gmail.com)'s article


 

 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.


And some will become frustrated and change majors, fail out, etc.


 Yes, standardized education for nice little standardized children!


If children were all the same then this wouldn't be a problem, as you're 
clearly aware :-)


 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.  ;-)


In my experience, students with a math background often tend to do 
better with functional languages, since the way they work is a bit 
closer to the mathematic definition--immutable variables, no global 
state, pure functions, etc.  My wife is one such person, and between 
that and her need to know the details behind how things worked before 
she could apply the concepts she was pretty much the antithesis of the 
standard approach to teaching CS.  Once she got to the more theoretical 
or low-level classes like computer architecture, algorithm analysis, 
compiler design, AI, etc, she had no problem at all.  But those first 
few programming courses were incredibly frustrating for her.


Sean
Sep 30 2008
parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Sean Kelly wrote:

 Chris R. Miller wrote:

 Sean Kelly wrote:

 == Quote from Chris R. Miller (lordsauronthegreat gmail.com)'s article



 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.


 
 And some will become frustrated and change majors, fail out, etc.


Probably a better thing for them.  If they can't deal with approaching a 
new and foreign concept by gently probing into it, they probably won't 
fare well in the rest of Computer Science as well.


 Yes, standardized education for nice little standardized children!


 
 If children were all the same then this wouldn't be a problem, as you're 
 clearly aware :-)


I have several classic quotes (of my own invention!) related to that 
topic, perhaps my favorite of which:

School is like a trash compactor: we stick our kids in and expect to 
have nice little rubbish cubes come out that stack nicely with the rest 
of the stinking trash heap we like to call "modern society."


 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.  ;-)


 
 In my experience, students with a math background often tend to do 
 better with functional languages, since the way they work is a bit 
 closer to the mathematic definition--immutable variables, no global 
 state, pure functions, etc.  My wife is one such person, and between 
 that and her need to know the details behind how things worked before 
 she could apply the concepts she was pretty much the antithesis of the 
 standard approach to teaching CS.  Once she got to the more theoretical 
 or low-level classes like computer architecture, algorithm analysis, 
 compiler design, AI, etc, she had no problem at all.  But those first 
 few programming courses were incredibly frustrating for her.


I think that part of computer science is appreciating the proverbial 
"black-box" of architecture and learning how to use an abstracted system 
that you don't know how the whole thing works.  To a degree you need to 
train yourself to ignore the dead zones in your understanding and to do 
the best with what you have.

She must be really fond of closed-source proprietary APIs that hide 
everything about their implementation, eh?  ;-)
Sep 30 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Chris R. Miller:

 Probably a better thing for them.  If they can't deal with approaching a 
 new and foreign concept by gently probing into it, they probably won't 
 fare well in the rest of Computer Science as well.


From what you say you are an awful teacher :-]
I'm glad to have had teaches way better than you.

Bye,
bearophile
Sep 30 2008
parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
bearophile wrote:

 Chris R. Miller:

 Probably a better thing for them.  If they can't deal with approaching a 
 new and foreign concept by gently probing into it, they probably won't 
 fare well in the rest of Computer Science as well.


 
 From what you say you are an awful teacher :-]


Ironically not.  Just goes to show that people with poor opinions can 
still become semifunctional members of society.  ;-)


 I'm glad to have had teaches way better than you.


Hence why I don't try and teach.  I just don't think that it's a good 
idea to force a student to learn something that they might not have any 
real aptitude with.  As my old saxophone teacher used to note, there are 
two quantities in students that make success.  The first is talent, the 
other is determination.  A student with talent and little determination 
fails, but a student with little talent and all the determination in the 
world succeeds.

I suppose I over-simplified in my original statement.  There are (many) 
more variables that I would want to factor in before recommending that 
someone continue exploring other career/hobby opportunities.
Sep 30 2008
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Chris R. Miller wrote:

 Sean Kelly wrote:

 Chris R. Miller wrote:

 Sean Kelly wrote:

 == Quote from Chris R. Miller (lordsauronthegreat gmail.com)'s article



 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.


 And some will become frustrated and change majors, fail out, etc.


 
 Probably a better thing for them.  If they can't deal with approaching a 
 new and foreign concept by gently probing into it, they probably won't 
 fare well in the rest of Computer Science as well.
 

 Yes, standardized education for nice little standardized children!


 If children were all the same then this wouldn't be a problem, as 
 you're clearly aware :-)


 
 I have several classic quotes (of my own invention!) related to that 
 topic, perhaps my favorite of which:
 
 School is like a trash compactor: we stick our kids in and expect to 
 have nice little rubbish cubes come out that stack nicely with the rest 
 of the stinking trash heap we like to call "modern society."
 

 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.  ;-)


 In my experience, students with a math background often tend to do 
 better with functional languages, since the way they work is a bit 
 closer to the mathematic definition--immutable variables, no global 
 state, pure functions, etc.  My wife is one such person, and between 
 that and her need to know the details behind how things worked before 
 she could apply the concepts she was pretty much the antithesis of the 
 standard approach to teaching CS.  Once she got to the more 
 theoretical or low-level classes like computer architecture, algorithm 
 analysis, compiler design, AI, etc, she had no problem at all.  But 
 those first few programming courses were incredibly frustrating for her.


 
 I think that part of computer science is appreciating the proverbial 
 "black-box" of architecture and learning how to use an abstracted system 
 that you don't know how the whole thing works.  To a degree you need to 
 train yourself to ignore the dead zones in your understanding and to do 
 the best with what you have.
 
 She must be really fond of closed-source proprietary APIs that hide 
 everything about their implementation, eh?  ;-)



Somehow my sarcasm senses tickle. Somehow.
Sep 30 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Chris R. Miller wrote:

 
 I think that part of computer science is appreciating the proverbial 
 "black-box" of architecture and learning how to use an abstracted system 
 that you don't know how the whole thing works.  To a degree you need to 
 train yourself to ignore the dead zones in your understanding and to do 
 the best with what you have.


Agreed.  It may have simply been an issue for her because she was in a 
learning environment and so had different expectations than she would 
have otherwise.


 She must be really fond of closed-source proprietary APIs that hide 
 everything about their implementation, eh?  ;-)


*snicker* :-)


Sean
Sep 30 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Sep 29 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Sep 29 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Sep 29 2008
parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:

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


Same.
I don't even use books very much, if at all.
Examples + reference material + experience.  It seems to be my killer 
strategy.
Sep 29 2008
prev sibling next sibling parent reply Janderson <ask me.com> writes:
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


On of the nice things about D is that its a multi-paradigm language. 
That is it has a bit of everything in it.  That should make for learning 
other languages easier once one knows D.  Also hello world is a lot 
simpler in D:

import std.stdio;

void main(string[] args)
{
	writefln("Hello World!");
}

I think you could craft tutorials that have small enough steps to make D 
a very easy language to learn.

-Joel
Sep 28 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Janderson <ask me.com> wrote:


 On of the nice things about D is that its a multi-paradigm language.  
 That is it has a bit of everything in it.  That should make for learning  
 other languages easier once one knows D.  Also hello world is a lot  
 simpler in D:

 import std.stdio;

 void main(string[] args)
 {
 	writefln("Hello World!");
 }

 I think you could craft tutorials that have small enough steps to make D  
 a very easy language to learn.

 -Joel


Actually, you can make hello world even simpler:

void main()
{
   printf("Hello World!");
}

-- 
Simen
Sep 28 2008
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Simen Kjaeraas wrote:


 Actually, you can make hello world even simpler:
 
 void main()
 {
   printf("Hello World!");
 }


You seem to be missing an import std.c.stdio; there...
Can't count on Object being buggy* like that forever ? ;-)

Or you could use an alternative declaration, like:
version(Tango) extern (C) int printf(char *, ...);

--anders


* http://www.digitalmars.com/d/archives/digitalmars/D/bugs/5838.html
Sep 28 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
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.
Sep 29 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message 
news:mailman.260.1222678473.19733.digitalmars-d puremagic.com...

 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.



I've also worked as a CS tutor at a college. We had two instructors (Mr. A, 
and Ms. B - because I honestly don't even remember their names anymore) that 
taught the intro to programming class (also taught in Java - which I still 
consider to have been a mistake). The number of students I got from each 
class was about half and half.

Mr. A would always start teaching with basic sequential statements (this 
line happens, then the next, then the next, etc.), then conditionals, then 
loops, then functions, and only *then* did he start getting into classes and 
OO. Literally every time I got a student from his class, it was clear that 
they understood the material, and they confessed they were only coming to 
see me just to double-check their work (which was overall pretty good).

Ms. B (a real nut, she wouldn't stop reminding everyone that she'd had 
experience "in the real industry" - yea, so what, who hasn't? Even I had at 
that point, and I was a student), for some reason that had always been 
completely beyond my comprehension, she always *started* these first-time 
programmers on classes and OO. Only *after* that would she get to anything 
else, such as basic flow of execution. Literally every time I got one of her 
students, they were *so* completely confused and clueless that the only way 
I could have helped them would be to either re-teach them from scratch with 
a full course curriculum of my own, or just send them back to their teacher.

So you definitely don't want to start too high-level. But, I would never 
teach a first-time programmer by starting at computer architecture and 
assembly (unless perhaps if they were coming from a strong EE background). 
Beginners need to start with simplicity. That rules out both OO and Asm:

OO is ruled out because OO is a style of code architecture (not a type of 
language) and code architecture is meaningless without understanding the 
basics of the language, and in the case of Java this means "imperative 
programming". Starting with OO is like teaching algebra before arithmetic. 
You can't understand one without first understanding the other.

Asm is ruled out because it's too complex and technical, and in many cases a 
full understanding is not strictly needed (although it can always help, I do 
recommend it be learned eventually). Plus it's very dull for a beginner. 
Starting with Asm is like teaching formal logic before moving on to basic 
arithmetic, or teaching quantum mechanics before moving on to chemistry and 
Newtonian physics. Yes, one is built on the other, but the lower-level is of 
somewhat less relevance (wrong level of abstraction), and the higher-level 
is far easier to grasp.

So basically, the high-level, OO, is too high-level to start at because it's 
too complex, and the low-level, computer architecture and Asm, is too 
low-level to start at because it's also too complex.

The way to go (at least for imperative languages):
- Basic text output using one statement
- Basic text output using multiple statements
- Assignments
- Conditionals
- Loops
- High/Low number guessing game (I've always thought this deserves the same 
status as "Hello World")
- Functions
- Other stuff, such as classes or binary, or anything else needed before 
getting to classes or binary.
Sep 29 2008
prev sibling parent Nicolas Sicard <dransic free.fr> writes:
Jarrett Billingsley a =C3=A9crit :

 On Sun, Sep 28, 2008 at 8:03 AM, Nicolas Sicard <dransic free.fr> wrote=


:

  =20

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




ic 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 ru=




n it

 without a virtual machine. A virtual what?
    =20


 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.
  =20


Well, I have also experienced that curly braces, and specifically=20
visualizing their nesting levels, is a hard thing for some of the novice =

programmers. Pascal's begin/end were a lot more expressive. Maybe=20
Python's syntax is more beginner-friendly.
So OO is not for tomorrow ! :-)
Sep 29 2008
prev sibling next sibling parent "Tim M" <a b.com> writes:
I like two programming languages a lot: D and Jade. I dont prefer one of  
the other I think they each are very good depending on what you are trying  
to do. I think D is not that easy to start with but I think java is much  
worse. Have you ever tried Jade. I recently started jadeprogramming.com  
back in June for people like you. It doesnt have much but it has one  
tutorial vid on there at the moment. An example easy to understand jade  
code:

vars
    s : String;
begin
    read s;
    write 'You entered: ' & s;
end;



PS dont confuse Jade with the Java Agent DEvelopment Framework. The jade  
im talking about is this  
http://en.wikipedia.org/wiki/JADE_(programming_language).
Sep 29 2008
prev sibling next sibling parent ore-sama <spam here.lot> writes:
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.
Sep 29 2008
prev sibling next sibling parent reply Alan Knowles <alan akbkhome.com> writes:
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
Sep 29 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Sep 29 2008
prev sibling next sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Hmmmm, now this may be of zero interest to the OP, but I the appearance 
of yet another programming pedagogy thread has caused me to spawn a 
crazy idea.

Disclaimer:  This is probably a bad idea.

So what if one of the ways to institutionally teach beginning 
programming was to just institutionalize the way I learned how to 
program?  You set up an Ultima Online server.  Customize it to cater to 
macroing/botting.  So it's kind of like robocode, but more RPGish and 
with some obligatory grindy numerical crap that has to be done before 
you are actually good at the game.

First of all, make sure the students coming in actually want to play 
games, namely an RPG style game, and if they don't send them to the 
bland boring typical programming classes.

The first few days of class are spent familiarizing the students with 
the game.  At this stage the instructor is mostly an admin as well as a 
player that helps other players out.  The students/players are allowed 
to play the game with relatively weak characters that should nonetheless 
be able to handle some fun canned activities.  They should also have 
some harrowing encounters.  You know; teach them their limits.  During 
this time the students will ideally gain some kind of personal 
attachment to their avatars and become assimilated into whatever kind of 
token economy might be deemed appropriate.

I suppose I should mention that you can safely assume that the students 
haven't played this particular incarnation of the game and that you can 
safely used canned quests and such.  It will all be novel to them.

After the first few days of the students being the squishy mortals they 
are, show them the power of programming.  Have them use a simple easyuo 
script like this overnight:

top:
; Hide every 10 seconds.
event macro 13 21
wait 10s
goto top

By repeatedly hiding every 10 seconds the player's character will 
develop hiding skill.  Run this overnight and you will likely have 100.0 
(maxed) hiding skill.  Now, hiding isn't an uber powerful skill that 
allows them to kill everything with the flick of a wrist, but it is 
useful.  This is good: you don't want to give everything away all at 
once.  Teach the students how to, in a pinch, run and hide, thus 
granting them invisibility to the AI mobs.  Given a low latency 
connection (school network?) and maxed hiding skill, they will be 
extremely hard for the AI to kill.  Now they are untouchable, but still 
poor at killing or very much else in the game.  That's good, they still 
have a reason to improve their programming skills.

Also, for reference, the less useful "hello world" script:

msg Hello world!$

Which makes the player's character say "Hello world!"
Yep. One liner.  The $ tells the computer to hit the enter key.

You're probably also glaring at that goto.  Heresy, isn't it.  But hey, 
goto is much easier to understand than functions.  It fits nicely with 
the idea of execution flow.  You can say that goto is horrible 
programming practice and hard to debug, and you'll be right, but the 
alternative is harder to teach at first.

At this point hopefully they've been using bandages to heal.  Hopefully 
they are also frustrated.  They have to move their mouse into their 
backpack, double click the bandages, then double click their 
character/healthbar every time they want to recover some precious hp. 
This just won't do.  So you have them write a macro to, on the press of 
a key, automatically find bandages in the backpack, use them, and begin 
applying them to self.  The solution looks somewhat like this:

hotkeyloop:
; poll for the key press.  It need not be only ctrl-shift-e.
onhotkey e ctrl shift
     goto heal
goto hotkeyloop

heal:
; Find a bandage.
finditem ZLF

; Use it.
set #lobjectid #findid
event macro 17

; Wait for targetting cursor to appear.
; If it takes longer than 2 seconds, give up.
target 2s

; Target self.
event macro 23

; done.
goto hotkeyloop

Hey, we have some branching and now the notion of variables.  The 
variables are #lobjectid and #findid.  They are builtins, and "set" is 
the assignment operator.  Teach it.
More gotos.  Deal with it.  It will get uglier in a bit, and that will 
probably be a good thing, ironically enough.

(Note: Last time I tried, onhotkey doesn't work with UO under Wine on 
Linux.)

Now for some magery.  They'll go from killing lowly rats and orcs to 
slaying dragons with this one.

top:
if #MANA = #INT
     goto cast
if #MANA < #INT
     goto med

med:
event macro 13 46
wait 4s
if #MANA < #INT
     goto med
if #HITS < #STR
     goto heal
if #MANA = #INT
     goto cast

cast:
event macro 15 41
target 4
event macro 23
wait 1s
if #MANA = #INT
     goto cast
goto heal

heal:
wait 1s
Finditem WKORQQD
set #LOBJECTID #FindID
event macro 17
target 2s
event macro 23
wait 1s
goto top

We start to see some if statements here, comparison operations, and a 
slightly more complicated program.
To be honest, I just grabbed this one from my old dusty collection of 
macros I've used at some point.  I have forgotten what WKORQQD is. 
event macro 15 41 casts energy bolt.  Other spells may be needed to 
level if the shard is set up differently.  Setting it up to keep it this 
simple is probably a good idea.  event macro 13 46 does meditation. 
This will train the auxiliary skills for magery too.
Maybe give them a skeleton program of this and possibly some bugs too. 
Fun with goto debugging.

For those that care, I haven't mentioned melee skills.  Those are harder 
to macro.  Just do magery.

You're still reading this?  Are you mad?

At about this point it's time to introduce EasyUO's subroutine feature, 
which is pretty much just functions.  Now they can ditch gotos.  Perhaps 
  switch goto loops out for while loops as the way to do a main loop. 
EUO seems to have most of the good structured programming constructs.
Before jumping directly into functions, it may be possible to goad the 
students into writing functions using goto primitives and thus teach 
low-level concepts like a call stack and a return address.  I'm not sure 
how much of a good idea this is.  I know I was writing functions this 
way before I know what functions were.  Then I learned, and sploited.

At this point they have some ?optional? assignments:
- There are nice builtin variables for things like #HEALTH.  EasyUO can 
also read messages displayed on the player's screen.  With these two 
things in hand, and a solid grasp of conditionals, control flow, 
variables, etc, it is possible to write a macro that does healing 
automatically.  No need to press a button.  It just continuously strives 
to keep the player at full health.
- Make another character.  A "mule" character.  Now make a macro to max 
out alchemy skill, so that the player can make potions.
- Make a macro that automatically chugs cure potions when the character 
is afflicted with the poison status.
- Make a macro that can max out 
tailoring/blacksmithy/carpentry/tinkering/mining on the mule character.
- Encourage classmates to share.
Welcome to teamwork.  Perhaps mandate that the students do all of these 
collectively as a class.  They will get first hand experience with the 
multiplicity of human programmers and how awesome it is.  Oh hey Linux 
Kernel, the might of mankind's giant programmer swarm is pretty cool huh?

Now perhaps we can get tricky.  Melee skills were ignored.  Perhaps this 
can be rectified.  Even though everyone is a mage just having maxed 
wrestling skill will be a valuable asset defensively.  Currently when a 
monster attacks them they get hit %100 of the time.  Maxed wrestling 
skill drops that to %50.  Alternatively, the student may opt to build a 
melee character (they should probably keep their mage, it's useful).
So how to max melee skills?
The macro-able way requires two characters to spar with each other until 
both are maxed out.  This is nontrivial.  The combatants will have to 
disengage when their partner is too low on health, or they will kill the 
partner and it's game over.  This may require the characters to move 
away from each other, and as such the macro must be vaguely aware of 
position.  Weapons degrade over time, so the macro will have to 
periodically equip a new weapon as old ones break.  The characters can 
heal themselves using the self-heal, but healing each other is 
considerably faster.  Heal self takes 10 seconds.  Heal other takes 4. 
Just how bad this is can be tweaked on server side (e.g. don't make 
weapons degrade over time).
At this point we can introduce the concept of finite state machines.  At 
some level most of these macros were just FSMs to begin with, but this 
is probably a good time to formalize the idea and begin exploiting it in 
earnest.  Writing this sparring macro as an FSM is probably a good idea.
This may also involve arrays.
It might also be good to mention the applicability of FSMs outside of 
this, such as in regular expressions.

Now if we really want to cement these concepts, we can have the students 
attempt to write AIs for their characters.  They'd probably be Player vs 
Player (PvP) or Player vs Mobile/Monster (PvM) AIs.  And by that I mean 
combat AIs.  The really nice thing about this is that the students will 
be able to replace a lot of their tasks in the game as a human being 
with things that their program can do.  They may even be able to run 
multiple AIs at once, thus multiplying their capabilities.  This 
realization and ability is quite an awesome experience.  It's probably 
doable in this setup too.  Of course, they'll probably need some 
guidance, and if fully autonomous AIs are too tough then there's plenty 
of room to expand on automatic healing/curing and construct a more 
robust part-man-part-machine kind of combat system.  Either way this is 
just damned cool.

That's about as far ahead as I've thought on this.

At one point my nephew wanted to learn how to do some EasyUO macroing to 
help him play UO.  My time was short, so in about 3 hours I taught him 
about 2-4 weeks of introductory computer science material.  He quickly 
realized this was more work than he thought it would be, and he seemed 
pretty wide-eyed by the end of the experience, but he did seem to learn 
and in a remarkably short period of time become something of a 
programmer.  So maybe there is something to this.

Notably, the topics covered by this will probably be different from a 
normal introductory course.  Finite state machines are covered, while 
user-defined types are not.  OOP is not covered here.

Pros:
- Fun factor.  The students are more likely to have unnaturally high 
levels of motivation during this course.
- Shock value.  It only takes a few lines of code at a time for the 
student to profit something fierce.

Cons:
- EasyUO is not a useful language outside of playing UO.
- Time spent on non-programming things.  Also, addiction.
- Differences with usual curriculum.  Non transferability of course 
credits.
- EA Games' rights to artwork in the UO Client.
- Has anyone even done this kind of thing before?

A couple of the problems can be solved with investment in a new UO 
client and macro language.  Of course, using existing RunUO server 
technology for the game server is probably a good idea.

Links:
High quality, free/open source UO server: 

The EasyUO main site: http://www.easyuo.com/
EasyUO documentation: http://wiki.easyuo.com/index.php/Documentation
Ultima Online site: http://www.uoherald.com/news/

OK, I've had my fun for the night.  Later.
- Chad
Sep 29 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Chad J" <gamerchad __spam.is.bad__gmail.com> wrote in message 
news:gbs393$j44$1 digitalmars.com...

 Hmmmm, now this may be of zero interest to the OP, but I the appearance of 
 yet another programming pedagogy thread has caused me to spawn a crazy 
 idea.

 Disclaimer:  This is probably a bad idea.

 So what if one of the ways to institutionally teach beginning programming 
 was to just institutionalize the way I learned how to program?  You set up 
 an Ultima Online server.  Customize it to cater to macroing/botting.  So 
 it's kind of like robocode, but more RPGish and with some obligatory 
 grindy numerical crap that has to be done before you are actually good at 
 the game.

 First of all, make sure the students coming in actually want to play 
 games, namely an RPG style game, and if they don't send them to the bland 
 boring typical programming classes.

 The first few days of class are spent familiarizing the students with the 
 game.  At this stage the instructor is mostly an admin as well as a player 
 that helps other players out.  The students/players are allowed to play 
 the game with relatively weak characters that should nonetheless be able 
 to handle some fun canned activities.  They should also have some 
 harrowing encounters.  You know; teach them their limits.  During this 
 time the students will ideally gain some kind of personal attachment to 
 their avatars and become assimilated into whatever kind of token economy 
 might be deemed appropriate.

 I suppose I should mention that you can safely assume that the students 
 haven't played this particular incarnation of the game and that you can 
 safely used canned quests and such.  It will all be novel to them.

 After the first few days of the students being the squishy mortals they 
 are, show them the power of programming.  Have them use a simple easyuo 
 script like this overnight:

 top:
 ; Hide every 10 seconds.
 event macro 13 21
 wait 10s
 goto top


...trimmed...

 OK, I've had my fun for the night.  Later.
 - Chad


 [*Skims over most and nods head*] I think looking at how good programmers 
learned is a great way to find perspective on how to teach programming.

And yes, a great thing to do is to show them right away how code can be 
useful and/or fun. Otherwise most of them will gloss over they way they 
usually do when introduced to something like algebra. Your idea would 
probably be great for people that are into hardcore RPGs (table-top or 
electronic). It shows them right from the start that programming is all 
about automating repetitive, but useful, tasks. And right away it gives them 
that feeling of power.

In a similar, but somewhat more general sense, I've always thought game 
development with a game-oriented tool like BlitzBasic or Torque2D is a great 
way to get people started in programming without immediately loosing their 
interest. Similarly, I've always felt that "High/Low number guessing game" 
should be every bit as quintessential as "Hello World" for people learning 
on something that leans heavily text-based (or, heck, even for the 
game-oriented systems like the ones I mentioned above).

Also, I learned a lot by typing in BASIC programs (many of them were games) 
from old library books, debugging the inevitable typos, and then customizing 
it by making changes and seeing how those changes affect the overall 
program. I think simulating that environment could be of great benefit to 
beginners, particularly the "making your on changes to a simple existing 
program." Among other benefits, this gives them positive early exposure to 
samples of "how code should look", and the skill of reading other people's 
code.

Another thing from my own programming past that I think is really good is 
the interactive tutorial. My very, very first coding experiences (and 
computer experiences in general) were from the AppleSoft BASIC, LOGO, and 
"Getting started" tutorial discs that came with the Apple IIc. I'm very 
surprised that twenty years later we still see very little of that sort of 
thing (Books and group lectures are very 1800's by comparison).
Sep 29 2008
prev sibling next sibling parent David Gileadi <foo bar.com> writes:
Chad J wrote:

 Hmmmm, now this may be of zero interest to the OP, but I the appearance 
 of yet another programming pedagogy thread has caused me to spawn a 
 crazy idea.
 
 Disclaimer:  This is probably a bad idea.
 
 So what if one of the ways to institutionally teach beginning 
 programming was to just institutionalize the way I learned how to 
 program?  You set up an Ultima Online server.  Customize it to cater to 
 macroing/botting.  So it's kind of like robocode, but more RPGish and 
 with some obligatory grindy numerical crap that has to be done before 
 you are actually good at the game.
 


I learned to program playing a warbots game on a Mac Classic.  I started 
by making my own robot icons and moved up to customizing and then 
programming my own bots in a calculator/assembly-like language.  My 
brother is learning to program by creating Flash movies and having a 
desire to add interactivity.  The difficulty would be formalizing this 
method of learning; it works great at your own pace but imposing a pace 
might defeat the method.

And yup, I read your whole post ;)

-Dave
Sep 29 2008
prev sibling next sibling parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Chad J wrote:

 Hmmmm, now this may be of zero interest to the OP, but I the appearance 
 of yet another programming pedagogy thread has caused me to spawn a 
 crazy idea.
 
 Disclaimer:  This is probably a bad idea.
 
 So what if one of the ways to institutionally teach beginning 
 programming was to just institutionalize the way I learned how to 
 program?  You set up an Ultima Online server.  Customize it to cater to 
 macroing/botting.  So it's kind of like robocode, but more RPGish and 
 with some obligatory grindy numerical crap that has to be done before 
 you are actually good at the game.
 
 First of all, make sure the students coming in actually want to play 
 games, namely an RPG style game, and if they don't send them to the 
 bland boring typical programming classes.
 
 The first few days of class are spent familiarizing the students with 
 the game.  At this stage the instructor is mostly an admin as well as a 
 player that helps other players out.  The students/players are allowed 
 to play the game with relatively weak characters that should nonetheless 
 be able to handle some fun canned activities.  They should also have 
 some harrowing encounters.  You know; teach them their limits.  During 
 this time the students will ideally gain some kind of personal 
 attachment to their avatars and become assimilated into whatever kind of 
 token economy might be deemed appropriate.
 
 I suppose I should mention that you can safely assume that the students 
 haven't played this particular incarnation of the game and that you can 
 safely used canned quests and such.  It will all be novel to them.
 
 After the first few days of the students being the squishy mortals they 
 are, show them the power of programming.  Have them use a simple easyuo 
 script like this overnight:
 
 top:
 ; Hide every 10 seconds.
 event macro 13 21
 wait 10s
 goto top
 
 By repeatedly hiding every 10 seconds the player's character will 
 develop hiding skill.  Run this overnight and you will likely have 100.0 
 (maxed) hiding skill.  Now, hiding isn't an uber powerful skill that 
 allows them to kill everything with the flick of a wrist, but it is 
 useful.  This is good: you don't want to give everything away all at 
 once.  Teach the students how to, in a pinch, run and hide, thus 
 granting them invisibility to the AI mobs.  Given a low latency 
 connection (school network?) and maxed hiding skill, they will be 
 extremely hard for the AI to kill.  Now they are untouchable, but still 
 poor at killing or very much else in the game.  That's good, they still 
 have a reason to improve their programming skills.
 
 Also, for reference, the less useful "hello world" script:
 
 msg Hello world!$
 
 Which makes the player's character say "Hello world!"
 Yep. One liner.  The $ tells the computer to hit the enter key.
 
 You're probably also glaring at that goto.  Heresy, isn't it.  But hey, 
 goto is much easier to understand than functions.  It fits nicely with 
 the idea of execution flow.  You can say that goto is horrible 
 programming practice and hard to debug, and you'll be right, but the 
 alternative is harder to teach at first.
 
 At this point hopefully they've been using bandages to heal.  Hopefully 
 they are also frustrated.  They have to move their mouse into their 
 backpack, double click the bandages, then double click their 
 character/healthbar every time they want to recover some precious hp. 
 This just won't do.  So you have them write a macro to, on the press of 
 a key, automatically find bandages in the backpack, use them, and begin 
 applying them to self.  The solution looks somewhat like this:
 
 hotkeyloop:
 ; poll for the key press.  It need not be only ctrl-shift-e.
 onhotkey e ctrl shift
     goto heal
 goto hotkeyloop
 
 heal:
 ; Find a bandage.
 finditem ZLF
 
 ; Use it.
 set #lobjectid #findid
 event macro 17
 
 ; Wait for targetting cursor to appear.
 ; If it takes longer than 2 seconds, give up.
 target 2s
 
 ; Target self.
 event macro 23
 
 ; done.
 goto hotkeyloop
 
 Hey, we have some branching and now the notion of variables.  The 
 variables are #lobjectid and #findid.  They are builtins, and "set" is 
 the assignment operator.  Teach it.
 More gotos.  Deal with it.  It will get uglier in a bit, and that will 
 probably be a good thing, ironically enough.
 
 (Note: Last time I tried, onhotkey doesn't work with UO under Wine on 
 Linux.)
 
 Now for some magery.  They'll go from killing lowly rats and orcs to 
 slaying dragons with this one.
 
 top:
 if #MANA = #INT
     goto cast
 if #MANA < #INT
     goto med
 
 med:
 event macro 13 46
 wait 4s
 if #MANA < #INT
     goto med
 if #HITS < #STR
     goto heal
 if #MANA = #INT
     goto cast
 
 cast:
 event macro 15 41
 target 4
 event macro 23
 wait 1s
 if #MANA = #INT
     goto cast
 goto heal
 
 heal:
 wait 1s
 Finditem WKORQQD
 set #LOBJECTID #FindID
 event macro 17
 target 2s
 event macro 23
 wait 1s
 goto top
 
 We start to see some if statements here, comparison operations, and a 
 slightly more complicated program.
 To be honest, I just grabbed this one from my old dusty collection of 
 macros I've used at some point.  I have forgotten what WKORQQD is. event 
 macro 15 41 casts energy bolt.  Other spells may be needed to level if 
 the shard is set up differently.  Setting it up to keep it this simple 
 is probably a good idea.  event macro 13 46 does meditation. This will 
 train the auxiliary skills for magery too.
 Maybe give them a skeleton program of this and possibly some bugs too. 
 Fun with goto debugging.
 
 For those that care, I haven't mentioned melee skills.  Those are harder 
 to macro.  Just do magery.
 
 You're still reading this?  Are you mad?
 
 At about this point it's time to introduce EasyUO's subroutine feature, 
 which is pretty much just functions.  Now they can ditch gotos.  Perhaps 
  switch goto loops out for while loops as the way to do a main loop. EUO 
 seems to have most of the good structured programming constructs.
 Before jumping directly into functions, it may be possible to goad the 
 students into writing functions using goto primitives and thus teach 
 low-level concepts like a call stack and a return address.  I'm not sure 
 how much of a good idea this is.  I know I was writing functions this 
 way before I know what functions were.  Then I learned, and sploited.
 
 At this point they have some ?optional? assignments:
 - There are nice builtin variables for things like #HEALTH.  EasyUO can 
 also read messages displayed on the player's screen.  With these two 
 things in hand, and a solid grasp of conditionals, control flow, 
 variables, etc, it is possible to write a macro that does healing 
 automatically.  No need to press a button.  It just continuously strives 
 to keep the player at full health.
 - Make another character.  A "mule" character.  Now make a macro to max 
 out alchemy skill, so that the player can make potions.
 - Make a macro that automatically chugs cure potions when the character 
 is afflicted with the poison status.
 - Make a macro that can max out 
 tailoring/blacksmithy/carpentry/tinkering/mining on the mule character.
 - Encourage classmates to share.
 Welcome to teamwork.  Perhaps mandate that the students do all of these 
 collectively as a class.  They will get first hand experience with the 
 multiplicity of human programmers and how awesome it is.  Oh hey Linux 
 Kernel, the might of mankind's giant programmer swarm is pretty cool huh?
 
 Now perhaps we can get tricky.  Melee skills were ignored.  Perhaps this 
 can be rectified.  Even though everyone is a mage just having maxed 
 wrestling skill will be a valuable asset defensively.  Currently when a 
 monster attacks them they get hit %100 of the time.  Maxed wrestling 
 skill drops that to %50.  Alternatively, the student may opt to build a 
 melee character (they should probably keep their mage, it's useful).
 So how to max melee skills?
 The macro-able way requires two characters to spar with each other until 
 both are maxed out.  This is nontrivial.  The combatants will have to 
 disengage when their partner is too low on health, or they will kill the 
 partner and it's game over.  This may require the characters to move 
 away from each other, and as such the macro must be vaguely aware of 
 position.  Weapons degrade over time, so the macro will have to 
 periodically equip a new weapon as old ones break.  The characters can 
 heal themselves using the self-heal, but healing each other is 
 considerably faster.  Heal self takes 10 seconds.  Heal other takes 4. 
 Just how bad this is can be tweaked on server side (e.g. don't make 
 weapons degrade over time).
 At this point we can introduce the concept of finite state machines.  At 
 some level most of these macros were just FSMs to begin with, but this 
 is probably a good time to formalize the idea and begin exploiting it in 
 earnest.  Writing this sparring macro as an FSM is probably a good idea.
 This may also involve arrays.
 It might also be good to mention the applicability of FSMs outside of 
 this, such as in regular expressions.
 
 Now if we really want to cement these concepts, we can have the students 
 attempt to write AIs for their characters.  They'd probably be Player vs 
 Player (PvP) or Player vs Mobile/Monster (PvM) AIs.  And by that I mean 
 combat AIs.  The really nice thing about this is that the students will 
 be able to replace a lot of their tasks in the game as a human being 
 with things that their program can do.  They may even be able to run 
 multiple AIs at once, thus multiplying their capabilities.  This 
 realization and ability is quite an awesome experience.  It's probably 
 doable in this setup too.  Of course, they'll probably need some 
 guidance, and if fully autonomous AIs are too tough then there's plenty 
 of room to expand on automatic healing/curing and construct a more 
 robust part-man-part-machine kind of combat system.  Either way this is 
 just damned cool.
 
 That's about as far ahead as I've thought on this.
 
 At one point my nephew wanted to learn how to do some EasyUO macroing to 
 help him play UO.  My time was short, so in about 3 hours I taught him 
 about 2-4 weeks of introductory computer science material.  He quickly 
 realized this was more work than he thought it would be, and he seemed 
 pretty wide-eyed by the end of the experience, but he did seem to learn 
 and in a remarkably short period of time become something of a 
 programmer.  So maybe there is something to this.
 
 Notably, the topics covered by this will probably be different from a 
 normal introductory course.  Finite state machines are covered, while 
 user-defined types are not.  OOP is not covered here.
 
 Pros:
 - Fun factor.  The students are more likely to have unnaturally high 
 levels of motivation during this course.
 - Shock value.  It only takes a few lines of code at a time for the 
 student to profit something fierce.
 
 Cons:
 - EasyUO is not a useful language outside of playing UO.
 - Time spent on non-programming things.  Also, addiction.
 - Differences with usual curriculum.  Non transferability of course 
 credits.
 - EA Games' rights to artwork in the UO Client.
 - Has anyone even done this kind of thing before?
 
 A couple of the problems can be solved with investment in a new UO 
 client and macro language.  Of course, using existing RunUO server 
 technology for the game server is probably a good idea.
 
 Links:
 High quality, free/open source UO server: 

 The EasyUO main site: http://www.easyuo.com/
 EasyUO documentation: http://wiki.easyuo.com/index.php/Documentation
 Ultima Online site: http://www.uoherald.com/news/
 
 OK, I've had my fun for the night.  Later.
 - Chad


I have a book written by one of the programmers in UO.  I was 
half-tempted to check out UO, but never had the time or money.  I'll 
definitely check out what looks to be an interesting potential 
pedagogical application.

Also, have you ever heard of Core War?

http://en.wikipedia.org/wiki/Core_War

A lot lower level, but I hear it's still crazy fun.

And no, I didn't really read your whole message, just sorta skimmed it.
Sep 29 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Chad J wrote:

 Hmmmm, now this may be of zero interest to the OP, but I the appearance 
 of yet another programming pedagogy thread has caused me to spawn a 
 crazy idea.
 
 Disclaimer:  This is probably a bad idea.
 
 So what if one of the ways to institutionally teach beginning 
 programming was to just institutionalize the way I learned how to 
 program?  You set up an Ultima Online server.  Customize it to cater to 
 macroing/botting.  So it's kind of like robocode, but more RPGish and 
 with some obligatory grindy numerical crap that has to be done before 
 you are actually good at the game.


In my wife's AI course the students built simulated robots which 
competed in various contests (navigate the maze fastest, etc).  I think 
it was a fun way to get students interested in the material and think 
about how to apply it in a practical manner.  This is my succinct way of 
agreeing with your idea of making courses fun for the students :-)


Sean
Sep 30 2008
next sibling parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Sean Kelly wrote:

 Chad J wrote:

 Hmmmm, now this may be of zero interest to the OP, but I the 
 appearance of yet another programming pedagogy thread has caused me to 
 spawn a crazy idea.

 Disclaimer:  This is probably a bad idea.

 So what if one of the ways to institutionally teach beginning 
 programming was to just institutionalize the way I learned how to 
 program?  You set up an Ultima Online server.  Customize it to cater 
 to macroing/botting.  So it's kind of like robocode, but more RPGish 
 and with some obligatory grindy numerical crap that has to be done 
 before you are actually good at the game.


 
 In my wife's AI course the students built simulated robots which 
 competed in various contests (navigate the maze fastest, etc).  I think 
 it was a fun way to get students interested in the material and think 
 about how to apply it in a practical manner.  This is my succinct way of 
 agreeing with your idea of making courses fun for the students :-)


It works.  I learned Java in a similar manner:

http://pclc.pace.edu/~bergin/KarelJava2ed/Karel%2B%2BJavaEdition.html

I've been itching to write a DWT incarnation just for kicks.  Imagine...

Karel D. Robot.  Stronger.  Faster.  On the whole more delicious than a 
cookie!

I thought it could help showcase the power of D as a real programming 
language.  Then I got roped into another project so I had to shelf the 
idea.  :(
Sep 30 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 30 Sep 2008 20:08:18 +0200, Sean Kelly <sean invisibleduck.org>  
wrote:


 Chad J wrote:

 Hmmmm, now this may be of zero interest to the OP, but I the appearance  
 of yet another programming pedagogy thread has caused me to spawn a  
 crazy idea.
  Disclaimer:  This is probably a bad idea.
  So what if one of the ways to institutionally teach beginning  
 programming was to just institutionalize the way I learned how to  
 program?  You set up an Ultima Online server.  Customize it to cater to  
 macroing/botting.  So it's kind of like robocode, but more RPGish and  
 with some obligatory grindy numerical crap that has to be done before  
 you are actually good at the game.


 In my wife's AI course the students built simulated robots which  
 competed in various contests (navigate the maze fastest, etc).  I think  
 it was a fun way to get students interested in the material and think  
 about how to apply it in a practical manner.  This is my succinct way of  
 agreeing with your idea of making courses fun for the students :-)


 Sean


We're currently doing robocode (http://robocode.sourceforge.net/) in my AI  
classes.  Loadsa fun.

-- 
Simen
Sep 30 2008
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
The way I learned programming wasn’t quite perfect. We started with C++, 

clicking around in Visual Studio. I’m just glad I found D pretty early, 
because it actually taught me programming.. or rather, I taught myself 
programming by exploring D. The D community and its open, positive 
attitude also had quite a big influence on me.

Thus, I think D would be a very good first language. Given that it 
sports a C-like syntax and includes so many paradigms, there’s lots of 
stuff to explore. Also, a “hello world” program is pretty easy to 
explain, as it only contains a very small set of constructs.

import tango.io.Stdout;

void main() {
	Stdout("Hello world!");
}

- import statement
- function declarations (main is a function after all)
- function calls
- string literals
- compilation :) (I’d just use rebuild to keep it easy for beginners)

Further, I would gradually add more things to this program, starting 
with function parameters!

import tango.io.Stdout;

void main(char[][] args) {
	Stdout.formatln("Hello, {}", args[1]);
}

- passing parameters to the program
- function parameters
- arrays
- passing parameters to functions

Next step would be to check args in some ways and explain flow controls 
that way, and so on.

You could well extend that to any paradigm you can find in D, given that 
you don’t skip anything that a paradigm builds on.

Best regards,
Alex
Sep 30 2008
prev sibling next sibling parent "Jim Hewes" <jimhewes gmail.com> writes:
<de-lurk>

I know BASIC and Microsoft are probably scorned here, but in this situation 
Visual Basic might be worth considering at least. Students can download the 
Express Edition for free ( http://www.microsoft.com/Express/VB/ ) and have a 
complete development environment. And there are some tutorials there to get 
started.

I wouldn’t recommend future developers bother with it. But since these 
students are biologists and not future software engineers, it may not be so 
important that they avoid a “bad” language that they will have to unlearn 
later. In the future they’ll just want something that they can use to 
quickly and easily get something done. A lot of people use VB to get things 
done.

Having said that, I haven’t actually tried VB Express Edition to see how 

decent environment. In the old days, before C became popular, BASIC was one 
of the first languages I used and I don’t think it screwed me up too badly 
(although I guess that’s open for argument :-) ) In any case, it’s probably 
a good idea to use a dynamically-typed language.

I used Scheme for a while in college many years ago and while it’s a good 
thing to teach programmers, at the time I found it hard to debug. We had no 
step debugger for it. Maybe things have improved since then. But I think the 
tools and environment you have to work with can be important too, not just 
the language itself. It’s harder to learn something in a limited amount of 
time when you have to struggle with the tools.

Jim

</de-lurk>
Sep 30 2008
prev sibling parent reply Bartosz Milewski <bartosz relisoft.com> writes:
If there was no D, I would argue for Java as the first language. 
However, D has a well defined subset (called SafeD) which is almost 
isomorphic to Java, except that it doesn't force OO on you (main is not 
an object, writeln is not anybody's method, you don't have to box 
integers, etc.).

When you introduce classes, you don't have to worry about 
private/public. This comes later, when you teach modules (separate 
source files). Even types are easier to teach because of some built-in 
type inference (the keyword "auto"). So SafeD has a very gentle learning 
curve.

D's standard library is quite adequate for teaching basic data 
structures and algorithms. It's also very easy to write a programs that 
list directories, read and write files, etc.

The only major problem with D is the lack of good programming/debugging 
environment. There's nothing that explains the functioning of a program 
better than single-stepping through it under a symbolic debugger.

--Bartosz

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!");
         }
     }
 


In D it's simpler. Simpler even than in C (no need for \n):

import std.stdio;

void main()
{
     writeln("Hello world!");
}

 From which you can progress easily to:

writeln("The number is: ", 16);

Although, how this works is a bit of advance magic ;-)


 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
Sep 30 2008
parent Don <nospam nospam.com.au> writes:
Bartosz Milewski wrote:

 If there was no D, I would argue for Java as the first language. 
 However, D has a well defined subset (called SafeD) 


Defined where? All I've seen is one blog post. I don't think we can 
recommend something which doesn't exist yet.
(Though I agree that when it does exist, it could be a great teaching 
language).
Oct 01 2008