I'm going to teach Clojure at university - suggestions/comments?
Dragan Djuric
This semester I'm teaching a course at MSc studies, and I decided to
base it on Clojure. Sorry, It's not a sign that Clojure gets the
ground in USA - I'm in South-Eastern Europe, at University of Belgrade
(cca 90.000 students altogether, the largest university in the region,
but underdeveloped economy comparing to EU).
The course title is not that important, as I am free to organize it as
I like (for the curious, it's "Tools and Methods of Software
Engineering").
In this region, Lisp is non-existent in the industry, which is usually
based on Java, Oracle stack or Microsoft stack, plus the usual PHP in
smaller projects and with the hobbyist crowd.
The undergraduate courses are based on Java and in a smaller extent
C#, so it's a usual "traditional" programming mindset.
The faculty I'm teaching at is an exotic mixture of management /
information systems departments, so even inf. syst. students attend
more management-related than IS-related courses. So, not many typical
geeks are going to be in the crowd. This course is a part of Software
Engineering module that does not exist at undergraduate level, only
Master/PhD. I expect 30 students total, 10 active and interested, 10
in the middle, and 10 that just want to pass.
I'm going to use Stuart's book as a referent literature, but the
courses I teach are usually interactive and not that structured
because I want to engage students to start coding and exploring as
soon as possible and I am willing to go to whatever direction seems
interesting to them and me. There is a method to the madness,
though :)
The goal of the course is to show them alternative/emerging languages
for the JVM. Because the industry is strongly traditional, and there
is little startup opportunity (keep in mind that this is not USA) I do
not expect anything more than them to be able to be ready to adopt one
of such languages if needed at one point of time in the future.
I hope that I'll also be able to do some research. The issue that is
particularly interesting to me to explore is how alien Clojure is to
Java programmers, what are subjective and objective causes, and how
hard is to overcome each of the identified issues. I am pretty sure my
students had no previous contact with Lisp dialects, some of them
probably coded PHP, and there may even be someone who had some contact
with Erlang/Ruby etc. I personally learned programming with Java, and
Clojure was my first contact with Lisp. Common Lisp is still something
that I would not use but Clojure was pretty easy to familiarize with,
and looks to me as JavaLisp :)
Any suggestion, especially related to the research part, would be
helpful :)
Michael Wood
[...]
> I hope that I'll also be able to do some research. The issue that is
> particularly interesting to me to explore is how alien Clojure is to
> Java programmers, what are subjective and objective causes, and how
> hard is to overcome each of the identified issues. I am pretty sure my
> students had no previous contact with Lisp dialects, some of them
> probably coded PHP, and there may even be someone who had some contact
> with Erlang/Ruby etc. I personally learned programming with Java, and
> Clojure was my first contact with Lisp. Common Lisp is still something
> that I would not use but Clojure was pretty easy to familiarize with,
> and looks to me as JavaLisp :)
>
> Any suggestion, especially related to the research part, would be
> helpful :)
I think this is an excellent way to explain lisp to e.g. Java programmers:
http://www.defmacro.org/ramblings/lisp.html
--
Michael Wood <esio...@gmail.com>
mac
> particularly interesting to me to explore is how alien Clojure is to
> Java programmers, what are subjective and objective causes, and how
> hard is to overcome each of the identified issues.
This sounds very interesting. I try to explain the point of lisp to
java programmers from time to time and I find it very difficult. When
the conversation is about clojure I usually just point out that it's
made for multi core because that's easier to understand and a good
selling point, but that really doesn't have much to do with the lisp
aspect.
ajay gopalakrishnan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Jeff Rose
A few years ago I taught two semesters of web application programming
to undergraduates using Ruby on Rails. None of them had any
experience with either programming in Ruby or developing for the web
before we started, but by most accounts it was a success. Maybe some
of what we learned can help you...
We structured the class as if we were all working on an open source
project together. We setup a Subversion repository and a mailing
list, and asked everyone to brainstorm project ideas during the first
few weeks of the course while they were learning the basics of Ruby
through a series of short programming exercises. Eventually every
student submitted an idea or two, and they all voted to create a wiki
like system that supported multi-media in a nice way. From there on,
we operated in two week cycles. At the beginning of each cycle we
would have a class discussion about what features to work on, which
bugs to fix, how to design important parts of the system, etc.
Everyone had to choose something they wanted to work on, submit a
short description of what they would do and how they plan on doing it,
and then do it. Communication on the mailing list started slow.
People were nervous about embarrassing themselves in front of their
classmates, and everyone was just starting in Ruby. The first commits
to the source tree were also pretty small and quite often very buggy.
Every time a student came to us with questions we would ask them to
first post it to the list though, and every time someone found a bug
we asked them to post it so we can put it on the TODO list for next
cycle.
For the first 5-6 weeks of the project we spent most of the lectures
going through code together, teaching more detailed lectures on web
app architecture, routing HTTP requests, model-view-controller, object
relational mapping, view templates, a little about javascript, etc.
Every lecture started with a clarification section though. Typically
about 10 minutes covering concepts that we could tell people were
struggling with by looking at their patches each week.
Eventually it really took off. Traffic on the mailing list literally
doubled every couple weeks from the start to the finish of the
semester, and submissions to the source tree kept getting more
interesting and more effective. There were plenty of bumps in the
road, social problems between competing interests, and all the other
student/open-source debates that come up, but that was also part of
the reason for doing the course the way we did it. By the end of the
semester they had a working application with lots of cool
functionality to demo to the rest of the faculty, and not only did the
students seem more confident in terms of picking up a new language and
a new technology, but they were also comfortable joining mailing lists
and taking part in the greater software development community.
My advice would be to have a lecture plan for every week, whether you
get to it or not. Students feel it when the course lacks structure,
and in turn they will lose motivation and discipline also. Try to
setup some policies in the beginning in terms of how assignments work,
when things are due, and what kind of code you expect, and then stick
with it. I guess this is kind of generic advice, but especially in a
class that feels less traditional I think it's even more important to
have this kind of stability for the students. It was definitely the
more challenging part of teaching for us, but when we succeeded it was
obvious.
Good luck!
-Jeff
P.S. The great thing about the internet and the software world is
that it doesn't really matter where you are. If your students learn
the right skills and practice lots I think they have a good chance of
finding work remotely or creating sites/services that can be used by
the rest of the world. Don't let a limited local economy limit their
ambitions.
Dragan Djuric
I'd like to do something like this - unfortunately, it's difficult to
enforce here because many students would start the riots (just
kidding) :)
As for the local economy, it's not a problem in a sense of employment
opportunity - half of them eventually move to EU, Canada or USA. The
problem is more with the alternative/exotic/emerging languages - they
simply want something that guarantees employment locally and abroad
(Java/.NET), and they are right.
Eric Lavigne
A year ago, I delivered a presentation about Clojure to a local Java
user group. I talked about advantages of Lisp/Clojure and demonstrated
Clojure's ability to interoperate with the Java libraries and code
with which they were familiar. Everyone nodded their heads, said it
was interesting and that they understood, and mostly forgot about it.
http://ericlavigne.wordpress.com/2009/02/11/clojure-presentation-at-gatorjug/
A couple weeks ago, I used Clojure to win a contest sponsored by that
group. In an afternoon, I wrote a web application in 100 lines of
Clojure.
http://www.codetown.us/group/contesttown/forum/topics/wari-contest-1
http://github.com/ericlavigne/island-wari
I was asked to discuss my code at the same group. We had no projector
that day, so I actually wrote out my code, 10 lines at a time, on a
whiteboard and explained how it worked. A lot of that time ended up
being spent explaining various sequence functions like map, filter,
and remove. Everyone was amazed at what Clojure could do with so
little code. They were amazed by this strange, expression-oriented
style of programming that didn't contain any statements. There was
lots of discussion, and when I was busy writing more code the audience
would break out into side discussions about coding style and whether
concise code was even a good thing (one person claimed that they
deliberately wrote verbosely so that they could understand their code
later). One audience member said that he had already seen one Clojure
presentation (mine) and two Scala presentations, and that he was
finally having an "aha" moment and starting to understand what
functional programming meant. They have asked me to continue talking
about my little program next month, as everyone is still very curious
about Clojure.
My lesson: showing is better than telling.