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
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
|ServersCheck's Thermal Imaging Camera Sensor||May 25, 2016|
- Secure Desktops with Qubes: Introduction
- Secure Desktops with Qubes: Installation
- Working with Command Arguments
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- CentOS 6.8 Released
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- ServersCheck's Thermal Imaging Camera Sensor
- Petros Koutoupis' RapidDisk
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide