Good point Mr. Hinkle. But, I would vote for an interpreter which has direct
access to memory resources, allocate them, is typed, and type-safe. Do You
know some which is good?
Oh, BTW, there is an excellent C/C++ interpreter, named CINT, which is
developed and used by CERN in their famous ROOT project.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

> Only trouble I see in D for the first day of teaching is that strings are the same as an array of char. Not good; "the same as, but works this way", and "just accept this, it will be explained" are the wordst things you can say to your students. They lose interest, and they get uneccesary scared of the complexity that need not be there.

What do you mean by "the same as, but works this way"? Do you mean the utf-8 encoding could have multi-byte chars?

Fredrik Olsson wrote:
> Hasan Aljudy wrote:
> 
>> I would personally go for Java, but the problem is you're gonna have to mention "class" before the students ever had a chance to know about programming.
>>
> I think Java is terrible, utterly terrible for beginners. As a teacher I have had a hard time justifying why my students must declare the start of a program as "main" in C. Going through a dummy class with a static main is just too much; "just accept this kids, and look at this single line, the other 10 will be explained in due time."

I mentioned java because it has a C style syntax but it's clear at the same time. The only problem is that it's entirely OO, so it's not really  for beginners.

> 
> 
>> C is not bad, except the printf formatting thing isn't so beginner-friendly.
>>
> C is also terrible for learners, because of all the exceptions. The trick is to teach the students what arrays and pointers are, what they are good for and why to use them. Good luck with C. And strings, ooh the strings. No too many of the simple things are just not simple enough with C.
> 
> 
>> As for pascal .. well, I have a thing against it.
>> It's all good and simple and all .. but once the code exceeds 50 lines, it becomes very hard to debug and maintain it. Everything is so cluttered .. there's simply no obvious boundaries between functions, and main becomes hard to find without a comment.
>> I always put a huge comment on it to help me find it
>> (*
>>  *
>>  * MAIN
>>  *
>>  *)
>>
> Pascal IS excellent for teaching, mainle because it is consistent. Very few exceptions, and if you are a good teacher you will avoid them very easily (Did you know that you do not have to put a terminating ; on the last statement in a compound statement, just before the end;?). All data types or clear and distinct from each other, and all constructs follows the same patters; what it is, what it is named, what it does.
> 
> All good students eventually go on and try their wings at programming, and ozens upon dozens of my C students have tried to make a:
> int foo(int a, b) { ... }
> Well you just can not declare the arguments that way I have to tell them. But why? They look like variables? They allways say. There is no good answer to that one, so yet another; "just accept it".
> 
> When teaching in Pascal I do o need to do that. It is an obvious construct and Pascal allows for it. Even the structure of the main program is the same as for sub-programs, not even a need to explain to the students why; it is soo natural. And as a bonus the students who do try their wings using logic applied to their new skills hits the mark nine times out of ten, and their tries work out. They get confidence and dares to try more. And as we all know; trying and actually write programs is the best way to learn!

In the pascal course I took, lots of students asked lots of questions that are quite similar to "why is it called main?" and "why can't I do this?" and "why is it that way?". These questions will always be asked, and in my opinion that's a good thing .. asking these kinds of questions means the students really want to learn.

And that end-semicolon example you brought up .. is an excellent example of a case were C style syntax beats pascal's.
In pascal, there are times when "end" needs to be followed by a period, and other times where it needs to be followed by a semicolon, and other times where it can't be followed by anything, or else the structure of the code will break. Like for example in nested if-else blocks ... I never figured out what's the proper way to do them, which end should have the semicolon and which one shouldn't?

With C style syntax, it's very obvious: blocks start and end by { and }, nothing more, nothing less.

> 
> My experience says that students learn to code in C twice as fast if they only get a crash cource introduction in Pascal first. Then all you as a teacher have to say is; it is like this in Pascal, and give a good example and then draw up how it can be done in C (And try to make the best practice example :)).

Maybe .. I did mention that I learned the concept of a function in C++ by relating it to GOSUB in basic, but I don't think it would've made that much of a difference (I mean if I didn't learn basic when I was a kid).

But um, when you give them a crash course in pascal then start teaching them C, you would already have spent "twice" the time to teach them programming .. no?

> 
> As for D I think it can work as a learning language, at least ten times better then C and Java combined. Pascal is hard to beat. Only trouble I see in D for the first day of teaching is that strings are the same as an array of char. Not good; "the same as, but works this way", and "just accept this, it will be explained" are the wordst things you can say to your students. They lose interest, and they get uneccesary scared of the complexity that need not be there.

Well, D has things like AA and dynamic arrays -- not very good for beginners. Although if you can hide these concepts from them at first, then it'd probably work out pretty well. I personally don't know how you can hide that, seeing as strings are dynamic arrays.

> 
> regards
>     Fredrik Olsson

In article <ddpeco$93j$1@digitaldaemon.com>, Fredrik Olsson says...
>
>Hasan Aljudy wrote:
>
>As for D I think it can work as a learning language, at least ten times better then C and Java combined. Pascal is hard to beat. Only trouble I see in D for the first day of teaching is that strings are the same as an array of char. Not good; "the same as, but works this way", and "just accept this, it will be explained" are the wordst things you can say to your students. They lose interest, and they get uneccesary scared of the complexity that need not be there.
>

Perhaps that could be 'glossed' over on the first day by: "In any programming language, a string is made up of a list of contiguous characters, also known as an array. We will go over arrays in more detail later in the course, but for now, this is how you declare and initialize a string in the D language: char[] str = "Hello World";" or something like that. Granted, you're forced to introduce the concept of arrays very early, but I don't see how the syntax itself would be much more difficult to grasp than Pascal.

You could use a module that declares an alias char[] String; too (along with importing things like std.stdio and such).

import D101; // import std.stdio; alias char[] String;

void main()
{
String s = "Hello World!";
writefln(s);
}

If an effective way could be used to teach through that issue for the newest of beginners, then D would also be an excellent language for continued eductation of 'advanced' concepts like OOP, PwC (contracts) and even some assembly w/o having to introduce other languages into a course series.

>regards
>	Fredrik Olsson

Hasan Aljudy wrote:

> In the pascal course I took, lots of students asked lots of questions that are quite similar to "why is it called main?" and "why can't I do this?" and "why is it that way?". These questions will always be asked, and in my opinion that's a good thing .. asking these kinds of questions means the students really want to learn.
> 
Questions are good. But questions with no definitive answer except: "that is the way it is, and I can only agree it is silly", are bad.


> And that end-semicolon example you brought up .. is an excellent example of a case were C style syntax beats pascal's.
> In pascal, there are times when "end" needs to be followed by a period, and other times where it needs to be followed by a semicolon, and other times where it can't be followed by anything, or else the structure of the code will break. Like for example in nested if-else blocks ... I never figured out what's the proper way to do them, which end should have the semicolon and which one shouldn't?
>
The dot and semicolon question is easy; dots are only used for terminating program, unit and library statemets. Such as:
program foo;
begin
  WriteLn('Hello World.');
end. // Dot, this is a program.

procedure bar;
begin
end; // ;, this is a complete procedure declaration statement.

The rule is very firm and simple, and the example I gave you is the only exception (An exception not many know of anyway, and I have never seen it actually being used). The rule goes like this:
ALL complete statements and declarations MUST end with a semicolon.
Nothing hard at all, then all you need to know beyond that is that a statement can be a single statement or a compount statement. And then you need to know what a declaration is.

The reason for declarations requiring a semicolon as well is simple: if it did not require one you would have to introduce an exception to the rule to make forward declarations work. And in Pascal grammar one more rule is preffered over one more exception to another rule.

> With C style syntax, it's very obvious: blocks start and end by { and }, nothing more, nothing less.
> 
Just as { and } groups zero or more statements into a compount statement in C, begin and end does the same in Pascal. Nothing strange at all. What differs is Pascals conssistent requirement on terminating semicolon on complete statements, and C requiring it sometimes (structs) and making it optional otherwise.

But teaching Pascal or even worse explaining the superiority of Pascal over C for a someone that have learned C first is quite futile. For some reason it is almost impossible to unlearn the use of the many rules applied to C code, and relearn the single rule of Pascal. C code becomes the normality :). And even if you can explain your point it always goes down to "{} are just two characters, 'begin end' are eight.", and that is quite hard to argue with ;).


> 
> Maybe .. I did mention that I learned the concept of a function in C++ by relating it to GOSUB in basic, but I don't think it would've made that much of a difference (I mean if I didn't learn basic when I was a kid).
> 
> But um, when you give them a crash course in pascal then start teaching them C, you would already have spent "twice" the time to teach them programming .. no?
> 
Say you wany to teach the students to be 100% skilled C coders. Staring of with C would require a full five days.
Instead starting of with teaching them Pascal, would take two or max three days, and then a single day with "in C you do this instead". And you would have made them 100% skilled in a total of three or four days. The remaining time can be spend on teaching them some Java or becoming 150% skilled in C.

The big problem with C is foremost that the language is hard to explain, Pascal is simply easier to read and memorize as it have barely no exceptions. And secondly you have to learn quite allot about quite complex things for beginners such as pointers, and momorize a whole bunch of functions from stdio.h and strings.h just to get strated. With Pascal you can ignore all that and do the simple stuff really simple. Anfd then day two you can still do pointers and teach them to a buffer overflow vulnerability of you like.

> 
> Well, D has things like AA and dynamic arrays -- not very good for beginners. Although if you can hide these concepts from them at first, then it'd probably work out pretty well. I personally don't know how you can hide that, seeing as strings are dynamic arrays.
>
Arrays can be tought in about hour four, and dynamic arrays are not more hard for new people then static ones. The hard part is that there is no clear distinction of arrays and pointers in C, and no run-time and barely no compile time checking at all. There D does wonders!

The strings are problematic, form a teaching perspective a default alias for char[] to string would be good. Begginers are quite reuctant to trying out something as daring as char[][], but doing a string[] they will find the use for quite fast. And then telling them that string is the same as a char[] is no biggie day two.

regards
	Fredrik Olsson

Ben Hinkle wrote:
>>Only trouble I see in D for the first day of teaching is that strings are the same as an array of char. Not good; "the same as, but works this way", and "just accept this, it will be explained" are the wordst things you can say to your students. They lose interest, and they get uneccesary scared of the complexity that need not be there.
> 
> 
> What do you mean by "the same as, but works this way"? Do you mean the utf-8 encoding could have multi-byte chars? 
> 
No I mean more of strings being arrays, that they really are is no problem. Problem is that in about minute ten of the first lesson you will bring up strings, and with a char[] you will quite possibly have to explain arrays briefly or tell a curious student to wait a bit longer for an explanation and just accept it for the moment. None of the options are good; a brief explaination of arrays ten minutes in, is far to early, telling a student to just accept something kills the curiosity and will to explore.

In D it could quite easily be fixed by having a default alias for char[] in string. Works good for Pascal, where string have always been an alias for an array of some sort. Fixed length 255 chars in old versions and a dynamic array in new. Explain strings, explain arrays and THEN tell them that strings can be used as arrays is far easier then trying to explain strings and arrays at the same time.

regards
	Fredrik Olsson

Dave wrote:
> 
> Perhaps that could be 'glossed' over on the first day by: "In any programming
> language, a string is made up of a list of contiguous characters, also known as
> an array. We will go over arrays in more detail later in the course, but for
> now, this is how you declare and initialize a string in the D language: char[]
> str = "Hello World";" or something like that. Granted, you're forced to
> introduce the concept of arrays very early, but I don't see how the syntax
> itself would be much more difficult to grasp than Pascal.
> 
To gloss over is never a good idea, and should be avoided at all costs. Beginners simply do not like to not grasp everything, the very first example you show them should be able to stand on it's own. If it can stand on it's own the students will feel secure and the initial fear will go away imidiately.

> You could use a module that declares an alias char[] String; too (along with
> importing things like std.stdio and such).
> 
> import D101; // import std.stdio; alias char[] String;
> 
> void main()
> {
> String s = "Hello World!";
> writefln(s);
> }
> 
This is a very good example. D101 can easily be said called "a bunch of helper stuff I made you for this course". Only problem I see is that with import you will have to explain the concept of modules as well :).

The good thing with Pascal having char[] "predeclared" as string, and writefln (WriteLn) builtin in the system unit, that is always linked in, is that when you come to explaining arrays you can allways tell the students that they have used some already without knowing it.

> If an effective way could be used to teach through that issue for the newest of
> beginners, then D would also be an excellent language for continued eductation
> of 'advanced' concepts like OOP, PwC (contracts) and even some assembly w/o
> having to introduce other languages into a course series.
> 
As I said I think D could be an excelent language for teaching. Add char[] alias and std.stdio as a default linkage (Patched student version maybe :) ), and it would be perfect.

Only problem I see is lack of books, will be quite hard to get it accepted at the University if there are no literature for it :/.

regards
	Fredrik Olsson

I would think something like Python would be the logical choice for a modern teaching language.  Simple things are simple (print "Hello World"), and you can proceed logically from the simpler programs introducing input, output, strings, variables, common flow control constructs (if, else, for, and while loops), data types, on to more advanced areas like functions, modules, exception handling (try, except, finally, as well as assert), and even the basic concepts of object oriented programming.

And the "whitespace as seperator" model encourages good code organization habits which will become useful later on in laguages like C where readable code requires some programmer discipline and adherence to conventions.

Moreover, good documentation and tutorials are readily avaiable (a must for the more motivated students who will want to explore learning materials available outside of the classroom), as are good free interpreters for all common operating environments, with extensive online help.  There is also a wealth of good simple code examples available to learn from.

From there, you can move on to a more robust OO environment, such as Java, C++, Ada, or D for more complex applications, or for more control for system level work, something like C/C++ or D.  While D might be an ideal language for someone interested in studying language design, it's probably one of the worst choices for a first language for a beginner.  I think to fully appreciate D, it's probably better to first have an understanding of both the strengths and limits of the more common laguages it hopes to replace.

On Wed, 17 Aug 2005 22:33:09 +0000 (UTC), acerimusdux wrote:

> I would think something like Python would be the logical choice for a modern teaching language.

I've kept out of this discussion before now mainly because it is so easy to drift off into 'religious wars about languages. However I'll risk that to mention the language called Euphoria. For most of the same reasons that Python might be considered, I feel that this is also worth a look at.

  http://www.rapideuphoria.com/

It is simple, interpreted, bloody fast, and focuses on programming rather than computers (no need to know about RAM and storage formats, etc...)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/08/2005 9:36:01 AM