Text

· · to read

Another Steve Jobs quote (via SvN):

Most people make the mistake of thinking design is what it looks like. That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.

I love how he uses first-person plural here (presumably by “we” he means Apple). It’s part of his Reality Distortion FieldWP. I think Apple employees have a strong sense of “if you weren’t great you wouldn’t be working here”. Sure, not all Apple employees are great for the company, but the feeling is very encouraging to those who are, and it leads many people to achieve great things.

Text

· · to read

Code Completion is a nice IDE feature that, for example, shows a list of methods for an instance of an object. It’s called IntelliSenseWP in Microsoft Visual Studio WP; in XCodeWP it’s just called “Code Completion”. It’s a very fast and user-friendly way to look up methods — while editing JavaWP in XCode, as soon as the user enters a period after a variable name, a list pops up, and as the user types it continues to narrow it down based on the first few letters. Documentation may also be displayed.

While XCode and most Java and .NETWP IDE‘sWP support this well, it’s a bit more difficult to implement for dynamically-typed languages like PythonWP and RubyWP. This is because of the difference between dynamic and static type systems WP. In a static type system, the type is determined at compile time, so the IDE can compile the code on the fly and find out the type. In a dynamic type system, the type is determined at runtime. Since running code can make changes to the system, such as deleting files, code can’t simply be run by the compiler to find out the type. Also, the type of a variable can vary, depending on a program’s input.

IDE’s for dynamically-typed languages implement Code Completion by examining the code. In a dynamic language, however, it’s impossible for an IDE to make a perfect guess as to which type a variable will be, in a given line of code, or which of several types it could be. It’s possible to let the user tell the IDE what type it’s expected to be. By guessing what type a variable has and letting the user override the guess, an IDE can have pretty good Code Completion for a dynamically-typed language.

One issue is, however, how does the IDE remember the user’s setting? Is it in a project file? I don’t really like having information for a file stored in a project file, since when the file moves between projects, settings are lost, or you have to go through the IDE’s way of moving the file between projects. Another possibility would be using a dot file (e. g. .foo.rb.ide-options) in the same directory. This is the way jEditWP stores bookmark settings. I don’t like this option because since they’re hidden I’m always forgetting to move them, and because it’s a pain to delete both the file and the bookmark file at the same time (I don’t like typing something like rm *foo.rb* because it will include baz_foo.rb). That leaves a couple options – including it right there in the source file or using a different naming scheme. This is easy to move around, but I’d rather keep these mundane details out of the source file.

This leaves using a different naming scheme. Perhaps foo.conf or foo._name_of_ide_. Whenever python runs a module, if it can, it automatically compiles it to bytecode and places it in a file with the same directory and name but with a different extension (pyc vs. py). I find that I have no problem with .py and .pyc showing up in my source directory. It’s nice to know that it’s byte-compiling it, and it’s easy to move around and delete (just use a wildcard expression like foo.*).

There’s no reason the metadata file can’t include all kinds of other things. I would want it to be extensible, and to include such things as bookmarks as well as Code Completion hints. This information could be stored as XML, YAML, or (my favorite) an S-Expression. Perhaps limiting it to things that only happen in the IDE would be a good idea, or maybe it could include instructions to the compiler to improve performance as well.

Another thing needed is a way to identify a variable inside a source file. I think the most elegant way would be a path containing the scope it’s in and the name of the variable. This would be something like my-namespace/my-class/my-method/param/bar. In an S-Expression format with the type and a construct for entering several in the same scope it could be something like:

(with-scope 'my-namespace/my-class/my-method'
  (specify-type 'param/p' 'Person')
  (specify-type 'local/brother' 'Person')
)

This would declare the parameter my-method and the local variable brother to be of type Person.

Finally, a quick way to declare the type in the IDE would be useful. I would like a right-click menu that goes something like this:

Popup Menu
+(other options…)
+Code Completion Type
++Auto
++(recent options)
++Custom…
+(other options…)

The Auto option would go back to having the IDE guess the type of the object. On a related note, I really like “auto” options that there are in office applications. It makes it really easy to say whether you want to stick with whatever the parent options are or specify your own options.

I have visions of a Lisp dialect with a great library and a great IDE getting a bit of a following and creating lots of LISP jobs. I think good support of code-completion while still having run-time typing, a dull color for parens, and built-in performance analysis WP tools (as Paul Graham suggested) would generate a lot of interest.

Thanks to Eliazar for the idea of using superscript to link to Wikipedia and other online resources.

Text

· · to read

There’s a damn impressive demo of the next version of BackPack on Signal vs. Noise.

It shows a cross-platform web application with main items draggable up and down on the page, todo items draggable within and between todo lists, and images draggable horizontally. Part of making it work well involves showing drag handles only when elements are hovered over. This is a really clever way to stretch the limits of browser technology.

What it really shows, though, is that a small company with only a few great hackers can do things that are just as impressive as what hundreds of Googlers can do in building GMail. And I bet they did it in a tenth of the amount of code.

I just don’t think a business person could commission anyone to come out with something like the new version of BackPack. It’s too creative for it to be done just by throwing lots of money at the problem.

Text

· · to read

“Good morning to everyone”, said Tim, smiling at the front of the table. “Before we start, we’d like to ask you to hold your questions until after each presentation. Each pitch is about ten minutes.”

“I can’t do that”, said Jobs. “I’m not built that way. So if you want me to leave, I will, but I can’t just sit here.”

— Steve Jobs (found via Signal vs. Noise).

Text

· · to read

One doesn’t have to live long in NYC to understand one of the non-obvious benefits – the ability to completely disappear into anonymity as an individual if you really need to. It’s quite easy to lose oneself, in a good way, on an island humming with the presence of 3 million people. Folks living in other places don’t seem to comprehend the typical New York City experience of living in a 500-unit apartment complex for years, and not knowing any of your neighbors. Some might shudder at the thought…I find this aspect of life in New York quite appealing.

I like the Brooklyn accent. It may not be a sound oozing sophistication or sex appeal, but it does give its owner an almost brazen air of confidence in almost any social situation. Great stuff!

From New York City by Andrey Butov.

Text

· · to read

Luke Plant pointed out that Python, in contrast to Java and C#, makes templates unnecessary most of the time. In Java, a minimal program has a class definition and a method definition. In Python, the minimal template is an empty file.

The advantage of this is the ease of diving in and writing code. You don’t have to set up and/or use templates in an IDE, copy and paste, type boilerplate code in manually, or run a command-line script to get started.

As Luke points out, Django is the same way. This is one way it differs from Rails. In Rails you run script/generate.rb to generate a model from the database definition or a boilerplate view or controller. This is the way that is taught in the tutorial.

In the Django tutorial, the reader is instructed to simply type the code in and save it in a text editor. And as Luke points out, Template Inheritance makes it so adding a new page with the theme of the main page involves only three lines of code.

I also like how the models are structured. In Rails, you run script/generate.rb and a model file is generated, along with tests and a “migration file”, and you repeat this for each class (a class corresponds to a database table). In Django, you make a module file in the “models” directory, and each module file can contain however many classes you want it to. Sometimes it makes sense to have multiple models in a file (when there are tightly coupled models) and other times it makes sense to give a model its own file. Django gives the developer the freedom to choose how to structure the model directory.

I feel more in control when I use Django, because once the initial directories are set up, I add things starting with blank files and writing them using my own style. No boilerplate comments or tests are there to distract me. Also, since I don’t have multiple files being generated at a time, in different directories, version control is much simpler.

There are a number of other design decisions in Django that I like, some which differ from how Rails is designed, and some which are the same. The success of Django, I think, comes from being a well-designed and innovative framework, written from the perspective of its creators (the same could be said of Rails). I think this is why it has more mindshare and a bigger community than imitation frameworks.

I think that starting an open source project that imitates another as closely as possible, but on another platform, is a bad idea. Not only does imitating result in copying mistakes, it also results in copying style, which inevitably get mixed with the style of the copier. I think it’s better to figure out which features are needed from the existing project’s platform, and to adapt them, one by one, to fit well into the new project’s platform, and to the style of the developers and users of the new project.

Text

· · to read

I love NYC. I visited for a week, and found the experience absolutely amazing. There is so much to see and do.

The best parts of the experience are meeting people and just walking around. Central Park is beautiful, and I like walking down the streets of Manhattan and seeing the interesting mix of new and old buildings, people, shops, and restaurants. I also like the MTA (subway system). For about twenty bucks for a week, you have a pass for a subway network covering all boroughs, except Staten Island, which is not accessible by Subway, but is accessible by a free ferry. There is more to see in those boroughs, at least when it comes to human civilization, than there is in all of Arizona. In Arizona, however, I have to drive for transportation, and it is expensive enough that going to new places is a rare experience for me, even on weekends.

Today I received a random e-mail from a recruiter about a Java web application job in NYC. I said I don’t have Oracle experience, but he was still interested and said I could probably get an interview. The mere thought of moving to NYC gave me butterflies in the stomach. How I would love to return, and visit the zoos and museums, walk around, and go to interesting clubs like LispNYC.

So I set forth to learn more about programming in Java. I am very motivated in this endeavor. One of the requirements for the job that I got the e-mail about is Spring. So I decided to pursue a project that I’d been planning to do in Java Swing (a desktop GUI framework) and do it in Spring, as a web application. I’ve been working my way through a tutorial, figuring out how to get a good setup with Tomcat, Ant, and Spring. Next I’m going to hook a PostgreSQL database to it.

I’ve heard good things about Spring. Some people like it even more than (gasp!) Rails. So far I’ve just entered the first sample code for a controller:

import org.springframework.web.servlet.mvc.Controller;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
public class TileEditorController implements Controller {
  public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
  {
    return new ModelAndView("");
  }
}

A class named ModelAndView! Interesting. I imagine if Java had support for tuples, Spring probably wouldn’t have that class. I think in absence of tuples, however, it’s a perfectly valid way of doing it. Quirky, but good.

Some things are complicated. Other things are just quirky. I don’t think it’s good for a developer to let quirkiness get in the way. In fact, I think a lot of the time it’s just a fact of life, that can not only be accepted, but enjoyed.

Just as I enjoy the quirkiness of buildings in NYC, which are full of character, and take on a life of their own, I can appreciate a clever solution to a programming problem that reality brings. I think of programming now more as a series of steps. If I have to do something needlessly complicated to complete a simple step, that’s annoying. If I have to do something straightforward but a little quirky, that’s OK by me!

Text

· · to read

Dharmesh Shaw posted a humor piece to his excellent blog at OnStartups.com. I thought the part for strategy type was the funniest (particularly because I’ve had a strategy type for a supervisor before):

Strategy Type: Forget the light bulb. We need to stop skating to where the puck is, and skate to where the puck is going to be. In five years, there will be no light bulbs to change. I’m going on an executive retreat next week and plan to return with a vision statement that articulates how we will leverage our core competencies to erect a formidable barrier to entry in the $1 billion market for LaaS (Light As A Service).

Text

· · to read

Today Bruce Eckel posted a blog entry called When Reuse Goes Bad. He tells of a project he was sent in to fix, as a consultant:

The main design and technical problem (ignoring for the moment Weinberg’s maxim that “No matter what they tell you, it’s always a people problem”) was that the contractor had decided that this was an opportunity to develop a reusable software system, and that they could develop this system on the customer’s dime.

This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer’s problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.

This reminded me of a post by my friend Eliazar, where he proposes a new dictum, Use before you reuse.

As I ponder on these points, I think of Paul Graham‘s essay Taste For Makers, where he states, “Good design solves the right problem.” When I think about getting at the heart of the problem, I think of the chapter about Use Cases in The Pragmatic Programmer. If the goal is to design a non-trivial library for thousands of users with many different usage patterns, how do you get at all the use cases? You can’t. The thing to do is to make something that solves one problem well, and adapt it, one by one, to solve other problems. Eventually, it will solve a lot of problems.

I think the Linux kernel is a good example of this. The first Use Case was Linus Torvalds running it on his own computer. In time it was adapted to run on many different computers and to do many different things. It had fewer growing pains than other things that were built Cathedral-style.

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.