Courses/CS 537/Summer 2008

From CSWiki

Jump to: navigation, search

Contents

[edit] Week 1. June 22

Video

Policies

[edit] Groovy references

[edit] Groovy Eclipse Plugin

From a July 24 message from Guillaume Laforge.

The Groovy Eclipse team released an updated version of the Groovy Eclipse plugin.

In this new release, the main points of interest:

  • the plugin has been updated to use Groovy 1.5.6
  • and it is also working with the recent Eclipse 3.4

You can find the Groovy Eclipse plugin as a Zip file here: http://dist.codehaus.org/groovy/distributions/update/GroovyEclipse.zip

And you can point your Eclipse update center at the following location: http://dist.groovy.codehaus.org/distributions/update/

Upcoming version of the plugin will feature the first refactorings (extract method).

You can discover more on the topic thanks to the students working on this project as part of their Bachelor thesis at University of applied sciences, in Rapperswil, Switzerland, here: http://sifsstud4.hsr.ch/trac/GroovyRefactoring

Also, don't forget to read Groovy plugin developer James Ervin's words on the roadmap of the plugin: http://iacobus.blogspot.com/2008/07/roadmap-for-groovy-eclipse-work.html

[edit] Chapters 1 and 2 code examples

[edit] Other languages that compile to the Java Virtual Machine (JVM)

The big three (besides Groovy)

Others(?)

[edit] (Non-Java) Low Level Virtual Machine Project (LLVM)

[edit] Grails

[edit] Student pages

[edit] Week 2. June 29

Video

[edit] Chapter 3. Simple Groovy datatypes

[edit] Chapter 4. Collective Groovy datatypes

[edit] Homework for week 2

Compare the simple and collective datatypes provided by your language to those in Groovy. Put your results on your course web page.

[edit] Week 3. July 6

Video.

[edit] Chapter 5. Closures

[edit] Week 4. July 13. Student presentations 1

Video.

[edit] Answers to question for the Groovy mailing list

[edit] Student Presentations

This week will be devoted to student presentations about your languages. Think of it as midterm1. You will have approximately 10 - 15 minutes each.

A number of you have been putting basic information about your language on your course page—more or less as I did with Groovy. That's good. It's a good way for you to familiarize yourself with the language and to keep track of points that you want to remember. For the presentation, though, you won't have time to go through all the information you have accumulated. So for the presentation prepare some executable examples that illustrate distinctive features of your language and how it differs from Groovy—and not just, for example, that it has variables that can be assigned and printed out. Make sure you have executable code—not just PowerPoint slides.

Let's do this again in week 7 and then once again for the final.

For the final, prepare a non-trivial program in your language.

Use the second presentation (week 7) to describe what you intend to do for your projcect, why that project shows off the significant features of your language (i.e., why do that project in that language), and how you have started.

I've created a CSNS entry for this course and enrolled students who are listed in GET. These are the people enrolled.

Agrawal Priyanka Omprakash
Bhatta Nandini
Cano Colon Maria Magdalena
Chansamorn Kanokwan
Claypool Gavin
Cofer Cheralyn Kay
Fang Zhou
Golestanian Namagerdi Aspet
Isaji Hideyo
Patel Dhaval Mukundbhai
Patel Prashantkumar Ashokbhai
Peters Tristan David
Puthota Anita Marty
Raghuraman Adithya
Udommana Smith

Unless I've made some mistakes, four people listed in the Student pages section above are not listed in GET (and now not listed in CSNS for this class). See comment next to your name in the Student pages section above.

[edit] Week 5. July 20

Video

[edit] Week 6. July 27

Video

[edit] Week 7. August 3. Student presentations 2

Video

As I said, it's ok for your project to be to do the examples I did in Groovy in your language. If you do that, I want you to be able to explain why the results are they way they are, not just to run the examples and point to the results. You should understand how your language gets its results, and you should be able to explain what happens.

It's far, far better to acknowledge that you don't know something than to pretend that you do and attempt to bluff your way through an answer.

When asked a question for which you don't know the answer, simply say that you don't know and that you will find out and report back.

Anything else makes you look bad. You look dishonest. And you look especially ignorant since by responding in a way that doesn't answer the question it seems that you don't even understand the question well enough to say that you don't know the answer.

As you have seen, that sort of response also frustrates the person asking the question, i.e., me.


[edit] Week 8. August 10

Video

[edit] Week 9. August 17

Video

Grails

[edit] Week 10. August 24. Student presentations.

Video

  •   9:00.
  •   9:30.
  • 10:00.
  • 10:30.
  • 11:00.
  • 11:30. Nandini Bhatta
  • 12:00.
  • 12:30.

[edit] Week Final. August 30 and 31 (Saturday and Sunday). Student presentations.

Please be prepared to answer my questions with respect to the mechanisms your programs use.

I have found that very often when I ask a question, the answer doesn't respond to the question. Either it doesn't talk about the issue at all, or it responds in a very superficial way.

For example, let's assume you have a line of code like this.

   x = y

If I ask you what that line of code does, I don't want you to say that it makes x equal to y or even that it assigns y to x. A good response would be to draw a diagram that includes x and y and then describe how the diagram changes from the way it is before the line of code is executed to the way it is afterward. (In this case the diagram would be different depending on whether y is a primitive or a reference to an object. If y is a reference to an object, the object itself would be in the diagram.)

In the past, when you haven't answered my questions I have asked them again, thinking that perhaps there was a language difficulty and that if I put the question differently you would understand what I was asking of you. Often this became very frustrating for both of us.

So I'm going to stop repeating my questions. Instead, when you are finished with your answer I want you to ask me whether your answer responded to my question. In other words I am placing the burden on you to determine whether your answer has been adequate. If you don't do that, I will assume that you are unable to provide an adequate answer.

Saturday August 30

  •   9:00. Anita Puthota
  •   9:30. Cheralyn Cofer
  • 10:00. Tristan Peters
  • 10:30.
  • 11:00.
  • 11:30.
  • 12:00.

Sunday August 31

  •   8:30. Natasha Jindal
  •   9:00. Gavin Claypool
  •   9:30. Hideyo Isaji
  • 10:00. Kanokwan Chansamorn
  • 10:30.
  • 11:00. Zhou Fang
  • 11:30. Aspet Golestanian
  • 12:00. Adithya Raghuraman
  • 12:30. Maria Colon
Personal tools