Public Void - Programming Blog (Beta)

A programming blog covering C/C++, Java, Perl, PHP, Python, Ruby, Ruby on Rails, and UNIX/Linux shell scripting.

Wednesday, July 23, 2008

Installing UCB-STk on Cygwin

UCB Scheme

I have been watching the Berkeley Webcasts of Brian Harvey's CS61A lectures and I wanted to run the same version of Scheme that he is using in his class. I got it running, and I thought I'd share how to get it working if you already have Cygwin installed on your Windows system.

To that end, I made some notes on how to intall the University of California Berkeley's distribution of Scheme, UCB-STk on Cygwin, which runs in Emacs. The short of it is that you simply need to extract the STk packages from the UCB Cygwin distribution. The STk download is somewhat misleadingly labeled. It presents itself as the STk installer, when in fact it is an entire set of Cygwin packages. Once I did this, I was rockin' along with Brian as he argues but first of sentence....

Labels: , , , , ,

7/23/2008 01:26:00 AM | Installing UCB-STk on Cygwin

0 comments

Sunday, August 12, 2007

An Introduction to Ruby on Rails

Ruby on Rails

I recently stumbled upon some sample videos from "Ruby on Rails Essential Training at Lynda.com.

Ruby on Rails has enjoyed really huge buzz all over the Web the past few years, but I've never really looked what that buzz was about--at what it is and what it offers. If you don't know already, Ruby on Rails is essentially a web development framework based on the Ruby programming language.

Ruby on Rails code

I highly suggest that anyone involved in web development at least check out what Ruby on Rails has to offer. There are a number of excellent screencasts of Ruby on Rails in action at the Ruby on Rails site, particularly "Creating a weblog in 15 minutes."

Labels: , , , ,

8/12/2007 04:47:00 AM | An Introduction to Ruby on Rails

0 comments

Sunday, March 18, 2007

Regular Expression Matching Can Be Simple And Fast

(but is slow in Java, Perl, PHP, Python, Ruby, ...)

Graph comparing efficiencies in regular expression matching in Perl, Python, Ruby, awk, grep, tcl, and others

"Some might argue that this test is unfair to the backtracking implementations, since it focuses on an uncommon corner case. This argument misses the point: given a choice between an implementation with a predictable, consistent, fast running time on all inputs or one that usually runs quickly but can take years of CPU time (or more) on some inputs, the decision should be easy."
Russ Cox

This paper by Russ Cox is a very interesting discussion of efficiencies in regular expression matching.

(Vim has joined Google Summer of Code 2007, and one project idea is to increase the efficiency of Vim's syntax highlighting and regular expression matching.)

Labels: , , , , ,

3/18/2007 12:46:00 PM | Regular Expression Matching Can Be Simple And Fast

1 comments

Sunday, February 18, 2007

Measuring Programmer Productivity

I am currently taking a Statistics class—a subject I was not at all thrilled to have to study. Typically, when I have to take a class that I don't enjoy, I force myself to find some personally applicable good in it so that I not only perform better in the class, but in order that I find the value in the subject. I told myself that Statistics is a subject heavily applicable to Computer Science and that I should look for ways that I could apply the general concepts I am learning to specific problems in Computer Science. So, over the past six weeks I have attempted to look for those things, I am surprised (though I shouldn't be) to find just how many times I find myself stumbling over Statistics in computing without even looking.

I happened upon this Google Tech Talk today and I ended up watching all 50 minutes of it. Two students from UC Santa Barbara give a presentation on a project they have begun to statistically measure programmer productivity—specifically in MPI and UPC, programming languages used in HPCS.

While the presenters, Viral Shah and Vikram Aggarwal, admit that the project is still a nascent effort, they were eliciting the suggestions of those attending in the hopes of building a "better mouse trap" and perhaps writing some tools that could be used for statistical analysis of programmers elsewhere, using additional programming languages.

And indeed, there were a number good points addressed. One listener addressed the questions asked of programming students in the study. This lead to interesting ideas regarding the comparison of how a programmer perceives their productivity versus how productive the statistical data shows them to be.

There are a number of fascinating issues related to this idea of programmer productivity, not the least of which is the age old debate of which programming languages are more efficient than others for human productivity or for computing productivity. I hope to see more on topic this in the future.

Labels: , , , ,

2/18/2007 02:16:00 PM | Measuring Programmer Productivity

0 comments

Tuesday, February 13, 2007

So you want to code for Google?

I've always been interested in what it takes to work at Google, specifically as a programmer. So I decide to do a little research to see just what Google is looking for in a Software Engineer. Below is a Google Spreadsheet containing a list of search results from Google's Job Search engine.

I must preface all of this by saying that this is a very informal analysis. The precision of the information is subject to a number of factors including the scope of the search engine, the search terms themselves, and the time the searches were performed—to name a few. Search terms that yielded no results are not included.

What is interesting is the amount of Free Software included in this list. Searches for proprietary technologies yielded virtually no results, or results that did not apply to Engineering. If you were paying attention, you noticed that the URL for Google's Job Search is a "py" file. So even it is written in a free programming language (Python).

Top 10 Skills for a Google Programmer

  1. HTML
  2. Bachelor's Degree
  3. Master's Degree
  4. Linux
  5. UNIX
  6. C/C++
  7. Java
  8. Python
  9. Perl
  10. Ph.D.
  11. SQL (Mostly MySQL)

So if you plan on working for Google someday, well, there's your hit list. Stay in college—particularly a Software Engineering/Computer Science program—and learn to code programs that integrate with databases for POSIX systems.

Labels: , ,

2/13/2007 07:28:00 AM | So you want to code for Google?

0 comments

Monday, February 12, 2007

Literate programming

Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
Donald Knuth, "Literate Programming," The Computer Journal: 1984.

I ran across this quote today in a blog entry on programming quotes. I find the concept interesting, although, with only a cursory look at what defines it, I wonder if this wouldn't be very difficult to implement in a structured manner at any level. It would seem that it bears a lot of resemblence to the concept of self-documenting code, which is actually more a function of the programming language than any programmatic style.

Still, the concept is interesting and worth a bit more reading. Don is obviously an accomplished and well-respected voice in the world of programming, so it would be well worth a prospective programmer's time to consider his thoughts on the issue.

2/12/2007 05:08:00 PM | Literate programming

0 comments

Monday, November 06, 2006

Choosing Your Goggles: Ruby or Perl, Python or Rails

An analysis of four language creators

In my continuing my exploration of programming languages, I happened these insights on four programming language creators.

What sticks out here is the assertion of programming language creators as progenitors of a culture of thought. The idea that programming languages and their associated syntax shape thought-process and design solutions is not new, if significant. What is interesting to me an aspiring programmer (or at least, a pupil) is looking not just at the syntax itself but also the philosophy and intent of each language's respective creator. Languages are designed to solve communication problems but, as Muli points out, the problems evolve as cultures evolve, and so languages must evolve with them. And so, more than technical prowess, the philosophical aspects of a language creator's intent determine its longevity and, more importantly, its ability to address those evolving problems.

It would follow, then, that Muli's investigation here is advisable for every new programmer--if only to familiarize oneself with each, as one would with each language's benefits and respective syntax. To that end, I am going to listen to the talks that Muli did, and will post any further remarks from these language creators and perhaps some others.

read more | digg story

11/06/2006 09:18:00 AM | Choosing Your Goggles: Ruby or Perl, Python or Rails

0 comments

Lists

Google Groups
Subscribe to treehead.net
Email:
Visit this group

URLs

treehead.net blogs

treehead elsewhere

Previous Posts

Archives