Category Archives: how

Learning Ruby… going about learning a new programming language

Published by:


I teach computer science at a small state college to pay the bills. One course that I regularly teach is “Objected-Oriented Programming and Design”. Our program is very C++ focused and this course is the class where we pound the more advanced aspects of C++ into our students and try to give them a flavor of other ways of doing OOP by introducing them to other object-oriented languages.

So… what other languages? In the past, I’ve taught the course by talking advanced C++, hitting Java pretty heavy, and doing a quick overview of Smalltalk to show students the “pure object” way of thinking. Teaching Smalltalk has been problematic… that language is so different from anything most of my students have seen that they go into vapor lock. Most of these folks are community college graduates looking to complete their four-year degrees (more on that in a future post) and haven’t had the deep dive background that you get in other programs. This has meant that I’ve had to go looking for a language that I can use to demonstrate the “pure object” idea without causing heads to go spinning out in the classroom.

That leads us to Ruby. I like the way that Dave Thomas described the language in one of his books:

Take a true object-oriented language, such as Smalltalk. Drop the unfamiliar syntax and move to more conventional, file-based source code. Now add in a good measure of the flexibility and convenience of languages such as Python and Perl.

So it appears that it will meet the needs of my course. However, it’s not a language that I’ve ever used for production development. I like to develop some ninja-level skills with a language before I have to try to teach it to other people.

So, oh Noble Readers, I intend to subject you to a series of posts that describe my experiences on learning Ruby. These posts will be the basis of my lecture materials for my class and will hopefully give you a feel about how someone like myself who has had the “fortune” of having learn many different programming language over time learns a new one.

Selah.

Computing like it’s 1999

Published by:

One of my recent “science fair” projects has been trying to get an older ASUS EeePC 900A netbook configured to a usable state. This was one of the first really practical netbooks with a 1st generation Intel ATOM processor with 1GB of Memory and one of very first practical SSD cards for file storage with 4GB of space. Not the most capable of machines from a hardware standpoint. ASUS shipped the machine with a rather hacked-up lightweight Linux distro. Sadly, the distribution they selected wasn’t one of the mainstream distributions like Debian, Ubuntu, or Fedora. This meant that you didn’t have access to a lot of the stuff that you need to work in an academic environment like my workplace. So, you say “Big deal, just install the NetBook Remix of Ubuntu?” It’s the problem of “Linux… just too darn fat” raising it’s ugly head again. Even the netbook oriented repackages of Ubuntu or Fedora assume a much more capable machine than what the 900A can handle.

That got me thinking: you know the specs on this machine would have been pretty sweet back 10 years ago. So, how would I have configured Linux back around 1999 and would that configuration be useful today. First step: how to setup the OS. GNOME and KDE are right out… And that gets rid of a ton of fat right there. Think about it: how much of what those desktop managers install do you really use in the normal course of business. OK, do we even need X-Windows? Could I really be that “Tech Neanderthal” and just work with text-mode EMACS on a Linux console?

Problem is web browsing. The guys at Google may be onto something with ChromeOS given how much time I spend during the day doing useful stuff in the web browser. However, while you can do a lot stuff using text mode browsers like w3m, a lot of the stuff you want to do just requires a GUI. OK, so we need a X-Windows and, thus, some sort of window manager to go with it. The best solution I’ve found was Fluxbox: it’s lightweight and works well.

Beyond web browsing,everything else that I do in my life I can do from inside EMACS. Writing documents (with AUCTEX and TeXLive), reading and responding to E-mail, manage my day-to-day tasks can all be done using the “editor that thinks it’s an operating system”. So, with the base OS, X/Windows+Fluxbox, Firefox, and GNU Emacs installed, I’ve used up about 80% of the 4GB SSD. Put my /home partition (where user data is stored) on a 4GB flash card in the flash card slot combined with a well-tuned command-line installation of Dropbox and I’m in business.

Of course there are still problems. The hardware is pretty slow, esp. when surfing to graphics-intensive web sites. I have to aggressively manage what files I keep local to the netbook given the available space. Particularly vexing is dealing with the dependency hell that is modern Linux package management. Good example is UI toolkit that I had to install for teaching purposes the other day. For one package, I had to install nearly 40 other dependent packages. It’s getting almost as bad as DLL-hell on Windows.

So, worthy experiment? Yep, I now have a usable travel machine that’s about 3 pounds lighter than the MacBook Pro I use at work. Still saving up to get a MacBook Air, tho’. And it does lend some credence to the thought that the GNOME, KDE, Windows, and Mac OS X folks have gotten complacent about the amount of resources they use when building applications.

Selah.

The C++11 standard and C++ as a teaching language

Published by:

The C++ Standards Committee recently published the 2011 update to the language standard with a large body of new features. Looking over some of the changes got me thinking again about my experiences as a software developer using the language and as an instructor teaching others how to use C++. And I’m not certain that the changes in the standard bodes well for the use of C++ as a teaching language.

A Historical Perspective

Like many who were first introduced to computers in the late 1970s and early 1980s, I learned how to hack using BASIC and assembly language, how to program using Pascal, and finally understood computer science when I grokked LISP and Smalltalk in my first run at graduate school. My introduction to C was in the late 1980s while learning to become a UNIX system administrator while working on my Master degree and C++ in my first real job writing point-of-sale software. So,like most people in my generation I’m not a native C++ speaker; most of the time I’m really thinking in C.

So, why comment now?

Part of my Ph.D. experience has involved working as a part-time instructor in our undergraduate program. Our department is very old-school in many ways; one of which is that we use C++ as our primary teaching language. And we teach C++ exactly as I learned the language 20 years ago in that we first teach imperative programming using the language as more fancy version of C and then we teach the object-oriented features. In other words, for the student’s first three or four semester we teach them that “C++ is just a better C compiler” and then dump object orientation on them when they have to also struggle with all of the theory of data structures. This brings us back to some of the features in the new language standard and how people who are taught to program in C++ in this traditional manner will never think to use them.

So what are some of these features?

Danny Kalev is a tech blogger and consultant who served on the C++ standard committee who recently posted a blog (here) that highlighted what he considered to be important new features of the standard. Let’s take a look at a few of those features from a teaching standpoint.

Null pointers

One of the big problems with not only C++ but also C is the way one dealt with concept of null pointers. From day 1 in both languages, the concept has been that machine addresses were represented by an integral subtype with value of 0 indicating an invalid null address. This lead to many issues in programs with people being caviler about treating the integer value of zero as being the same as indicating a NULL pointer. You have to be diligent in teaching people the difference between the two concepts and how to avoid the problems that are introduced by this convention.

So the convention developed that you would define a preprocessor value called “NULL” that you set to zero to indicate you were working with a null pointer value. Eventually this macro was incorporated in the set of headers mandated by the standard. Consider an example from Kalev’s post:

void f(int); //#1
void f(char *);//#2
//C++03
f(0); //which f is called?

In both cases, very dangerous as the compiler can’t figure out which version of the overloaded function to call. Now think how to explain this concept to a neophyte programmer just learning about concepts of machine addresses, pointers, and overloaded functions.

So, the language standard introduces the concept of “nullptr”. For example, the nastiness from Kalev’s example becomes:

void f(int); //#1
void f(char *);//#2
//C++11
f(nullptr) //unambiguous, calls #2

A glorious and wonderful thing for the language and a feature that will help teaching. But a good illustration of the problems that exist in teaching C++ to new programmers.

Delegating constructors

Object orientation is one of most difficult aspects of instructing people in programing C++. The idiosyncrasies of constructors and destructors are bad enough as currently defined but the new standard is adding more complexity to the issue. For instance, the C++11 standard permits the use of delegation in constructors. Again, we consider an example from Kalev’s post:

class M //C++11 delegating constructors
{
 int x, y;
 char *p;
public:
 M(int v) : x(v), y(0),  p(new char [MAX])  {} //#1 target
 M(): M(0) {cout&lt&lt"delegating ctor"}
}

 

At last, we can now safely call other constructors, an excellent idea from an object-theroetical standpoint. However, the entire chain of teaching constructors becomes far more difficult with this feature.

Lambda expressions

The new standard adds the concept of lambda expressions to the language. A lambda expression lets you define functions locally at the place of the call to the function. In C++, this helps reduce some of the security risks that function objects incur in the language. Consider the following example from Kalev’s post:

int main()
{
   char s[]="Hello World!";
   int Uppercase = 0; //modified by the lambda
   for_each(s, s+sizeof(s), [&Uppercase] (char c) {
    if (isupper(c))
     Uppercase++;
    });
 cout&lt&lt"Uppercase&lt&lt" uppercase letters in: "&lt&lts&lt<endl;
}

In this case, we see an example of a lambda expression in the for_each construct where the Uppercase lambda expression defines a C++ expression for switching text to uppercase. Note the general form of the lambda expression

[capture](parameters)-&gtreturn-type   {body}

We see two pedagogical problems from this example: (1) the for_each construct is one that isn’t taught very well when you are inspired by the “C++ as better C” viewpoint of teaching, and (2) more critical, the entire concept of lambda expressions is one that you would not be able to teach until you have developed rather strong fundamental conceptual understanding of language design principles. Thus, not something easily taught to beginning programmers. In most undergraduate computer science programs, it’s a concept not taught until your third or fourth year in the program.

OK, how do we tie all of these thoughts together?

For me, the new standard makes the use of C++ as a teaching language even more problematic. Many of the concepts being added to the language to make it safer and cleaner make it more it more difficult and dangerous to use as a teaching language. Furthermore, it becomes even more problematic if your program is traditional and uses the “C++ as better C compiler” approach to teaching students just starting in their study of computer science.

Closing thought: C++ not a good teaching language

If we begin from the premise of C++ as being less than suited as a teaching language and becoming even more so with the introduction of the revised standard, what then should we use as a teaching language for new programmers? In my recent travels in search of a teaching position, it’s been my observation that many programs have switched to Java and C# as alternatives. These languages suffer from many of the same issues of C++. I’m beginning more and more to believe much as the teaching staff does as CMU and we should be teaching using languages such as Python.

Selah.

References

Danny Kalev: The Biggest Changes in C++11 (and Why You Should Care)

Robert Harper: Teaching FP to Freshmen

Enhanced by Zemanta

How to setup SSH to not ask for a password?

Published by:

I’ve had enough people ask me how to do this that I decided to post a summary here on my blog.

Terms:
Client: machine starting the SSH session
Server: machine running the SSH session
On Client:
Use ssh-keygen to generate a new public/private keypair:
ssh-keygen -t dsa
Take the defaults (except for passphrase if you want to be picky)
Now append the generated public key (id_dsa.pub) onto the authorized keys for server:
cat id_dsa.pub | ssh uname@server 'cat >>.ssh/authorized_keys2'

Make certain that .ssh directory is configured with permission 0700 and contents are permission 0600.