[EVALUATION] - E01: The Java Failure - May Python Helps?

[Markus Wankus]

OH GOD!  I cannot believe Ilias has shown up here...

Google his name - he has been banned from Netbeans and Eclipse (and 
Hibernate, and others...) for good reason.  Can you imagine how much of 
a Troll you need to be to *actually* get "banned" from the newsgroups of 
open source projects such as those?

I realize your admirable intentions and the fact that you are simply 
trying to help (the beauty of this community), but I beg you all 
now...PLEASE...do not feed this troll.  Any responses to his posts will 
simply snowball into the biggest waste of time and energy this newsgroup 
has ever seen.    I'll let Google fill in the rest of the picture.  You 
can decide whether or not you want to respond to his posts.

Markus.

Jeremy Bowers wrote:

> On Thu, 03 Feb 2005 09:26:08 +0200, Ilias Lazaridis wrote:
> 
>>My question is essentially:
>>
>>How many of those constructs are already supported by python (and the 
>>surrounding open-source-projects):
>>
>>http://lazaridis.com/case/stack/index.html
> 
> 
> This post is hard to follow, but I'm going to assume this is the core
> question, as it is labelled as such.
> 
> The first thing that leaps to mind is that you need to play with Python
> for a bit to get a full analysis of it. Due to the nature of Python, some
> of the things you have in that list don't really apply. 
> 
> The most obvious example of this is "code generation": Assuming you mean
> what I think you mean, the sort of thing you have in the C++ or Java world
> where you click a couple of boxes, push "next" a few times, and have
> several hundred kilobytes of impenetrable source code pop out as your
> project's "framework", it doesn't generally apply. In Python, you can
> actually write frameworks that can be made to do useful things in a small
> handful of lines.
> 
> For a good example of that, I'd recommend the Twisted tutorial:
> http://twistedmatrix.com/documents/current/howto/tutorial/index . In
> Python, if a framework makes you write reams of boilerplate... it's
> probably because someone just came from Java and isn't thinking in Python
> yet. :-) Code generation in Python is generally a non-starter. (Few rare
> counterexamples, but it's nothing like the Necessary Crutch it is in the
> C++ world.) Generally, every line in that Twisted tutorial, even in the
> final program, is *doing something*, not satisfying the framework with
> necessary boilerplate.
> 
> As for the rest of your requirements, you have specified your "technology
> stack" in terms of *goals*, not capabilities, so for quite a lot of them,
> there is no answer except, "Yes, Python can do that, and generally easier
> than most anything else". For instance, "Use of metadata within the design
> (on text level [code file])" can mean a thousand things. For what it's
> worth, Python tends to make it so easy I do it all the time, but for any
> given way you mean it, I can't promise there exists a pre-rolled framework
> for you.
> 
> So I can only speak generally. Given your list, you may find that Python
> is weak in the "graphical programming" department; drop-and-drop GUI
> generation isn't as well-tuned as VB. (I, for one, consider that
> development methodology toxic and actively dangerous, but I can understand
> why you miss it.)
> 
> Skipping down to your evaluation sequence:
> 
> * Create a class: Well, I'll show you this one:
> 
> class Something: pass
> 
> There, a class.
> 
> * Simple GUI: You may wish to check out Boa Constructor, as the closest
> thing to the GUI generator you probably want. There are at least 3 major
> viable GUI toolkits for Python and several other minor (but still capable)
> ones.
> 
> * Embedded DBs: I don't know, Google for your embedded DB name + Python.
> Failing that, there are several ways to wrap your embedded DB such that a
> Python program can use it.
> 
> * Web GUI: There are more Python web frameworks than you can shake a stick
> at, and I don't mean "some guys hacked together templating system" either;
> there are a lot of very mature systems out there, expressing a lot of
> different philosophies. Given some of your other requirements, for a
> web-based application I'd recommend examining Zope.
> 
> * Deployment: I don't generally have enough problems with this to be worth
> thinking about. I don't know what the state of the remote debugging is on
> Python; Google "remote debugging Python".
> 
> * For your "complex updates", I see two distinct things there; half of the
> depend on the database, not Python. For the other half, it depends on if
> you mean "while the program is still running". If so, they are
> challenging. If not, they are trivial.
> 
> * I'd recommend adding "testability" to your stack, and refer you to the
> "unittest" module; others can suggest their preferred testing modules, but
> I tend to stick with that as the general framework is available in a lot
> of languages that I use. If by evolutive development you are including the
> ideas behind "agile software development" (hard to tell if you mean that,
> or a community open to change*)
> 
> Based on what I see here, I have two basic comments. First, yes, Python is
> probably as close as you are going to get in an existing system to what I
> think you are looking for. It isn't perfect, but you will also be able to
> reasonably extend it for your needs. Second, Python has a different
> philosophy; you recognize the need for a different philosophy and I
> extremely strongly suggest that you take the time with Python to sort out
> what you truly need from what you think you need due to still thinking
> with your old philosophy. (For example, given my aforementioned
> reasons why code generation isn't an issue in Python, I strongly suggest
> you embrace Python and give it a chance, rather than force 'code
> generation' on top of it.)
> 
> You've got some exciting learning to do, and some interesting philosophy
> shifts to absorb, but I think you'll find, as a lot of use have, that even
> if it isn't perfect it's a helluva lot better than Java!
> 
> *: Community open to change: One caveat, from what I've seen when other
> people talk about this. The Python community is open to change, but it is
> still a meritocracy, and you will still need to convince others your
> change is good. For example, getting something into the standard library
> is not something that everybody does routinely. But as it is open source,
> if you want to take responsibility for your changes, you can do as you
> like. I *think*, based on your reading, that you are focussing on the
> latter, in which case you are OK. But do not expect to be able to dump
> things off onto "the Python community". 
> 
> Also, not getting into the standard library isn't that big a deal anyhow;
> a lot of very powerful and popular frameworks and modules don't go in,
> often because they conflict with the needs of a Python release (slow rate
> of change, mature interface, general utility, need to prevent a Python
> download ballooning to 250 MB, etc.).