Wednesday, November 17, 2004

Wicket in Python

I have decided to write the Wicket editor in Python. There are a number of good reasons for this:

- We need to have a number of alternative languages available in Croquet. It would be a shame for people to get turned off of it just because they don't want to learn Smalltalk.
- This is a forcing function for us to get the Python compiler done so that I can begin work. Andreas thinks he can have it by Monday.
- I don't know Python. For some reason, I don't seem to have much problem switching languages, as they all are pretty much the same to me with slight differences in syntax. APL is a bit different, but since it was my first real language it seems quite natural to me. In fact, I really miss it's array/matrix handling.
- It would be nice to have a substantial application running in Croquet in another language as part of the demonstration of the systems capabilities.

The Wicket architecture is going to be really neat. It is the first application that will utilize the Replicant/Interactor/Task model and the new UI that we have come up with.

2 comments:

Anonymous said...

Wouldn't it make more sense to write Croquet components in Squeak first and then port them to another language as desired? Anyone wanting to work with Croquet already needs to learn Squeak as a prerequisite. Having the Wicket in Python isn't going to change that. Is a Python programmer really going to be able to use your Wicket code in Croquet without knowing Squeak, especially since Croquet doesn't have much documentation yet? Current Croquet developers will however have to learn Python if they don't know it and they want to use the Wicket code. I don't see the advantage in this approach.

Croqueteer said...

The documentation should be language neutral for the most part. One of the major barriers to people interested in using Croquet is that we use Smalltalk as the main language. I think Smalltalk is a great language, but many people are not interested in learning it. Many people already know Python, Javascript, etc. and would be far more willing to jump into systems that allow them to code in those languages.

Of course, the documentation is critical. Note also that we have already modified Croquet to utilize positional arguments (see the OpenGL interfaces), so we have been looking into these issues for a while.