Love him or hate him, Joel's got another article out. Amongst the many interesting points:
Mitch Kapor, who founded Lotus and created 123, decided for his next application to go with something called wxWindows and wxPython for cross platform support.
We have started building desktop applications to manage some of our Web services in part because clients tend to be more impressed with desktop apps. When you're trying to obtain funding and win contracts, showing them your beautiful (*cough*) Web applications doesn't impress. Many companies with beautiful Web applications found themselves selling their office furniture in the end. Since we decided to go this route, one of our programmers investigated several possibilities. As we were not going to go the .NET route, VB was ruled out (VB6 is no longer supported). We narrowed the choices down to Java, Perl, Ruby, and Python.
Java was ruled out quickly as being slow, buggy, and had too many issues with not allowing the programmer the fine-grained control that is often desired for a desktop application. Perl, regrettably, forced extra complications on us for distribution and was more difficult to support (and we'll not talk about threading). Ruby simply wasn't far enough along, but that would have been awesome. Python, on the other hand, had impressive support, was easy to bundle and distribute and was relatively quick to develop in. In fact, the desktop apps -- which I have not had the chance to work on -- have been so fast and responsive that they could be mistaken for an app written in Visual C++. We've been very happy with it.
Now, when can we get this convenience with Perl?
--Nat
Always read the source code
Ovid on 2002-12-11T22:23:13
It seems that the author of AmphetaDesk is a wee bit bitter. Comments from Ampheta.pl
# Dedicated to all the companies who wait until a large user base becomes
# dependant on their freeware, then shafting said happy campers with
# mandatory payment for continued usage. I spit on your grave.
Something that is on my todo is to learn wxWindows, so I can write stuff that will work on Linux/OS X/Windows. I attempted to learn it once but found the lack of documentation frustrating. I don't really have much of a choice as I've had bad feedback from TK apps because they don't look very professional.
Getting back to Joel, I enjoy reading his articles but find him very negative sometimes. He's goes on about how hard programming is, how leaky abstrations are but doesn't offer a solution. Sometimes you have to accept things aren't perfect and live with them.
Re:perlapp
Ovid on 2002-12-11T23:25:44
I have to confess that I also disagree with him from time to time. For example, in his latest article, he writes the following:
Becoming proficient, really proficient, in just one programming world takes years. Sure, lots of bright teenagers learn Delphi one week and Python the next week and Perl the next week and think they are proficient.On the surface, I agree with that. I was certainly one of those cocksure "I can program anything" types and I faced my comeuppance once I started hanging out at Perlmonks and seeing real programmers in action. ("what's an adjacency list?", "what's this stuff about decoupling?"). However, he goes on to write (emphasis mine):
Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff.That's where I take exception with him. Any time someone uses or implies superlative terms like "all", "never", "only", etc, then there's probably a flaw in the logic (and it sometimes paradoxically makes the person using it sound like an expert).
Case in point: at my work, our Python programmer isn't terribly familiar with a Windows environment and he knew nothing about Python when he started working on his projects, but he picked up Python in a week. He's a good enough programmer that he knows how to design things well, how to refactor, and with a bit of prodding from me, he's even started testing. The payoff here is obvious. When he finds a problem that he's not familiar with, his overall programming background is strong enough that the problem is rarely a systemic one that turns everything into a ball of mud. Yes, it might take him a little longer to figure out what the problem is, but he's going to get it solved.
In short, I'd be happy to take someone who's inexperienced with a given set of technologies so long as they can demonstrate that they know how to build things well. Few problems are insurmountable when you have the right technologies and the right mindset.
Re:perlapp
koschei on 2002-12-12T01:38:11
This argument is also known as the "university education" argument.
The idea being that in university you pick up your theoretical knowledge, all the concepts and ideas, and have some practical applications of said knowledge (usually in some either ancient or obscure language).
With that knowledge, you can pick up any language.
You then have the joy of adjusting to management who give 'fun' specifications.
Others seem to think that theory is bunk and you become a good programmer merely by doing lots of programming (e.g. many teenagers and/or graphic design people who think HTML is a programming language and that PHP and/or JavaScript are all one needs to program anything; they're often the people who cut'n'paste rather than refactor). This has some merit (after many years of programming in ARM BASIC, I found I'd worked out OO from first principles), but damn if it doesn't take a long time and you're usually not as rounded or well-developed as someone who spent time specifically studying programming as a concept.
Re:Python
Ovid on 2002-12-14T19:54:41
I don't work on the Python side, so I could be mistaken, but I seem to recall that wxPython was the choice. The programmer who's handling that is generally pretty careful about researching things, but I don't know his reasoning for this choice.
