Over the weekend I got some reactions over the str.join() vs list.join(). Well, just for fun, this morning I played “what if” in my head.

So, let’s say every iterable got a join() method. So you could

>>> a = ['s', 'l', 'o', 'w']
>>> a.join('')
slow

Exactly as JavaScript does. Mkay. A could even be a tuple and would still work. Or, stupidly enough, a string and still work. But, then, what would be the first thing that would cross you mind when you saw this code for the first time:

>>> a = ['s', 'l', 'o', 'w']
>>> b = ['r', 'u', 'l', 'z']
>>> c = a.join(b)

You have a list in one side and a list in the other with a “join” method. List-join-list. Well, I’d expect another list with ['s', 'l', 'o', 'w', 'r', 'u', 'l', 'z'] which is what extend() does.

But let’s return to the original str.join(): What it does is, join the iterable in the parameters using “self”. Mkay, so what would be:

c = ['r', ['s', 'l', 'o', 'w'], 'u', ['s', 'l', 'o', 'w'], 'l', ['s', 'l', 'o', 'w'], 'z']

Which doesn’t make any sense.

Let’s go further. join() could, possible, call str() for the parameter and still react like JavaScript join(). Why? Well, as you may already know, Python have dynamic typing which means any variable can be used. Just to remember:

var l = ['s', 'l', 'o', 'w']
var j = l.join('')

would result in “slow” in JavaScript. Mkay, so

>>> l = ['s', 'l', 'o', 'w']
>>> r = ['r', 'u', 'l', 'z']
>>> j = l.join(r)

Would result in… guess what, "s['r', 'u', 'l', 'z']l['r', 'u', 'l', 'z']o['r', 'u', 'l', 'z']w" which, not surprisingly, still doesn’t make sense. Ok, if r was a simple string, it would react exactly like JavaScript. But it would be a mess with any other types. And what’s the point of dynamic typing if you force types?

So, str.join() not only makes code simpler and avoid some mess of monkey-patching, it also removes a greater problem: ambiguity.

And yes, I understand that JavaScript list.join(str) makes sense, but it still have the problem with “What about the other types? Are you a racist?”

Edit: Just for curiosity, I wrote a list.join(list) code in JavaScript to see the results. Here they are for you mind-bloggling pleasure:

js> var l = ['s', 'l', 'o', 'w'];
js> var r = ['r', 'u', 'l', 'z'];
js> var j = l.join(r);
js> j
sr,u,l,zlr,u,l,zor,u,l,zw

When I was in Australia, one guy kept asking why Python had the “horrible” (in his opinion) str.join() instead of obvious (in his opinion) list.join()?

After working with JavaScript for a while, I can understand his opinion: In JS, you have a list.join() of sorts and it makes a hell lot of sense.

But, then again, this morning it finally hit me: str.join() uses an iterable object as parameter, so any iterable object will work. For example:

>>> p = 'python'
>>> '-'.join(p)
'p-y-t-h-o-n'
>>>

Ok, this is understandable, but why not have a list.join() too? Well, this would mean that every iterable object would have to have a join() method (str.join(), tuple.join(), dict.join(), list.join() and all the new iterable objects that appeared in Python 3.0.) Since the C API for Python doesn’t allow object hierarchies (and all base types are implemented in C), the same method would have to be implemented over and over again. Not only that, but you would have several different ways to join() stuff instead of one, (now) obvious way.

Another way to fix this would monkey-patch every object to have a join() method, but that’s not the Python way. Monkey-patch is never the Python way.

And the same rule applies to len(): it takes any iterable due the same reason.

THIS IS AN ALPHA RELEASE! We want to test most of the new features, code and interface to be sure that things are going to the right way. Some features (like DBus notifications) are disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• Fixed a crash (just internal, Mitter would still run fine) when deleting messages.
• Fixed an issue with Python 2.5. It seems that, from time to time, I add some feature that only exists in Python 2.6. From this point, I’ll try to make Mitter compatible only with the previous minor release from the current stable version. So, when Python 2.7 is launched officially, Mitter will require at least Python 2.6.
• Added support for coloring Hashtags, users and Groups (not a Twitter feature, but it’s used in Identi.ca, so I’m just paving the way for future networks.)
• The statusbar will try to keep more important messages displayed. Smaller updates (i.e. “Message deleted”) will appear for about 10 seconds and then disappear, showing the time to for next update.

Download details and full list of of changes in this release are available in project home page.

THIS IS AN ALPHA RELEASE! We want to test most of the new features, code and interface to be sure that things are going to the right way. Some features (like DBus notifications) are disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• Added better support for reporting errors. Some things are still missing, but most of the errors should now be properly reported (instead of just pointing that “something went wrong.”)
• Fixed a problem with Mitter start up when there are not networks set up.

Download details and full list of of changes in this release are available in project home page.

THIS IS AN ALPHA RELEASE We want to test most of the new features, code and interface to be sure that things are going to the right way. Some features (like DBus notifications) are disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• This is the second major code rewrite of Mitter. The first rewrite added support for multiple networks; this rewrite split the PyGTK into some more files, to make it easier to manage it in the future.
• The update area is hidden from the start from now on. To post an update, you need to select “new message” or simply press “Enter”. The update area will then appear. This gives more area to see the messages.
• Fixed a couple of problems with Python 2.5 (I accidentally added a feature that only exists on Python 2.6.)
• Fixed a problem when marking all messages as read.
• Added a simple “ago” in the message time text.
• The number of unread messages now can be displayed in the window title (check the CHEAT-CODES file if you would like to change the format.)

And yes, the plan was to make Alpha 4 the last of the alpha releases and add oAuth support. Problem is, oAuth is a mess to implement and absolutely impossible to find a good document about it. Since it was taking too long, I decided to fix a few other issues. I won’t make any kinda of promise this time. ;)

Download details and full list of of changes in this release are available in project home page.

THIS IS AN ALPHA RELEASE! We want to test most of the new features and code to be sure that things are going to the right way. Some features (like DBus notifications) were disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• Fixed an error when favouriting a message in the replies tab.
• Fixed an error when setting up Mitter for the first time.
• Fixed UTF8 incompatibilities when posting on Twitter.
• Fixed an error when using the menu button (or Shift+F10).
• Fixed the status of the message actions after an update.
• Fixed the status icon when there are no new messages but new replies.
• Fixed the menu so Settings is also visible.
• Added proxy support.
• Added priority for interfaces, so PyGTK should be chosen when running Mitter for the first time.
• Added indicator for protected messages.
• Added functionality to minimize Mitter to tray.
• Added action to mark all messages as read.
• Added a timeout for requests.
• New Deb packaging. As Mitter, it should be considered Alpha quality and, thus, we are still testing it.(deb is now available)

This should be the last release in the alpha series. Next thing should be oAuth support for Twitter and then the beta cycle will start with a Tk interface and Identi.ca.

Download details and full list of of changes in this release are available in project home page.

THIS IS AN ALPHA RELEASE! We want to test most of the new features and code to be sure that things are going to the right way. Some features (like DBus notifications) were disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• I18N: All visible strings for the user should now be marked as translatable. A bunch of scripts to keep the translations were added in the repository to help translating Mitter. Any help (testing if the translations are in the right place, new translations) are really welcome in this phase. New translations can be added in the Project Page as an Enhancement issue.

THIS IS AN ALPHA RELEASE! We want to test most of the new features and code to be sure that things are going to the right way. Some features (like DBus notifications) were disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• General:
  • Added missing files in the install (via setup.py.)
• Twitter:
  • Fixed links to reposts.
• PyGTK:
  • Fixed display of names with “&”.
  • While typing messages, “Del” won’t try to delete the selected message.
  • Actions on messages selected in the “Replies” now work.
  • “Replies” are marked as such in the message lists (with a “in reply to” message.)
  • Removed the “Ctrl” for sending and canceling messages. “Enter” will send the message, “Esc” will cancel.
  • Added missing libraries in the install (via setup.py.)

For the next alpha, I want to mark all strings as “translatable”, paving the way to internationalization.

THIS IS AN ALPHA RELEASE! We want to test most of the new features and code to be sure that things are going to the right way. Some features (like DBus notifications) were disabled at this point to make sure the base code works without a problem. If you want to help, remember to run Mitter from a terminal with the “-d” option (to display debug messages.) Any help is welcome.

• New, redesigned network layer. This should make things easier for new networks.
• New, redesign configuration files. This should make to upgrade for newer options if they appear.
• Most (if not all) hardcoded values were moved to the config file. URL colors, URLS, you can change them by simply changing a config file instead of messing with Python code.
• Repost (retweet) support in PyGTK interface (working with the Twitter protocol at the moment.)
• Proper reply support for Twitter
• Replies are shown in the main window.
• Favourites.

More info, bug reports, what needs to be done, downloads and everything else is available in the project page.

Go is a new language created by Google that recently went open source and generated a lot of buzz in the interpipes.

As someone who have been working as programmer for almost 20 years and worked with almost a dozen languages and, on top of that, have a blog, I think I’m entitled to give my biased opinion about it.

One of the first things that got me off was the video pointing that the language is faster. Or the compiler is. Honestly, pointing that you become more productive because your compiler is fast is utterly wrong. If you’re aiming for a new language and you want people to be productive with it, make it so it’s easier to write code right in the first time. If you need to keep compiling your code over and over again till it does the right thing, you should probably check if there isn’t any impairment in the language itself that prevents right code to be written in the first place.

Which brings us to my second peeve about Go: The syntax, as presented in the tutorial. Syntax, in my opinion, is the biggest feature any programming language have to offer. If the syntax is straightfoward and easy to understand, it makes easier to have multiple developers working on the same code; if the language allows multiple “dialects” (or ways to write the same code), each developer may be inclined to use a different approach to write the code (which basically does the same thing) and you end up with a mess of a code where most developers would feel like rewriting than fixing a bug or adding a feature.

The first thing that caught my eye was the “import” statement that at some point uses a name before it and a block in the second example. Why two different ways (well, three if you count that one is probably optional — in the middle of the statement, nonetheless!) to import other packages with the same command?

Variable declaration also feels weird. “a variable p of type string” is longer to read than “a string p” (comparing var p string := ""; with C way string *p = "";). And that goes on. If you keep reading the statements in their long form (expanding them to natural English), all commands start to feel awkward and adding unnecessary cruft on the code, things that could be easily dismissed and force people to do less typing.

The “object” interface seems derived from JavaScript, which is a bad idea, since JavaScript have absolutely no way to create objects in the proper sense. And, because object attributes and members can be spread around instead of staying grouped together, like in C++ and Python, you can simply add methods out of imports. Ok, it works a bit like duck-taping methods in existing objects, but still can make a mess if you add two objects in one file and people decide to add methods just in the end of the file: You end up with a bunch of methods about different objects all spread your code, when you could “force” them to stay together.

So far, those were my first impressions of the language and, as you can see, it was not a good first impression. Focusing on compile speed instead of code easiness/correctness seems out of place for current IT necessities and the language seems to pick some of the worst aspects of most languages around.