|
From: Kevin A. <al...@se...> - 2002-01-22 21:20:24
|
I modified version of my original post to the list, responses from readers and a follow-up are online at: http://altis.manilasites.com/2002/01/21 http://altis.manilasites.com/2002/01/22 Dan Shafer provided the following comments via email, so they are not part of the online responses. ka ps. Due to the story being picked up by both Scripting News http://www.scripting.com/ and Dr. Dobb's Python-URL! http://www.ddj.com/topics/pythonurl/ we're getting a reasonable amount of derivative traffic to the PythonCard site. --- Dan says: I think the most important and telling part of this message for _me_ is: > >The resourceEditor sample, which is one of the more complex PythonCard apps >I've done so far, is still only 1500 lines long; and a total hack job to >boot ;-). Obviously, that isn't a big beast like Word, Excel, or >Photoshop... but one person can't write those types of apps and that is >probably the sweet spot I'm aiming at (one person or a few people coding >efforts) and for the type of complexity one person might come up with, >Python ends up as the best choice. > One-person apps fall into two categories for me: 1. Apps (stacks) which consist 90% of component assembly and wiring (which may involve high-level scripting) and only 10% of scripting (where 99% of functionality can be pre-defined and packaged). 2. Components which consist largely of Python code written to the framework API creating the things the first kind of sole developer glues together. This, to me, says that a sole app developer _could_ build a _huge_ and very complex app, _provided_ he had access to the components needed. This has always, for me, been the unfulfilled promise of OOP becuase no OOP language has ever developed in an atmosphere where its inventors/developers were at all interested in inventive users. I fervently hope and strongly desire that PythonCard become that environment and tool. If it does, I may decide to homestead there for a very long time indeed. But first we gotta get wxPython working on a Mac! -- Dan Shafer, Author-Consultant > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Kevin > Altis > Sent: Sunday, January 20, 2002 1:35 PM > To: pythoncard-Users > Subject: [Pythoncard-users] FW: Python is just as good as C++ for real > apps > > > I recently exchanged the following emails with someone that posted on > wx-users asking about porting from Visual Basic (VB) to > wxWindows. Like many > people, especially people using C++, he is under the mistaken impression > that Python is not good for building real apps. For the most part, I think > that is simply wrong. My arguments in favor of Python are below. The > messages are in order of most recent at the top to oldest at the bottom. I > removed the original posters name, email and signature. > > I'm sure if I misspoke below, Neil or other C++ coders that use > Python will > correct me. They might even have points to add that I overlooked. I didn't > even get into all the downsides of programming in C++. > > ka > --- > > From: Kevin Altis > Subject: RE: VB -> wxWin > > It depends on what you mean by big apps. If you are worried about speed of > the menus, windows, widgets, event handling, etc. that is a non-issue. If > you are worried about having access to lower-level OS routines, that again > is generally a non-issue. Either there is a Python library that already > provides access or it is a relatively painless affair to wrap the needed > C/C++ so that it can be used directly by Python. Python has much better > built-in cross-platform support than C++, even with the wxWindows library. > You can even call Python from within C/C++ or inline C/C++ code in Python. > Python has threads. Python has profiling tools to isolate which section of > your code might need to be optimized or rewritten in C/C++. > > There are drawing samples for wxPython and I have put some drawing samples > into PythonCard as well. These are actually a bit slower than they need to > be because I did a double-buffered bitmap widget that should have some of > the operations moved into C, but it is surprisingly fast as is. > The speed is > mostly a matter of the video card used. My hopalong sample is > comparable in > speed to the version I did in Java. > > The only way to know for sure if your particular application would have > execution speed issues is of course to try it. However, the > assumption that > Python is somehow inferior to C++ for real apps is just plain wrong. Your > initial message prompted my reply because your original code was in VB and > you definitely aren't going to lose anything going from VB to > Python except > the simplicity of using COM components; you can use COM from > Python, it just > isn't as simple as from within VB. You should seriously consider > Python and > wxPython as a solution. > > ka > --- > > Subject: Re: VB -> wxWin > > Thank you, but I'd rather stay with C++. Although Python is a very > interesting programming language, it is more for scripting than > creating big > app's. > > --- > From: Kevin Altis > Subject: RE: VB -> wxWin > > If you would like to program in Python (and everyone should :) > you can check > out PythonCard > http://pythoncard.sourceforge.net/ > This isn't just a random plug. Many of the good things in VB are > influencing > the design of the framework, some naming conventions for event handler > readability, how the layout editor works, etc. If you need them, you can > build standalone EXEs using py2exe or Gordon McMillan's > installer. There are > screenshots of some of the samples (there are over 20 samples) that come > with each release: > http://pythoncard.sourceforge.net/samples.html > > PythonCard sits on top of wxPython so you can use the > wxPython/wxWindows API > code in a PythonCard app in addition to our wrappers which are designed to > simplify the "raw" wxWindows API. > > It won't help you with automatic code translation from VB to Python or > translating your VB forms into PythonCard resources (layouts). The > resourceEditor sample, while primitive, will help you quickly > recreate your > layouts. > > I would very much like to get feedback from a VB user such as yourself on > features you really need or would like to see added. > > The only problem I see based on your requirements is that there > isn't a firm > date on the wxPython Mac port other than Real Soon Now. > PythonCard/wxPython > runs fine on Linux/GTK. It is possible to run GTK under OS X. > > ka > --- > > Subject: VB -> wxWin > > Does anybody have experiences translating a Visual Basic program into a > wxWindows application? Maybe a tool which does that? > > I have got about 10 programs written in VB3 or VB6 which I have to make > running under Mac and Linux, all of them > - not using any databases > - not using any complicated ocx or dll (just vb runtime) > - relatively clean, uncommented vb code > - few Windows API calls (like BitBlt) > > I thought about writing a program/script which translates the > "Visual" into > "wxWindows" and the "Basic" code into "C++". I think this should > be possible > up to some small code parts which I would translate manually. > Is there already such a tool? Does anybody have experiences in doing such > things, maybe converting from other languages? > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |