Bye bye Emacs, Helloooo Sexy (TextMate)

If programming editors are a religion I am an Apostate.

While reading up on Ruby, I came across videos of people writing code real time. First, it is cool Ruby can do high level things in short programs. So short you can watch people coding real time. Second, more apropos, several different presenters were using this cool editor I'd never seen. I thought it was Vim with some crazy programming mode turned on. It completed statements and other coding constructs, speeding up the process of writing code.

This new editor was TextMate. It is a MacOSX app only. It has some simple bourne shell-like extension language. Or you can use any language you like. They come in "Bundles". Bundles exist for every language under the sun. Further Bundles exist for Version control systems. Checkin, checkout, update, branch, whatever. With windows to prompt for commit messages and the like.

The Git bundle allows you to switch branches real time. It even switches the files you have open in the editor. It has full colorization display windows for diffs and commit logs.

I have only scratch the surface of TextMate. You can start using it without having to buy into some IDE monstrosity like Eclipse. From what I can tell it rivals Eclipse or other IDEs for full Web Application development. Apparently it can run a full Web Application stack and support all the languages (Ruby/Python/Perl, HTML, CSS, and Javascript) side by side.

I haven't used it for so involved a dev environment. But I like how it allows you to start small and simple, then build up to the full stack development environment. From what I can tell this applied equally to (Configure, make, C/C++) or (Ant/Maven, Java, SWT) or (Rake, Ruby on Rails, Web) Application stacks.

I am still just playing with simple Project editing. My projects tend to be libraries and Server-side stuff anyways.

I took a look at perl5...

and found Modern::Perl. I always put use strict; use warnings; and such things in my code. use Modern::Perl; does more and is succinct. Apparently use 5.10; turns on say and the given ... when switch extension. There is a book about modern styled perl that is worthwhile for even experienced Perl programmers. It is the impetus of the Modern::Perl module. You can by the book or download an electronic version here.

I've always liked Perl. I found the blather about "line noise" and classes not compelling. Given the number of newbies using all this perl code, it can't be that impossible to read and write (though newbie code usually blows in any language). Classes are hard/complicated? The quantity and quality of CPAN code begs to differ.

I always thought that a switch was one of the features perl needed. An automatic line separator after each print statement is good. That it is short is even better. Two things come to to mind. One, Perl5 is alive and well. Second, what is left for Perl6?

To the second point, I answer, Grammers. I have looked at Grammers with wonder. Grammers provide a method to parse a full (programming) language. The key element that is hinted at is that each level of parsing provides a hook to attach code. So if people, say cpan authors, write a grammer for parsing C code and publishes it; then you can write code to use those hooks. The code is something like C::Grammar.parse($str, :$actions);.

If someone implemented Grammers in Perl5 there maybe no need for perl6.

'Nuff said.

Just compiled rakudo perl6. Perl6 is UGLY!

Simple things like getting the last element of an array have gotten grotesque. Perl5: $arr[-1]. Perl6: @arr[*-1] ughhh! I don't mind the '@' sigil; that change makes sense. But '*' in the index *-1 doesn't make sense on the face of it.

Why such a change? I didn't look deeper. It is such a non-intuitive change to such a common idiom.

Another seemingly unnecessary change: inline comments. The code goes $x = 1 #`(add one) + 1;. Why would I want to do that? In the 2+ decades I have been coding Perl professionally, I have never felt the need for inline comments. How does that help? How doesn't that obfusicate code?

Perl has a bad rep for being indistinguishable from line noise (or a cat walking on your keyboard). These two changes jumped out at me. They messed with the simple idiom for accessing the last n'th element of an array and added an unnecessary "inline comment" syntax that looks like more gobbleygook.

Supposedly, part of the design goals of perl6 was to make common things easier. So we have $obj.method() instead of $obj->method(); ok fine. And we have '$' for scalars always; '@' for arrays; and '%' for hashes to denote type rather than context. But what is that star '*' doing in the index of the array.

I was looking forward to Grammers as a very powerful tool. Talk about a text munging chainsaw! But some of these other changes are making perl6 very un-perl. Or rather, making perl6 indulge in the worst parts of old perl.

I haven't been paying much attention to perl since 5.8.1 . I hope someone has backported some Grammer-like construct it that is the case, then screw perl6!

Still dealing with the old problem of Logging

Well it is two issues:

1. Finding the basename of the program or module your code is within.
2. Setting up the logger given the answer to the previous issue.

NOTE: I am playing with some CSS to display code. I am using the simplest which is applying a class to a div.


Getting the Fully Qualified Directory Name (FQDN) of the project directory; assuming the program is in a project/{bin,sbin,script} directory.

require 'pathname'
BASE_DIR = Pathname(__FILE__).dirname.expand_path(Dir.pwd).parent
puts "BASE_DIR=" + BASE_DIR.to_s
LIB_DIR = BASE_DIR + 'lib'
puts "LIB_DIR=" + LIB_DIR.to_s
$:.unshift LIB_DIR.to_s

Set up the logger format. This doesn't grab the library name or line number.

log = Logger.new(STDOUT)
log.level = Logger::DEBUG
log.progname = File.basename(__FILE__)
log.datetime_format = "%Y-%m-%d %H:%M:%S"
log.formatter = proc { |sev, dt, prog, msg|
"[#{dt.strftime("%Y-%m-%d %H:%M:%S")}] #{prog}(#{Process.pid}) #{"%-5s"%sev}: #{msg}\n"
}

I am thinking of adding more data into each line. Like PID, line number, class/module name, and function. It is alot but if you are using the logs for debugging more the merrier and while I prefer maintaining the sanctity of 80 columns for code. Ultra wide log lines is not sacrilege.

Also, there are two more questions to be answered: do I repeat this code in every file? how do I abstract it into a library?