Entries Tagged 'Software Development' ↓

Very well stated Guido!

Thanks to Reddit today, I saw this posting from Guido Van Rossum about the recent flap about the GIL in Python:

On 9/13/07, Andy Wiggin <andywiggin at gmail.com> wrote:
> I thought the discussion was very interesting. I think true parallel
> programming is the challenge of our time, so I’m quite disappointed
> that the Python powers that be do not seem to feel any imperative to
> address it. I’ve always been kind of assuming that Python would
> provide a “pythonic” parallel programming paradigm that would “just
> work” and be as elegant as the rest of the language.

I’m sorry, but this attitude just really pisses me off. Python is the
work of many people. If you want something to happen, make it happen.
Don’t wait for someone else to solve your problem for you.

–
–Guido van Rossum (home page: http://www.python.org/~guido/)

Guido is 100% right. I used to (and some times still do) sit around waiting for someone else to take care of a “problem”. That’s certainly one way to approach a problem, but it is even better if you can get into it, figure it out and produce your own solution. That is the way to truly gain new wisdom (and to learn all kinds of interesting new things).

I have discovered several times that simply waiting for someone else solve your problem is a horrible compromise to make. It usually lessens the quality of your code because the solution isn’t a perfect fit for what you are doing, and overall keeps you from gaining the true deep knowledge that is oh so helpful when debugging.

Not to mention the fact that so many open source projects have gotten their start because someone (like Guido) got tired of waiting for someone else to do something. I think its a great that Guido has been so up front with this whole GIL issue: He has said that if someone will do the leg work and prove a better way that is still backwards compatible he will welcome it. The key thing is that he said “someone” and not “I” or “me”. This encourages more people to get involved, and for a community based project/product/language, this is a great thing.

So, kudos to you Guido! Keep up the great work! And please note that I am not saying that “Not Invented Here” syndrome is the way to go, I am saying: Don’t wait for a patch, see what you can do yourself to fix it!

The trials of indie game development

I saw today that a indie developed “Fallout inspired” RPG was being taken down by the author due to lack of sales. This bummed me out because:

  1. It sounds like a game I would have really been interested in
  2. Although it had been out for some time, I had never heard of it
  3. I’m wanting to make a RPG that isn’t based in a dungeon
  4. The world needs new games that aren’t just derivative sequels of the same-old-same-old

Its always sad when a product is retired, but this situation sounds bad. According to the comments on the Ramapant Coyote site, lot of people are feeling the same way I do. But at the end of the day, its the author’s call, and in this case the author decided to pack it in.

I stated in #4 above that the world is too full of games that aren’t anything special. That’s why indie games are so exciting. Many are of the games that are made on the indie seen are passion works on the part of their creators. As a result these games are different than what you normally find in a store. They try new things, they take chances.

But sadly, just as in real life, sometimes you win, sometimes you loose. I hope Mr. Moffat finds the success he is looking for in his future endeavors.

A shortfall of Python: no function overloading

I’m a big fan of Python. It has little quirks that can be annoying (like having to specify self.method() instead of using scoping rules to look at the class first), but overall I really like the language. But today I ran into a shortfall that I really stubbed my toe on: Python (as of 2.5) doesn’t support function overloading.

For example, this snippet of code won’t run:

def a():
print “This is a”

def a(x):
print “This is a(x)”

a()

Instead it will just tell you that TypeError: a() takes exactly 1 argument (0 given) presumably because the second function (a(x)) seems to overwrite the reference to the first one. Further reading on the topic shows that a fix for this might be coming in the future (see Guido’s blog entry for details).

The strange thing for me is I never noticed this until recently. The only reason I ran into it was because I wanted to do some refactoring where it made sense to have an overloaded method. Or at least that’s what I would have done in Java.

Not having this option available is having an interesting side effect in that it made me step back a little bit and evaluate the “big picture” a little bit more than I normally do. Which in this case isn’t a bad thing, hopefully it will cause some me to stretch in new directions and discover my inner OO-Architect…

Business Rules and the Visitor Pattern

One thing I really love about Python is that you can really knock things out quickly with it. I’ve been thinking about business rules lately, and specifically about how to make them cleaner with respect to your code.

When it comes to rules, there are several places and ways you can encode them in your application, each with its own pro’s and con’s. Lately I’ve been reading a lot about Lisp based languages and every now and then I’ll read a reference to using Lisp code not only as a configuration file, but as a “executable” that carries its own data.

The more I thought about this, the more I wondered if this type of separation was possible in Java. Sure, I could just code the rules in Java, but where’s the fun in that? Via its reflect package, Java can do some pretty neat tricks, so I decided to try and code up some ideas in Python first since its so concise (and can also do reflection, etc.). Basically a case of “anything you can do, I can do better”.

A while ago I read a really interesting article about the visitor pattern. Most of the time this pattern is explained in terms of something like a driver: You have some kind of hardware that needs to call a driver to setup its connection to the system. Using the accept() and visit() methods you can make a class that can register itself with the caller and allow it to configure itself, the end result being that the caller doesn’t need to know (i.e. be linked with) the details of the visitor.

It occurred to me that this is the same situation with externalized business logic: The rule engine is reading in an external file and then based on the contents of that file, executing code. If a “rule” implemented the visitor pattern, and the “rule engine” implemented the accept(visitor) method, then this would allow the external file to dictate what the program would be doing without the program needing massive changes to alter the rules.

It boils down to this: defining the core actions separately from the rules allows a better separation between  the two. The visitor pattern allows the two to be bound together. The end result is cleaner (smaller) code, that should be more “testable”. At least that’s my theory.

I’ve put the python code implementing this up on my project page (here is the code). Its a very simple example, there is one rule per line, and the first token (space delimited) is the function to call followed by its arguments. Internally the RuleEngine class is calling Python’s eval() function and that is what actually executes the function from the data.txt file.

For the function to execute successfully it needs to exist (i.e. it needs to be defined in the file, or be a built-in Python function). Note that this is not the safest approach, it will allow malicious code to execute. A more secure way to do this would be to set up a dict (or, if this is done in Java a HashMap) that contains a mapping between the rule tokens and the function to be executed. That way the execution of the RuleEngine can be controlled somewhat, in that it will only allow certain functions to be executed.

Simple graphics on a Mac. Why is that so hard to do?

I don’t want a copy of Photoshop. Its not that I’m cheap (that’s a whole other story!), its just that I don’t like using sledgehammers to kill mosquitoes. I’m trying to do some simple bitmap editing and it has turned into a big headache because it is hard to find a simple graphics editing program.

I was using Pixen which is highly regarded and does just what I need it too. Buuuuuut… I can’t get the program to run more than a few minutes without a crash. And that just really bums me out because it seems like the perfect program. Sadly, I’m not the only one having this problem, posting around the net seem to indicate that this is a common issue.

And unlike Windows, the Mac doesn’t seem to come with any simple programs a-la Paintbrush. What’s up with that? I realize Apple is all about minimal cruft and what-not, but this really takes it to an extreme.

For the moment I’m trying out tileeditor which is a pretty minimal editor, but at the same time seems to work pretty well. (Although as a side note I would like to point out that you need to start the editor in the same directory as your artwork, otherwise it seems to try and save to the wrong directory. Every time I did this is put _tmp and the front of the path, which of course doesn’t exist. I’m not sure if this is a Mac specific thing, but just starting the program in the art directory seemed to get around this issue.)

Lisp/Scheme and business logic

I’ve been thinking about business logic lately. Specifically about how to make nice flexible rules without hard coding them in the code itself. This has led me to look more at Lisp-y languages like Scheme and Erlang. (I’ve got some more to say about Erlang, but that’s a topic for a later post.)

At any rate, today on Reddit there were a few really good postings on this topic and one of those postings led me to more really good articles on the topic. (As a side note, I’m really glad this happened today, lately reddit has been a dumping ground for picture links and other uninteresting things.)

While none of these links shows exact methods for implementing business rules, they are a great starting spot.

These links also mention a lot about XML and the associated headaches that come with working with it. As one of them pointed out when you (modern programmers) think about storing data, XML usually springs to mind first. Past experiences with XML and XSLT have left a weird taste in my mouth: They seem like they are on to a good idea, but the execution and use of it just feels so contrived. These articles enlightened me to think about the data with more of a functional “lisp” frame of mind.

Lots of food for thought. Lately I’ve been thinking a lot about the MVC pattern and how it is trumpeted all over the place, yet sometimes it doesn’t seem to solve the core problem of getting the application out the door to the user in a timely and maintainable manner. (And when I say that, I am thinking mostly of web apps.) Perhaps this is a better way…

Refactoring observations

Its almost spring time and I’ve been doing some spring cleaning both at work and at home. Yes, its refactoring time.

For the most part I like refactoring. It’s a chance to go back and tighten up the code, correct earlier guesses, and just make things nicer looking. One thing that has really been hammered home to me is the type of refactoring you are trying to do depends greatly on the underlying design and what you are trying to change about it.

Example: One of my home projects is an RPG game written in python. I started out with one code base, and began changing it to meet my ideas/needs. Over time it has change two more times. Yesterday I noticed that a major class (the display that draws the tiles to the screen) had not really been migrated and could use some attention. As I began trying to work in the new changes I saw why I put the project down a few months ago: there’s got to be some major changes because the class is so different than the new architecture. As a result, most of the refactoring tools/techniques I’m used to using (at work)
just can’t be used right now.

At work, I’ve got a pretty well laid out architecture (coded in Java) and most of my refactoring work revolves around streamlining and consolidating methods and classes. The refactoring tools in Eclipse make this a breeze because everything is pretty straightforward. (Also, the strong typing of Java is really helpful in this area, its much easier for Eclipse to figure out what a member variable is in Java than it is in Python.)

The moral of the story? I think it’s best to make sure you build in some flexibility to your designs. This will allow you more choices down the road, especially as you discover new techniques for your particular language. As always, the tools are helpful, but they can only do so much to help you.

Learning never stops

No matter what you do, no matter what you are best at, you can always learn something new. This is an awesome article about being a better developer. Anyone of the tips in the article is a starting point for a project to learn something new. Revisiting them will make you a true master of your craft.

Programming is all about moving forward. Being a better developer and making better software is the only way to achieve this.

Fullscreen editors - The new battlefront

There’s a bit of controversy going on about Mark’s post about full screen writing apps. Mark doesn’t quite see the point of the application (it basically is a word processor that takes up the whole screen) and makes some comments about how he doesn’t like this. His comments were a bit over-the-top, and of course, people took exception to this.

But this is nothing new. Emacs vs. vi, Whopper vs. The big Mac, Windows vs. Mac vs. Linux, Kirk vs. Picard. There have been many holy wars before, and there will be many more. And like most of them, this is one is over something seemingly small and insignificant.

For some people these apps are the best thing since sliced bread. Myself, I don’t really get the appeal of the application. If I want “full screen” editing, I usually just maximize the window, but I’m simple like that. To each his own I suppose, no one is forcing you to use the app.

But one thing I do get is the cool free publicity that these apps are getting! WriteRoom is the leading full screen editor for the Mac, and with Mark’s blog post making the front page of Reddit, I imagine that it is getting a lot new traffic which translates into new sales. At $24.95 a pop, even a dozen extra sales will mean a few extra hundred dollars for the developer.

That’s not too shabby. Hopefully this little flare up will result in the developer (Hog Bay Software) winning a few new customers. Mac Developers can use all the free attention they can get… :)

The future of programming

This is an interesting time to be in the world of computers. The web is becoming more and more to everyday computing for the average user. Applications are moving off the PC and onto the web. Hardware is getting faster and faster (check this out, 80 cores on 1 chip for less that 100 watts!), and things like Operating Systems are beginning to take a back seat in the grand scheme of things.

With all of these changes coming around, I’m thinking that in the near future we programmers are going to have to start changing how we write our programs. We can no longer depend on gigahertz increases to drive the software faster. A point has been reached where the software needs to step up and be more efficient and utilize the new hardware more effectively.

Along those lines, I ran across this very cool article today: Functional Programming For The Rest of Us

Its a really good overview of functional programming and its many advantages (concurrency, etc.). With a lot of attention being placed on “functional” features in languages like Ruby, Haskell, Python, etc. this article is a good primer on what functional programming can do for you.