Monday, August 16, 2010

Somehow, I'm really not sure what is worse: the curse of experience or a gringo's rush.

Concept: tried Quassel IRC, didn't like it - good software but not my bag. Switched to ircII - love the interface, don't want to screw with hacking it. IRC clients are simple creatures but tend to be crap. While I could live with (or suitably script) ircII to my hearts content, I also want a more Windows usable client too.

Problem: When it comes to programming languages and what I want (something very ircII like, yet rather lisp like in a way). I can see all the pluses and minuses of any given implementation. If I was a nub, I would just pick a language, rush into it, and try and dig myself out.

Knowing so much can sometimes be a real let down \o/.


For those that don't know it, ircII is a very old school IRC client, even by the best CLI-whorish standards.

The typical IRC client is arranged as a text display area, for the current channel; a line edit for your messages; modern ones include a panel to list names in channel and some "Tab" like interface for marking the channels you're chatting in. Text mode IRC clients work this way too.

ircII on the other hand, routes everything into a central display area and places a line edit under a "Status line". Rather than jocking between tabs to see what's up in other channels—which is very wasteful, even when using keystrokes: in ircII you simply use a command to change your current channel. Exempli gratia:

Typical:

  1. Click #chan1 tab
  2. Read what's going on
  3. Reply if desired
  4. Change back to #chan0
Becomes:
  1. See what's going on both in #chan0 and #chan1
  2. Use /j #chan1 to make your subsequent messages go to #chan1 instead of #chan0 until the next /j[oin] command.
It's just more convenient for me than the 'modern' user interface. I like efficiency.


In terms of implementing something like this portably (unix/win), the issue is simply line editing. That's not a subject I enjoy. Having worked on a unix shell, I know it's a bitch of a subject. Colour support is another, but minor one. Cmd.exe doesn't understand what a DEC does.

I also want something dynamically reprogrammable on the fly, basically access to a REPL. O.K. so lisp spoils you. This makes dynamic languages more convenient; which is also it's own can of worms.


That's the fact of Programming, it's all a Kobayashi Maru problem: you've just got to deal with it.

No comments:

Post a Comment