Yes yes, Nat, enough about your friends and your conference scheduling toys. What about the sessions? What was hot? What was not?
RT was definitely hot. Everyone I spoke to who had been in an RT session came away raving. I even had one guy send me email looking for the online evaluation forms because he'd had to run away after the RT tutorial but wanted to make sure to give his feedback. Jesse was talking about RT work he'd done for a UK security organization, building an incident response system out of RT. It's apparently the only free one of its kind. As always, I predict RT will go bigger and better places.
Ruby and PostgreSQL were both topics that I'd heard a few people talking about last year, but which everyone seemed to be talking about this year. The war between PostgreSQL and MySQL continues to rage, which is disappointingly stupid--they should be trying to steal installations from Oracle, just as Perl and Python shouldn't be fighting with each other, they should be taking the battle to C++ and Java.
George Dyson's keynote on Von Neumann was utterly brilliant. He really knew who his audience was, and targeted the talk directly at them. He did a great job of drawing parallels between the very early days and the present time, with some hilarious slides showing the trials and tribulations of the early computer hackers. The scribbled paper showing "Let a word (40 binary digits) be 2 orders, each order = C(A) = Command {1-10,21-30} + Address {11-20,31-39}" was incredible--as he said, it's like the "Let There Be Light" of computing.
Ward Cunningham was the talk of everyone, whether his fit project or his Wiki fame. Another Portlander, Dave Thomas, was also the subject of much discussion--his Ruby tutorial was very well-received, and his Pragmatic Programmer book garnered a lot of attention.
Robert Lefkowitz gave a great talk about business models. I cornered him afterward and asked him "so your talk basically seemed to consist of `hey open source people, if you believed [this thing that you say about open source], you'd do [this self-destructive logical corollary]'--did you mean that?" and he laughed and confessed that he had originally written the talk with a conclusion but then realized he didn't really think his conclusion was right, so he turned it into more of a "food for thought" talk. It was great--I have it on video, so expect it to go up as soon as I figure out Final Cut Pro :-)
Maciej Ceglowski was the Perl find of the conference for me. He spoke at our etech, and came highly recommended by Rael, Schuyler, and Ken Williams. So I made a point of giving him a session (which he turned into the very successful "building a better search engine" talk) and a lightning talk (in which he talked about his archive of raw blog material and the kinds of information you can extract from it). He's really thoughtful and razor-edge smart, and reminded me a lot of Sean Burke (but without the frenetic blog).
I heard both sides of Perl6 at the conference. Some folks were enthused, particularly by Damian Conway's utterly mindbuggering implementation of a heap of Perl6 patterns in under a thousand lines of Perl. He very cleverly reused one of the most complex parts of Perl5, its regular expression engine. Larry (Wall) also raised interest with his announcement of Ponie, Arthur Bergman's project to reimplement Perl 5 on Parrot (yay Fotango for sponsoring this!). But I also heard a few people (including one I respect a lot) saying "if Perl 6 doesn't come soon, I'm giving up". I tried to encourage them to take my philosophy: I'll worry about Perl 6 when it's something I can install on my machines. Until then, I'll worry about Perl 5 and what I can do with it.
The Ticketmaster (aka CitySearch) talk on open source patronage had everybody talking. Ticketmaster pay for Stas Bekman fulltime to work on mod_perl. Sean Moriarty, who gave the talk, presented very convincing arguments to the effect that Ticketmaster get lower costs and better issue response from this system than they do from their commercial software and support. I (and everyone else at OSCON) would love to see this patronage model grow and spread. (Major kudos to Ticketmaster for hiring another great mod_perl guy, whose name I'm not sure I can reveal at this point--these guys, like Amazon, are hiring up the cream of Perl because they see clear business benefits for doing so)
--Nat
The war between PostgreSQL and MySQL continues to rage, which is disappointingly stupid--they should be trying to steal installations from Oracle, just as Perl and Python shouldn't be fighting with each other, they should be taking the battle to C++ and Java.
The cause of the infighting is obvious. Everyone likes to think they've made the right choice, so everything else must automatically become the wrong choice. This is sad. Personally, I think Java is a fine language -- if you have the right problem space. I once found myself in the position of recommending Java over Perl due to this, but have listened to people be absolutely astonished that I could even think such a thing.
There is one curious thing I've noticed, though. Most of the really top-notch strong typing advocates that I have talked to seem to think that strong typing is the only way to go. The top-notch dynamic typing advocates that I have talked to admit that both strong and dynamic typing have their place. I suspect that this may be that many people in Perl, Python and Ruby have used strongly typed languages, but not the other way around. I wonder if this is true?
Re:Java and Perl
chaoticset on 2003-07-17T20:15:19
I say with no malice or sarcasm: I'd be fascinated to know what this problem space was.Personally, I think Java is a fine language -- if you have the right problem space. I once found myself in the position of recommending Java over Perl due to this, but have listened to people be absolutely astonished that I could even think such a thing.Re:Java and Perl
Ovid on 2003-07-17T21:06:53
No worries, I realize your question was legitimate and while I'm answering at length, don't take that to mean I misunderstood your intent
:) I won't go into detail about the particular project, but as a general guideline, I think it's fair to say that while Perl can tremendously increase the productivity of individual programmers, Java is still a safer language for many programmers.
In Java, you have to go out of your way to forget to check whether or not your file access was successful. There's not really an equivalent of open FOO, "< $foo"; (note the semicolon). Even changing the checked exception to a runtime exception will still eventually generate an error, if present. There are no such guarantees in Perl. (I think the analogous situation in the Java world is the newbie programmer ending all try/catch blocks with an empty catch that catches a generic exception object.)
Another example would be method overloading. Due to proper method dispatch based on signatures, much of the conditional logic we see in Perl is not present in Java, thus eliminating a major source of bugs:
public void foo (int x)
public void foo (String x)
public void foo (int x, int y)
Those are three separate methods and, if they're all available as method calls for the same object, you rarely have to worry if the correct one is being called. To do that in Perl, you either use Class::MultiMethods or you you write bug-prone conditional logic:
sub foo {
if (@_ > 1) {
# handle int x and int y
}
elsif ( $_[0] =~/^-?[[:digit:]]+$/ ) {
# handle int x
}
else {
# handle String x
}
}Any Perl programmer should see plenty of problems with the Perl version of that. Those problems don't exist in the Java version, but you might think "so what? How often does that become a problem in Perl? Well, what if you have a code base of 80,000 lines and you have to trust that every one of your Perl programmers will always handle that correctly?
Java also lets you declare private methods and data. Java also has data inheritence. You don't have those in Perl unless you jump through a few hoops. When you have a team of many programmers and you fail to notice that one person's bad habit of breaking encapsulation your life gets miserable. $foo->{bar} should almost always be $foo->bar().
Don't get me wrong, though. There are plenty of things about Java that are just a royal pain in the rear, but you'll notice that the Java programmers still publish plenty of code. Just because you found that an autoloaded method call that tweaks the caller's namespace was a perfect solution for that very weird problem doesn't mean that the Java programmer won't find a solution. It may take longer but he or she will get it done.
Perl is concise and powerful; Java is verbose and safe. If you have the money and you can't seem to find quality Perl programmers, the latter might be a better choice. If your choice of programming languages were limited to those two, you would need to assess the trade-offs of legibility, programmer availability, safety, power, expense, etc.
Note that throughout all of that, I was talking about core language issues. There's no need to pull out the tired "applet/device driver" limitations to point out that different languages have different strengths. And note that all of the above is being given by someone (me) who strongly prefers Perl. Regardless of my preference, though, I would be doing myself a disservice if I didn't honestly examine a particular language's boundaries.
Re:Java and Perl
chaoticset on 2003-07-18T02:14:42
Hm.I guess there's a certain divergence in philosophy to some degree. "We want it to be easy to produce powerful things" versus "We want it to be hard to really screw up too badly". (I suspect highly that it makes it sound like I'm not an advocate of the second view. Philosophically, I do disagree with it. I suppose it's like the difference between anarchy and "relative policing" -- if you've got only self-restriction, you have a theoretically high freedom to do good things, but there's always some schmuck mucking things up, and if they don't see a cop every now and again (or get picked up for misdemeanors) then they end up being a serious problem.)
Having said all that, I'd like to be able to crank out Java. I just have this problem -- every time I look at Java, my laziness starts to kick in, and I start telling myself I can save time by not doing an example of X in Java.
Of course, "saving time" is not always the best goal. (Me saying this is tantamount to heresy, as most people who know me well would quickly tell you.) There are times when saving time is wasting time, and it depends on my goal -- if I want to learn Java at all, fiddling around in Perl isn't saving time. If I want a functional screenscraper in a day, Perl is the time saving implied. (CGI being only one example, of course.)
Agreed -- that's why I asked for the information about the problem space. I want to know as many as I can as well as I can. And I hear lots of fine things about Java...I just want to find out why I can't seem to actually do them.Regardless of my preference, though, I would be doing myself a disservice if I didn't honestly examine a particular language's boundaries.Practice is the reason. Clearly, I need to get some.
While we're here, let me ask you -- C++ versus Java, if you've had any exposure to that? Pros, cons, special circumstances?
Re:Java and Perl
VSarkiss on 2003-07-18T14:46:07
That's probably the best two-sentence summary of the languages I've read.Perl is concise and powerful; Java is verbose and safe.Re:Java and Perl
ziggy on 2003-07-17T22:20:27
Just to echo Ovid's points above....I was talking about Perl with a hacker who is now managing a well-funded startup. Now that he's a Real Manager, he has to look at everything with conservative glasses.
If he had a project in mind, had good Perl programmers available, and was reasonably confident that he could find more of them to extend/replace his team, then he'd spec out a project to use Perl. Yes, he'd pay more per programmer and they'd get done faster, but his primary goal is risk mitigation, not time to market or reduced costs. There's nothing worse than starting a project that has to be scuttled later because no one can understand the code.
Ditto Python, Ruby, etc.
If there wasn't a ready pool of talent, he'd go with Java in a second. Easier to find people, and you can handle a team mediocre programmers better. They will be less productive, but they can't do anywhere near as much damage.
He's not alone in this viewpoint, nor is this a new perspective. It's the same kind of thinking that's kept Lisp in the gutter for 50 years.
