Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
As I said previously, my concern about learning a new programming language from scratch is that even with a head start--having the Tk GUI programming model etched in my head, thus making part of the process a matter of translation to the new language rather than learning an entirely new approach--it would be time-consuming. I wouldn't know the best way to do things, I might run into unexpected speed bumps, and it would just generally be a step backward.
That's proven to be the case, in some ways. Programming a Tk GUI is harder from Python than from Tcl, my main programming language. There are little differences in how things are done, some cool things just haven't been translated from Tcl to Python yet, and I've had to find some new ways to accomplish things that are easy for me in Tcl.
Furthermore, I've had to adjust to the different language itself. Python is a very different language from Tcl, I'm discovering. Despite some similarities, there are more differences than I expected.
So PacketStream isn't ready yet. I had done a rough prototype of it in Tcl, but rewriting in Python is more than just a matter of translation. There's a "Python way" of doing things that differs from the "Tcl way," for better or worse.
I don't want to bore you with the technical details, but I'll offer one example. Tcl is generally termed a "procedural" programming language. You write code that does stuff to data, and organize your code around the functions, or procedures, that it follows--in other words, the way the program does stuff.
Python, by contrast, is an "object-oriented" language. You can write Python code in a procedural fashion, but code tends to fall more easily into "object-oriented" organization--in other words, into categories in which related procedures and data are collected together. In procedural programming, the relationship between data and functions is more or less arbitrary; in object-oriented code, there is some conceptual or logical relationship between all the stuff in a single object category (or "class").
There is a lot of arguments among programmers about which is better, procedural or object-oriented programming styles. All I can say is that object-oriented is more complex, especially up-front; it may pay off later in large-scale projects.
My first take at PacketStream (as well as some smaller little projects) was to write Python in a procedural fashion. This is very natural for me in Tcl, but in Python I kept tripping over my own toes. So I eventually decided to re-write PacketStream in an object-oriented fashion, using classes.
It's not complete yet, but I can say that it's going more smoothly than the procedural version of PacketStream did. So I'm glad I decided to give Python and object-oriented programming a try; it definitely feels like I'm expanding my skills (by developing proficiency in a new langauge) and also expanding the breadth of possible solutions to a particular programming problem that might present itself to me.
I'm still not convinced that Python is the solution to every problem; I still find Tkinter too limiting compared to programming a Tk GUI in Tcl. I think if I need to develop a really sophisticated or complex GUI in Tk, I can do that more easily from Tcl than Python. I also believe I can develop more quickly in Tcl than Python, at least right now. But Python is an incredibly robust language, with a large standard library and many extensions, and can do some things that Tcl simply cannot; there's at least one unreleased application on the product list at my main website that would probably lend itself much better to Python than Tcl.
So, when I release PacketStream (hopefully in January), it will look very similar to the other applications I've already released. But under the hood, it will be very different.