Hey, we're looking for a programmer. What a timely article Mr Yegge!!!
Ten Tips for a (Slightly) Less Awful Resume
Wednesday, September 26, 2007
7 reasons I switched back to PHP after 2 years on Rails
7 reasons I switched back to PHP after 2 years on Rails
I found this article fascinating and echoing some of the decisions I've made over the last year or so. With my explorations of Ruby early on and now Lisp and Erlang, I've had many of the same thoughts. I'd love to do the "big rewrite". But, with the volume of code we've got in our system, the big rewrite is probably a pipe dream. But, I've already found that my coding patterns have changed dramatically after playing around with these three languages. Learning new languages really does improve your current code writing.
I feel about python how Derek Silvers feels about PHP. It's not as glamorous as Ruby on Rails, but there are an awful lot of things that you can do in python that you can't (yet) do in RoR. Also, I feel like django is very nice compromise. Gives many of the shortcuts that rails does, and then gets out of the way when you want to use sql directly.
I'm also in agreement with Derek about sql. SQL gets a lot of bad press because it doesn't really map to the Object Oriented world that many programmers are comfortable with. But sql is an incredibly powerful tool when used well. There are some things that are awkward in sql (heirarchical data is a big one). But that is offset with the fact that most of the data I work with on a daily basis really is just rows and tables.
Anyway, great article Derek.
I found this article fascinating and echoing some of the decisions I've made over the last year or so. With my explorations of Ruby early on and now Lisp and Erlang, I've had many of the same thoughts. I'd love to do the "big rewrite". But, with the volume of code we've got in our system, the big rewrite is probably a pipe dream. But, I've already found that my coding patterns have changed dramatically after playing around with these three languages. Learning new languages really does improve your current code writing.
I feel about python how Derek Silvers feels about PHP. It's not as glamorous as Ruby on Rails, but there are an awful lot of things that you can do in python that you can't (yet) do in RoR. Also, I feel like django is very nice compromise. Gives many of the shortcuts that rails does, and then gets out of the way when you want to use sql directly.
I'm also in agreement with Derek about sql. SQL gets a lot of bad press because it doesn't really map to the Object Oriented world that many programmers are comfortable with. But sql is an incredibly powerful tool when used well. There are some things that are awkward in sql (heirarchical data is a big one). But that is offset with the fact that most of the data I work with on a daily basis really is just rows and tables.
Anyway, great article Derek.
Wednesday, September 19, 2007
Another great shell hack...
The problem was, we needed to pull the file off the end of the path as returned by subversion status.
ie:
M folder1/folder2/file
M folder1/file2
etc.
we wanted
file
file2
With some help from uber hacker Kelly, we knocked out the following one liner.
svn status | gawk '{ print $2 }' | sed -r 's/.+[/]//'
Which worked beautifully. Thanks Kelly.
ie:
M folder1/folder2/file
M folder1/file2
etc.
we wanted
file
file2
With some help from uber hacker Kelly, we knocked out the following one liner.
svn status | gawk '{ print $2 }' | sed -r 's/.+[/]//'
Which worked beautifully. Thanks Kelly.
Wednesday, September 12, 2007
Beware the black screen of darkness cometh
Black screen of darkness to haunt Vista pirates
Buy the software or suffer the consequences
I truly wonder if Microsoft understands the consequences of their tactics. The harder you squeeze, the more runs through your fingers. Piracy in many ways made them the standard (among other factors of course). But, now one wonders if people won't start moving in other directions. I think it will take far more then this to cause any kind of mass migration. But each little bit erodes their market. As has been said before, Microsoft is their own biggest competitor.
Just a side note, I in no way condone piracy. In the previous paragraph I simply observe that piracy actually helped Microsoft become the dominant player in the market at certain points in their life. Now as the monopoly with no one left to compete with, they are down to making sure everyone has to pay to use their software.
Followup Apparently this story was a hoax. Followup
Buy the software or suffer the consequences
I truly wonder if Microsoft understands the consequences of their tactics. The harder you squeeze, the more runs through your fingers. Piracy in many ways made them the standard (among other factors of course). But, now one wonders if people won't start moving in other directions. I think it will take far more then this to cause any kind of mass migration. But each little bit erodes their market. As has been said before, Microsoft is their own biggest competitor.
Just a side note, I in no way condone piracy. In the previous paragraph I simply observe that piracy actually helped Microsoft become the dominant player in the market at certain points in their life. Now as the monopoly with no one left to compete with, they are down to making sure everyone has to pay to use their software.
Followup Apparently this story was a hoax. Followup
Saturday, September 8, 2007
LinuxMCE - Home media and automation system
I've run across this before and plan to play with it at some point. I currently have an aging mythtv box that I use for incidental recording of tv. But this project seems to take things to the next logical step incorporating phone, lights, climate control and other things into one gui front end. Some fascinating features of the project taken from here.
- media & entertainment with a server for music, movies and tv shows, plus a PVR and DVD Player,
- a home automation system to control everything in the home with touch-screen tablet and Bluetooth mobile phone controllers,
- a phone system with video conferencing,
- a security system that feeds you live video on your mobile
phone when something happens, and lets you speak to visitors through
your stereos, and - a home PC solution.
Immediacy versus Consolidation
Like Kelly, I am a sucker for a good book. I still primarily use google for searching for things day to day quickly. But books are invaluable as well. I think the primary reason a book is useful is because someone has spent the time to in a structured way boil down a whole lot of knowledge and experience into a single concise source. The signal to noise ratio in a book is very high. Where books fall down (unless they have an excellent index as Kelly points out), is quickly finding one reference item. This is where most of the time google is better. Yet, there have been many times where I've gone through several pages of results trying to find a particular recipe or explanation because I cannot formulate a useful query in google. For example, ever wondered how to write a for loop in a language your not familiar in? "For" is a common word, so it can be difficult to actually find what your looking for.
Anyway, I'm a book collector too. Vive les livres!!! If your curious, you can see the books I'm currently reading or working through in the sidebar on the right. If you have other book suggestions, post them in the comments. I might have to make a list of favorite books as well sometime.
Anyway, I'm a book collector too. Vive les livres!!! If your curious, you can see the books I'm currently reading or working through in the sidebar on the right. If you have other book suggestions, post them in the comments. I might have to make a list of favorite books as well sometime.
The way to lisp
A couple of interesting points from a blog I found today.
The way to Lisp | Tux Deluxe
This does seem to be a different perspective then just about every other programming language out there. Whether this is a good idea seems to be a matter of opinion. But, for anyone that has done extensive programming, it is heady stuff for the language to be as malleable as the functions, methods and objects we are writing to solve a particular problem. So, does customization make for better code? Or does it simply obfuscate the code making later modifications more difficult?
It seems that mathematicians have long been looking for a way to rigorously define algorithms as they define proofs. If this were possible, then one would be able to "prove" that an algorithm was correct in how it solves a particular problem. Perhaps even proving that it is without defect. Unfortunately, the normal day to day problems coders solve resist this type of mathematical proof to a great degree. Or at least we have not yet found a way to rigorously prove that an algorithm is correct in most real world problem domains. The closest that can be achieved is using tools such as test cases and code coverage to approach the ideal of a perfectly working application. But even this does not prove that an application will work correctly given all possible inputs to the system. Any moderately complex system seems to breed defects regardless effort of the programmers. The reality is that the human brain is only able to deal with a certain amount of complexity and the average programming project can easily exceed what the average brain can handle. Multiply this by other developers, third party code, release deadlines and it's pretty amazing that most applications work fairly well or even at all.
So, does Lisp help at all with this complexity? The author of this blog entry and many others contend that the ability to build DSL's (Domain Specific Languages) can greatly reduce the complexity of the application by allowing the developer to work in a language tailored to the problem domain. The obvious detraction to DSLs is that a new developer approaching an application must learn the ins and outs of the DSL before being at all productive. The rebuttal to this argument is simply that DSLs are really only a different form of the modules and libraries that get built in any complex application. And regardless of your skill with a given language, it will still take time to explore and understand the application specific libraries that have been built up when coming up to speed on a new project. So, in many ways DSLs are simply an easy way to bring what used to be put into these ancillary libraries and modules into the language core itself.
My personal experience with DSLs is relatively slim in comparison imperative and object oriented programming. Ruby on Rails has quietly (or not so quietly) brought the idea of DSLs into the focus of the mainstream. By building a DSL which targets the database backed web applications problem domain, they were able to radically change how those applications are developed. When compared to the old PHP, Java, ASP or even early python web frameworks, the amount of work to implement a CRUD interface is shockingly small. Once RoR showed the world how DSLs can simplify some tasks, competing projects of varying success have shown up in just about every language.
It seems many developers in imperative and OOP languages are still puzzled by the success of RoR. The common complaint is that there is too much "magic" going on. What if you need to go outside of that addressed problem domain? In a perfect world, the language would allow the programmer to extend the DSL to meet new challenges. Few languages seem to have this power today with Ruby and Lisp being the only ones that I am aware of that do it well. Even my personal favorite python doesn't really implement DSLs well. But who knows where the future may lead. Python has incorporated limited anonymous functions and perhaps someday DSLs will be easier to build someday. Now that RoR has accomplished what Lisp has struggled to do by capturing the imagination of a new generation of programmers and creating buzz about DSLs, perhaps we will continue to see more of these features from Lisp slowly migrate into the mainstream.
The way to Lisp | Tux Deluxe
"...Lisp isn't about writing applications, it's about writing languages"
This does seem to be a different perspective then just about every other programming language out there. Whether this is a good idea seems to be a matter of opinion. But, for anyone that has done extensive programming, it is heady stuff for the language to be as malleable as the functions, methods and objects we are writing to solve a particular problem. So, does customization make for better code? Or does it simply obfuscate the code making later modifications more difficult?
"McCarthy did not set out to design and create a programming language to meet specific programming needs or satisfy a problem domain, rather he was interested in mathematical notation and expressing theory. This makes Lisp unique in the field of programming, and quite distinct from the functionality associated with C or C++. Lisp is a flexible, theoretical language which is primarily expressive."Yet another uniqueness about lisp. Now does the initial focus of lisp more towards mathematics build a stronger foundation then languages written purely from the practical standpoint of solving a problem? As has been pointed out by others, a well written computer language will have a very strong internal consistency. Consistency when well applied, greatly simplifies the programmers job by allowing him or her to anticipate the internal language and library structures without having to look everything up in a reference. Having a strong and rigorous mathematical foundation I would assume greatly enhances this consistency in Lisp.
It seems that mathematicians have long been looking for a way to rigorously define algorithms as they define proofs. If this were possible, then one would be able to "prove" that an algorithm was correct in how it solves a particular problem. Perhaps even proving that it is without defect. Unfortunately, the normal day to day problems coders solve resist this type of mathematical proof to a great degree. Or at least we have not yet found a way to rigorously prove that an algorithm is correct in most real world problem domains. The closest that can be achieved is using tools such as test cases and code coverage to approach the ideal of a perfectly working application. But even this does not prove that an application will work correctly given all possible inputs to the system. Any moderately complex system seems to breed defects regardless effort of the programmers. The reality is that the human brain is only able to deal with a certain amount of complexity and the average programming project can easily exceed what the average brain can handle. Multiply this by other developers, third party code, release deadlines and it's pretty amazing that most applications work fairly well or even at all.
So, does Lisp help at all with this complexity? The author of this blog entry and many others contend that the ability to build DSL's (Domain Specific Languages) can greatly reduce the complexity of the application by allowing the developer to work in a language tailored to the problem domain. The obvious detraction to DSLs is that a new developer approaching an application must learn the ins and outs of the DSL before being at all productive. The rebuttal to this argument is simply that DSLs are really only a different form of the modules and libraries that get built in any complex application. And regardless of your skill with a given language, it will still take time to explore and understand the application specific libraries that have been built up when coming up to speed on a new project. So, in many ways DSLs are simply an easy way to bring what used to be put into these ancillary libraries and modules into the language core itself.
My personal experience with DSLs is relatively slim in comparison imperative and object oriented programming. Ruby on Rails has quietly (or not so quietly) brought the idea of DSLs into the focus of the mainstream. By building a DSL which targets the database backed web applications problem domain, they were able to radically change how those applications are developed. When compared to the old PHP, Java, ASP or even early python web frameworks, the amount of work to implement a CRUD interface is shockingly small. Once RoR showed the world how DSLs can simplify some tasks, competing projects of varying success have shown up in just about every language.
It seems many developers in imperative and OOP languages are still puzzled by the success of RoR. The common complaint is that there is too much "magic" going on. What if you need to go outside of that addressed problem domain? In a perfect world, the language would allow the programmer to extend the DSL to meet new challenges. Few languages seem to have this power today with Ruby and Lisp being the only ones that I am aware of that do it well. Even my personal favorite python doesn't really implement DSLs well. But who knows where the future may lead. Python has incorporated limited anonymous functions and perhaps someday DSLs will be easier to build someday. Now that RoR has accomplished what Lisp has struggled to do by capturing the imagination of a new generation of programmers and creating buzz about DSLs, perhaps we will continue to see more of these features from Lisp slowly migrate into the mainstream.
Friday, September 7, 2007
From the everything can be done in Emacs Dept...
Since I do a lot in emacs, I was pretty excited to run across this plugin allowing posting to blogger from within emacs. Why you say would anyone want to do such an odd and painful thing? Well, if you live in emacs all day long, it's nice to be able to post code snippets and other things directly from your text editor. That's quite cool.
http://buzz.blogger.com/search?q=emacs
Sadly, I haven't figured out how to get it to work yet. I followed the instructions at the link above and was able to sign in (do I really have to enter my name and password every time). But after that, nothing really seems to work. Maybe one of you really smart people out there can leave a comment explaining how to use it.
One other note, I'm using emacs 22 and since it's not the default emacs on my system, I needed to change the make file to point to the right emacs file. After that everything compiled cleanly.
http://buzz.blogger.com/search?q=emacs
Sadly, I haven't figured out how to get it to work yet. I followed the instructions at the link above and was able to sign in (do I really have to enter my name and password every time). But after that, nothing really seems to work. Maybe one of you really smart people out there can leave a comment explaining how to use it.
One other note, I'm using emacs 22 and since it's not the default emacs on my system, I needed to change the make file to point to the right emacs file. After that everything compiled cleanly.
Python lambda functions
Even though python doesn't have support for full blown lambda functions as in functional programming languages, the lambda functions it does have are incredibly useful. One of the most common idioms I use lambdas for is when I have a list of objects and need to pull out one attribute from each object into a string. So, for example, let's say I want the name attribute of every object in list l. Perhaps the first version of the code might look like this:
Now, with lambda support in python, we can actually reduce this down to a single line of code. Let's start with just the
That line of code will walk the list and return a new list containing only the names. Now, I really want a string instead of a list, so to convert this into a comma separated string, I would do this...
Which will return something like: "Name1, Name2, Name3". It's pretty nice to be able to clean up seven or eight lines of code with one.
You can start to see a little bit of the power of anonymous functions shining through. Since our primary language at work is still python which is not a functional language, this is a little way to make code more concise and take advantage of some of the benefits of functional programming.
Filter and Reduce are two more ways to build anonymous functions which respectively return a filtered list or reduce the list to a single value. The following link is an excellent resource for learning more about anonymous functions in python and why they are useful.
Python: Lambda Functions
# Concatenate Names together in comma seperated list
# l is a list of objects with an attribute called name.
firstTime=1
rtnStr=''
for item in l:
if firstTime:
rtnStr+=', '
firstTime=None
rtnstr+=item.name
Now, with lambda support in python, we can actually reduce this down to a single line of code. Let's start with just the
rtnList=map(lambda x: x.name, l)
That line of code will walk the list and return a new list containing only the names. Now, I really want a string instead of a list, so to convert this into a comma separated string, I would do this...
import string
rtnStr=string.join(map(lambda x: x.name, l), ', ')
Which will return something like: "Name1, Name2, Name3". It's pretty nice to be able to clean up seven or eight lines of code with one.
You can start to see a little bit of the power of anonymous functions shining through. Since our primary language at work is still python which is not a functional language, this is a little way to make code more concise and take advantage of some of the benefits of functional programming.
Filter and Reduce are two more ways to build anonymous functions which respectively return a filtered list or reduce the list to a single value. The following link is an excellent resource for learning more about anonymous functions in python and why they are useful.
Python: Lambda Functions
Shell scripting is really Cool
One of the things I really love about shell scripting is the ability to quickly automate a task by linking a bunch of little programs together with pipes. Here is a little one liner that takes all new files in the current directory or below and runs svn add on them so that they are ready for a commit. I got tired of typing svn add file1 many times. Especially useful when working with large numbers of files that all have to be added at once.
svn status | grep ? | awk '{print $2}' | xargs svn add
A File1
A File2
A File3
A ...
svn status | grep ? | awk '{print $2}' | xargs svn add
A File1
A File2
A File3
A ...
Thursday, September 6, 2007
Changing keybindings in Firefox...
Something I do many of times a day when switching back and forth between emacs and firefox is try to search for a text string on the page in firefox. Unfortunately, in emacs search is Ctrl-S which maps to save page in firefox. Well, I save pages rarely enough for it to ever be useful having it bound to a key sequence. So, I went searching for a firefox extension that will let me fix this one annoyance that drives me crazy a couple of times a day.
Today I found it with Keyconfig. With the Keyconfig extension I was able to find the "Find in page..." function and map it to Ctrl+s and disable the save page. That's one more annoyance I don't have to deal with.
You can download it from here if your interested.
Today I found it with Keyconfig. With the Keyconfig extension I was able to find the "Find in page..." function and map it to Ctrl+s and disable the save page. That's one more annoyance I don't have to deal with.
You can download it from here if your interested.
Wednesday, September 5, 2007
Erlang versus Scheme
Another benchmark pitting Erlang against Scheme. Erlang soundly trumps even the scheme compiled to C version. Erlang seems to do well in the speed department at least in microbenchmarks.
Cross Polination is a good thing
I've loved working in python personally over the last five years or so. As I've become interested in concurrency and more functional styles of programming, it's been fascinating to find how many of those concepts have made it back into python in some form. I just never noticed them because I was so used to imperative programming styles. Cross polination is a good thing. I would probably not have started to look at some of these concepts in python except for trying to learn them in other languages.
So, even if you cannot use a new language your day job, learning languages like Lisp, Haskell, Erlang, Smalltalk, etc can teach you new tools and ways to look at particular problem domains. It's amazing how quickly that can change your programming style.
So, even if you cannot use a new language your day job, learning languages like Lisp, Haskell, Erlang, Smalltalk, etc can teach you new tools and ways to look at particular problem domains. It's amazing how quickly that can change your programming style.
Erlang versus Stackless
A somewhat surprising set of benchmarks regarding stackless python and erlang.
It's interesting that python held up so well against erlang. I'm still trying to find out whether stackless python can take advantage of multiple cores and/or machines as erlang can. One would think that the benchmarks would tend to skew pretty heavily once you moved in that direction. Anyone know if stackless python is multi-core or even multi-machine aware?
It's interesting that python held up so well against erlang. I'm still trying to find out whether stackless python can take advantage of multiple cores and/or machines as erlang can. One would think that the benchmarks would tend to skew pretty heavily once you moved in that direction. Anyone know if stackless python is multi-core or even multi-machine aware?
Subscribe to:
Posts (Atom)

