I've been waiting for this for a long time...

4:39:40 PM    comments ()  trackback []  

Yeah. What he said. (go read it.)

1:26:16 PM    comments ()  trackback []  

Doc trashed Oddpost for being MSI5/Win only and Doug Hacker pushes back and speaks for me. Pushing the envelope is great no matter what. Doc's feelings are irrelevant. In the past users, esp Mac users, have pushed this button to quickly. If a breakthrough happens and users flock to Oddpost, that's good. I see Mac users these days getting lots of stuff that Windows users don't have (I use Windows) and that's cool too.  [Scripting News]

I think I know where Doc is coming from. But I tend to agree with Dave. A few years back, I remember Dave posting about another web site that was trying to design pages with broadband in mind, so they were very graphic heavy, and had a lot of JavaScript for interaction. I remember thinking that it was very pretty and fun to play with, but I also felt like it was threatening my bandwidth.

You know when you get a new fast computer, and then companies start adding feature after feature to the software, so that the computer ends up feeling as slow as the one you replaced? That web page made me fear that the same thing was going to happen to my bandwidth. Web pages were going to bloat more and more, until my cable modem started feeling like a 28.8k connection again.

But it never happened, because the increase in broadband speed and adoption has not followed Moore's law.

I have since changed my mind. We DO have to keep pushing the edges. We have to keep having faith in Moore's law. We have to believe that we will continue moving forward, because the alternative is stagnation. I see that now.

In fact, some of the design decisions that I've been making for my current Python project have been based on what I think will get faster, rather than what is fast today. The code I've been writing to play with the Radio ODB from Python uses the following transformations:

ODB -> table.tableToXml() -> XML-RPC -> fTableXML -> python

and then back as:

python -> XML-RPC -> table.xmlToTable() -> ODB

The problem is that it is slow. It's been suggested that I toss XML-RPC and try to go direct, but I don't see that as gaining much. The XML-RPC overhead is not as big as you would expect. By far the most processing time is being spent in table.xmlToTable and table.tableToXml. I have a very good reason to keep using XML-RPC and the table verbs, and that is that UserLand is VERY committed to the utility of XML in general, and XML-RPC in particular, so I see those verbs as primed for kernelization, thus getting rid of most of my speed problem.

So, yeah, it's a faith thing, but I can see it happening.

Of course, another way to go about it is to add Python hooks to Radio, or expose the ODB entry points so I could write some C to couple Python to Radio. It should be somewhat simple to make Radio call Python.

1:37:31 PM    comments ()  trackback []  

This is where I start losing steam.

Oh well. I've made some decisions about the current Radio project I'm working on. Soon there will be some code to play with.

1:53:15 PM    comments ()  trackback []  

I went to my first 2002 Mariner's Game tonight. Exciting, and yet ultimately quite disappointing. Oh well. I still have 15 more games to see.

While exploring the iRights site looking through the Radio/Jabber interop work that is happening (I enjoy interop a lot), I happened upon this.

I find that project very interesting, because it fills a hole for me. It makes it much easier to do Python/Radio interop.

I will have code to play with very soon.

11:08:10 PM    comments ()  trackback []  

Get an idea, plan it, write it, test it, fix it, test it again, ship it.

I love it when it happens.

1:51:36 PM    comments ()  trackback []  

If you have any suggestions about what would make it better, let me know. I'm working on Jython support and a Preferences page right now.

6:42:52 PM    comments ()  trackback []  

It helps that he likes my project... ";->"

I really like it when he says: "Scripting is really just programming by another name. (Don't tell a programmer I said that)." This squares completely with my experience, and leads right into a provocative question I like to ask when programmers turn their noses up at "scripting languages." I ask them how they define a scripting language. Unless they've thought about that subject a bit, they'll usually respond with a definition that makes Java, C++, or any number of other languages into "scripting languages."

Truthfully, I'm not quite sure that dividing programming languages along the lines of "scripting" and "non scripting" (or, as I've run into quite a bit: "non-serious" vs. "serious" programming languages) is useful.

Bottom line: programming is programming, and the same skills are needed whether you are using a scripting or non-scripting language.

1:24:04 PM    comments ()  trackback []  

It was fun, but it did distract from the game itself, even though it was easy after about the third inning (getting the rhythm down helped). Don't know if I'd do it all the time.

8:03:26 AM    comments ()  trackback []  

Make up your own joke here.

3:31:10 PM    comments ()  trackback []  

http://www3.telus.net/latrippi/netvironments/ continues along the lines of using analogies to learn new programming environments.

2:42:37 PM    comments ()  trackback []  

Hmmm.  Is this real?

Ahh.  April Fool, but a day late for me.

1:27:37 PM    comments ()  trackback []  

I'm playing with Cocoa, and therefore I've been playing with Objective-C. Background: I've wanted to play with NextStep and Objective-C since they came out. When OO extensions to C started to come up (C++, Objective-C), I'd hoped that Objective-C would dominate, mostly because I came to OO via Smalltalk, and I wanted the syntax. (I'm weird.) C and C++, however, paid the bills. I never had the opportunity to program a NeXT. Playing with Cocoa is the fulfillment of a wish I once had.

The problem is that I love being able to declare my variables anywhere, as you can in just about every scripting language, C++, and Java. I love it becuase it allows you to group variables with the code that chiefly concerns them. It's a nice way of structuring your code.

I can't do that in Objective-C, because it is based on C, for head-shakingly obvious reasons. All variable declarations have to be made at the top. Arguments can be made that variable declarations must always be made at the top. Many of them are compelling. I am even convinced by others. But I still like to declare them as I go. I like to limit the information necessary to understand the code.

Oh. The argument that is convincing? 'If you have a hard time keeping all the local variables straight, your method is too long.' It's a Code Smell.

6:01:52 PM    comments ()  trackback []