D at University of Minnesota
Carl Sturtivant
sturtivant at gmail.com
Sat Aug 17 08:22:24 PDT 2013
>> What happened is that I unclear what the state of play is; I
>> am not
>> asserting the wrongness of TDPL. Still, I am reassured by your
>> responses.
>
> Hi Carl -- TDPL is for the most part in good shape. There are a
> few inaccuracies, but I'd say most concern corner cases that
> are unlike to deter the learning process.
>
> You may want to encourage students to interact with us here, or
> write me email directly if they have any questions. I'd be very
> glad to help them.
Hello Andrei, Ali,
Well, CS2 in D is over, and grades are in. Being a summer course
it was conducted at twice the speed as in a regular semester.
Being the U of M there's enormous variation in background,
current experience and ability, potential, etcetera etcetera,
among students in the course. In the end registration had
stabilized at 55 before the course started and (unusually) all of
them finished it. There were a number of exceptional students of
little experience in the class. There were also a number of
students in the class with C++ experience that was more than
beginner level. A majority of the students had come from the CS1
course here which is Scheme based, and so they had experience
mainly with functions, recursion and singly-linked lists.
My main observation is that there was a significantly greater
level of inspiration engendered by using D as opposed to the
usual alternatives. I and my TA saw a lot of the students in the
lab and in office hours, and I made an effort to find out their
reactions to using D, and they were very positive, especially so
among those in about the top 2/3 or so of the class.
In our abstract data type implementations we made good use of D's
superb dynamic arrays, and associative arrays, and we used both
classes and structs; we made prolific use of operator overloading
including signature constraints, and in an extra credit exercise
we even had them write a simple opApply. We used classes to
implement linked structures except at the end of the course. When
I say "we" I mean that while I discussed topics on all scales and
from abstract to concrete in lecture, the TA and I had them
actively learn everything done via a long sequence of problems to
solve in D, and some things were left to the lab.
At the end of the course I introduced pointers (to structs or to
C-style arrays), and I discussed the connection between D and C.
I also explained in detail how they could cripple their use of D
and with small changes find themselves writing Java, and I gave
an introductory discussion of the relationship of D to C++. In
doing this I was pointing at their future courses: Java is the
default language for a course here; in the machine architecture
course they will use C; in the "Program Development" course they
will use C++.
Language related issues that caught a significant minority of
students out when solving the course's problems, despite
explanation in lecture and lab, include the following. First up,
no default constructor for structs, and what to do about it. This
was complicated by the fact that in the Windows implementation of
DMD it was possible to assign e.g. a new array directly to a
struct variable, apparently contradicting the dictum of a fixed
.init for structs. This lead to some writing code that needed
non-trivial changes to run on the lab's Ubuntu machines. Second,
the complexities of opCmp for classes, where a cast from Object
is needed. We'd covered inheritance, but the need for this cast
struck some as an unexpected deficiency in D, and we had to
explain this many times to individual students struggling to make
their code compile.
Overall, a significant number of students made this class a
game-changing one for themselves, and were inspired and
stimulated to learn more about algorithms and data structures,
and to learn more about D. For example, we had them implement
associative arrays as linked lists of pairs, then as hash tables
using the previous implementation to do the work, and quite
separately as a binary search trees. They had already implemented
binary search trees with a single type parameter, and now having
that type be a struct parameterized by a pair of types they could
use the earlier solution to do the work. The result was a lot of
very natural data abstraction, and, most exciting, types that
looked built-in. This was very gratifying to many students. And,
I should mention that the presence of operator overloading via
opIndexAssign kept the associative array solutions simple enough
for all students at this level, unlike what C++ would necessitate.
Ali Çehreli's tutorial played a central role supporting students
especially during the first half of the course --- without it the
course simply would not have worked, so "many thanks Ali" --- and
an important part of that is its linearity --- it can be read
with only backward dependencies. This meant that with hard work
even students of little experience and only moderate current
abilities could get up to speed, and we saw just that. It is hard
to overstate this factor.
TDPL got some use during the second half of the course: most
students acquired it and my impression is they did so because
they had become inspired by D and wanted to use it to exert
maximum leverage on the homework problems. All-in-all I saw a
significant majority of the class inspired and excited in some
cases by D itself because of its possibilities and
expressiveness. This was told to me in office hours directly and
repeatedly. I haven't had this experience with other languages
used in the department.
More information about the Digitalmars-d-announce
mailing list