Text

· · to read

Here’s a few things that I think would have made my undergraduate career more successful:

  • Consider waiting until after your first semester to declare a major. I started my first semester majoring in Computer Science and never really considered majoring in something else until I was a sophomore. My friends and I were proud that we knew what we wanted to do. Actually, it’s better at this stage to keep your options open. For every degree there are related degrees. The related degrees may have a better department, with more professors, more money, and more research opportunities. Math or Physics would probably have been better choices for me.

    If you’re undeclared, you will have an advisor who’s job is partly to help you pick what to major in. You also may get useful advice from teachers in what to major in when you talk to them after class.

  • Get to know your professors, not just in your the field you’re majoring in, but in one or two others. You may find, after you graduate, that you want to go to grad school or work in the field you have a minor in. It will be a lot easier if you have several references from the new field. In my case, I got a job working on a fascinating project that would greatly benefit from both programming and mathematical expertise. I decided to pursue a graduate degree in Mathematics. I’m applying for admissions right now, and wish that I had built stronger relationships with the faculty in my school’s Mathematics department.

    The learning itself is also a good reason to get to know people in another department. Organizations everywhere want people who are good in multiple disciplines. For example, anyone with a science degree should have a good mathematical background, and that comes partly from getting to know your professors and excelling in courses in the Math Department.

  • Don’t skip classes just because you’ve already taken them at a community college or high school. To me it seemed obvious. Since I’d taken Calculus I and II at the community college, I was ready to take Calculus III. I heard of some other students that were taking Calc I even though they took two semesters of AP calculus. I asked a guy why and he said that he didn’t think he was ready for it. I foolishly assumed that his class must have been a joke and was glad I took it from a fairly good teacher. Only later did it sink in that it may have been a good idea to start with Calc I. First of all, I could have got sorely needed A’s in my first two semesters. Secondly, I would have had more time to build relationships with Math professors. Finally, I would have been less stressed and had more free time for academic exploring during my freshman year.
  • Keep your scholarship. “I can do anything I put my mind to.” It’s good to think this, but only to a certain extent. Confidence is good, but so is rational thought. If you got two A’s, one B, and three C’s your first semester, and need to have a 3.5 GPA by the end of your second semester in order to keep your scholarship or tuition waiver, don’t do it simply by trying to work harder. Do it by taking a lighter load and/or easier courses. If you’re a science major, take business courses, if you must. I made the mistake of taking what the advisor recommended for completing the degree in the shortest time possible, and lost my tuition wavier. For the next several years I worked, and the distraction brought down the quality of my education considerably. I also ended up with a mediocre GPA of 3.01.
  • Have study buddies. I’m not the person to give advice on social skills, but I have seen how important they are. Seek advice on this matter. I’ll be doing the same. I am trying to put into practice the advice in the book Never Eat Alone, which has a lot of interesting suggestions.
  • Go to the library. Chances are, the university library has fewer distractions than your dorm or apartment. So if you’re having a hard time concentrating, go there. Also, browse the bookshelfs in any subject area that interests you. Even if you’re looking for books on Computer Science and most of the books are old, there are sure to be things you haven’t learned yet, even if the examples are in archaic programming languages.
  • Exercise frequently and maintain a balanced diet. One big danger for college students is turning into insomniacs. Sure, you will probably have to pull the occassional all-nighter. But don’t let that become a habit. Frequent exercise and a healthy diet will help you to balance out your sleep schedule. It will also help you to avoid sickness, and to concentrate on your classes.
  • Learn to ask for help. Don’t wait to ask for help until you’re deparate. Ask for help from your teacher if there’s something you don’t understand. Ask for help from your advisor if you’re worried about your grades. Ask for help or advice from parents or other relatives if you see financial troubles on the horizon. Don’t wait until you’re desparate to ask for help. If you do, you will make it harder on yourself and on those who care about you.
Text

· · to read

Anyone who has poked around in the Scheme or Functional Programming community has no doubt heard about PLT, or at least one of its projects, which include DrScheme and the book How To Design Programs. PLT is a group of people spread across four universities that works on a number of projects, some of which involve making really cool software, and others which involve teaching programming.

They’ve created a complete graphical programming environment called DrScheme, which includes a Scheme interpreter, various Scheme libraries, and an IDE written in Scheme using their libraries. It even has its own HTML renderer that is used to implement the Help Desk feature of DrScheme.

They’ve used PLT Scheme (the umbrella name for the different distributions of their Scheme implementation) to build:

  • A PLT web server, which presumably is used to host their own website, which is well designed.
  • A Slideshow application, which Matthew Flatt uses for in-class presentations
  • PLaneT, a package repository for PLT Scheme

Four of them wrote a great introductory programming book, How To Design Programs, (HtDP) which covers a lot of practical programming concepts that were sadly skipped over in my C. S. program.

Using HtDP, they have a TeachScheme! project, which aims to “turn Computing and Programming into an indispensable part of the liberal arts curriculum” [1]. This is an important goal. Even if most people in other fields don’t program as part of their job, I think it’s a good idea for them to learn enough to understand the process of programming, as it often effects their work. HtDP starts at a level that most high school student ought to be able to understand, while still being interesting to a graduate of a state university’s C. S. program. That is an impressive achievment.

I think that in order to make a really good learning organization, you’ve got to have ambitious projects and invite all members to participate. PLT certainly has more than its share of ambitious projects – a Scheme compiler, language extensions, a portable GUI framework, a web server and application framework, a package repository, and an HTML renderer. The same could be said about MIT, with their wide variety of operating systems, graphics, and compiler projects. It should be possible for any school to work on something along those lines. The first step would be for a member of faculty to start an ambitious project, and invite students to participate (hopefully with pay for anyone who does substantial research).

To start an ambitious project, you need something to work on. Fortunately, there are a lot of ideas already out there, and it’s not that hard to come up with an idea. In the words of John Locke:

The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.

John Locke, An Essay Concerning Human Understanding (1690)

A lot of programming projects are started by a programmer noticing problems that take lots of repetetive work to solve, and coming up with useful abstractions. Ruby On Rails was started this way. There’s a very good chance that the next big thing will as well.

[1] http://www.plt-scheme.org/

Text

· · to read

I went to my Alma Mater’s library in search of a book on Common Lisp and found Paradigms of Artificial Intelligence: Case Studies in Common Lisp by Peter Norvig. The book is 946 pages long and covers both AI and Common Lisp in depth. I started working through the Common Lisp chapter and found that it is much richer in features than I expected. I’ve always heard that Common Lisp is quite a contrast to Scheme, but hearing isn’t the same as experiencing it.

One thing that I like about Python is the cleverly designed def (define function) syntax, which gives the programmer all kinds of convenience and flexibility in defining functions (for example, having an arbitrary number of arguments, having explicitly named arguments, or having a combination of positional and explicitly named arguments — details here). Common Lisp has clever function-defining syntax too. Here’s an example of declaring a function with three explicitly named parameters, one of which is optional:

> (defun foo (bar &key (baz 30)) (list bar baz)
FOO
> (foo 30)
(30 30)
> (foo 30 :baz 90)
(30 90)

Another thing Common Lisp has in common with Python is doc-strings. I’ve seen them in emacs before. A doc-string is a piece of documentation that can be put in the function declaration and accessed at run time (or from within the REPL). In both Python and Common Lisp the doc-string goes in between the argument list and the function body.

One cool thing about Ruby is the ability to call a method with a minimal number of keystrokes. If bar has a method named baz with 0 parameters, the code to call it is “bar.baz”. There’s no need for empty parenthesis! In Python “bar.baz” would refer to the method itself. In ruby, to refer to the method itself, it’s “bar#baz”.

Common Lisp uses a hash symbol to refer to a function, but it is for a different reason. Common Lisp, like elisp (Emacs’ built-in scripting language), has a separate namespace for functions and variables. It’s possible (but arguably bad style) to have functions and variables with the same name. To refer to the functions, you add a hash and a single quote before them (e. g. #’foo).

It looks as though Python and Ruby both have inherited from Common Lisp. And that shouldn’t be a surprise – the designers of Python and Ruby have been programming long enough to remember a time when Lisp was more popular.

One thing about Common Lisp that’s often cited when someone mentions how big it is compared to Scheme is the format function. The format function practically has its own language for printing out text, and as Norvig notes, it’s not a very Lisp-like language. But there is also the loop macro, which was given its own chapter in Common Lisp the Language, 2nd Edition.

While I might just skip over learning to use the loop macro, I think that there are a lot of really cool functions and macros in Common Lisp that you could do without, but make things more convenient. It has some things that might seem redundant, but that can be used to code more clearly what you are trying to do. For example, there is a when macro, which is like if, but without the else clause. A Common Lisp programmer that comes upon “when” knows not to expect the else clause.

Another neat thing about Common Lisp implementations in general is that there tends to be debugging and optimization support accessible from the REPL (read-eval-print loop).

My first impression is that when I use Common Lisp, it feels like a mature language. I can tell why Norvig chose it to do lots of AI projects. It has a lot of features people want — it “lets hackers have their way with it” [1]. It’s multi-paradigm. Scheme is a little too focused on one paradigm (functional programming) for my tastes.

[1] Paul Graham‘s essay The Dream Language, form Hackers & Painters, which is not available online (yet). In my opinion, it’s one of his best essays.

Text

· · to read

Eric Sink posted an article bemoaning the current state of the web. In his footnotes is this observation:

I think we need to stop saying that the spammers only continue because they make money doing it. Virus writers don’t make money. They write viruses simply for the joy of causing harm to others. I don’t see much reason to believe that spam would stop if the financial incentive were magically removed somehow.

I agree with him. The idea that spammers will quit if they can’t find any more suckers is yet another piece of conventional wisdom I get tired of hearing. I also think it’s fairly useless to talk about something that’s not going to happen. As long as there are people, there will always be people getting suckered into making bad decisions. It’s human nature.