New Year, New Language
As we head into 2003, a lot of people are making New Year's resolutions. Many of these resolutions will last only a few weeks (just go look at all the exercise equipment in the used sports shop in February), but I hope to keep mine this year.
I've read that one way to keep yourself motivated is to tell other people about your resolution, even inviting them to join you. So that's why I'm here. Hopefully, this idea will be worth thinking about. If you decide to join me, great! If not, I'll just pretend that you're going to pester me at some point about how I'm doing. I'm sure it'll all work out in the end.
Earlier this year, I picked up a copy of 'The Pragmatic Programmer' (a great book by Dave Thomas and Andy Hunt). I really liked many of the ideas I read there. One which resonated with me was this:
"Invest Regularly in Your Knowledge Base."
A method they recommended was to learn a new programming language every year. They even set up a wiki and mailing list to help coordinate people who'd like to work together.
The idea behind this goal is that by learning a new language, you learn more abut programming in general. You might find new techniques to bring back to your own favorite languages, or you might find a new favorite language. To really make this effective, you could look into languages outside your normal programming style -- Never done OO programming? Try Smalltalk. Spend all your time with compiled languages? How about really learning a shell.
Last year, the Language of the Year (LotY) group worked together to learn Haskell. I joined the list too late to start with them, and wasn't really interested in Haskell either, so I puttered around learning more about Ruby. This year, I've decided to get serious about things. I started out thinking about two languages I might try my hand at: Objective C and Forth.
I've never been much of a hand with compiled languages, and I've been hearing about Objective C again, so it seemed like it might be a good direction to go in. Programming Ruby gave me an 'Aha!' experience with OO, but it's so dynamic that I think I'd be able to learn a lot from doing OO in a compiled language as well.
On the other hand, Forth seems like it would teach me a lot about very low level programming. It's a language that keeps popping up on my radar screen, but which I've never pursued. This might be a great time to do something about that.
In the end, I decided not to go with either of these languages. Not that I wouldn't learn a lot from either one of them, but I found myself pulled in another direction. Two more tips for 'The Pragmatic Programmer' jumped out at me.
The first tip that caught my eye was:
"Use a Single Editor Well"
Well, I'm a systems administrator by background, so I've gotten used to many different editors. 'vi' (or one of its descendants) will always be there, 'emacs' offers a ton of features, and there are others that (for one reason or another) have been the right tool at one time or another. For day to day use, I've settled into emacs. I know that I only scratch the surface of its feature set, but it seems to fit my style better than anything else.
The second tip that helped push me towards my final decision was:
"Learn a Text Manipulation Language"
I already know enough Perl, awk, and sed (along with the various shell tools for manipulating text) to get along, but I could certainly stand to learn how to make my manipulation of text easier, faster, and better.
With these additional thoughts floating around in my head, I was poised for a blinding flash of the obvious. As I was browsing around a book shelf, I stumbled on a copy of An Introduction to Programming in Emacs Lisp by Robert J. Chassell -- voila, my LotY.
I snatched up the book, and started to brew a plan. My first thought was to see what other books were out there that might help. There's one from O'Reilly, Writing GNU Emacs Extensions, but it just didn't feel like the right place to start. I've come to agree with Emacs creator Richard M. Stallman that there should be free documentation for free software. Not that proprietary books don't have a place, just that they're a second layer of information. Maybe I'll grab a copy later and see where it takes me. There's also the two volume Emacs Lisp Reference. This looked like overkill for a primer, but will certainly be on my list for later in the year.
With an initial book in hand, I laid out a schedule for myself. I'm going to work through 'An Introduction ...' during January, then start looking at projects. I'm not sure what I'll hack on yet; improvements to the Ruby mode maybe (hmm, refactoring support would be yummy), or maybe a mode to support writing skits and plays (my wife would like that), I might even try my hand at writing an interface to Koha, a free software library system I manage. Working on projects like these would certainly provide a good excuse to dive into the Reference books.
I figure that running through these books and concentrating on some interesting projects will really help me master Emacs Lisp. I don't know yet what kinds of tricks I'll learn this year, or what other benefits I might gain. I'm excited to get started though, and I'm sure that something good will come of it. Who knows, I might even come back later in the year to tell you about it.
What about you? Hopefully, reading this has started some juices flowing for you too. Whether or not Emacs Lisp is the right LotY for you, take a look at the wiki noted above. If you decide to work on a LotY yourself, join the mailing list. If you do decide to work on Emacs Lisp let me know, we can check up on each other. If you decide to work on something else, you can tell me that too -- I'd be happy to ping you about it occasionally.
-- -pate http://on-ruby.blogspot.com
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- KDE Reveals Plasma Mobile
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python