Stefan wrote:
> The reasons the Python rewrite started AFAIR:
>
> * get more people involved:
>
> didn't work, there are even less people working on Gump's code base
> than before.
But we have a lot more people 'sniffing around'. ;-) That said, likely this
is 'cos the daily/nightly Gump coverage has continued to climb (which is a
testiment to Gumpmeister work, not language).
I wonder if part of the problem is that Gump is pretty unique and extensions
are not obvious. Maybe we need to create a Gump TODO (wiki) page, where we
list the extensions we'd like to do. If we had a list of such extensions we
could measure the language/accessibilty of Gump to those goals. We could
track what folks are struggling with, if they are.
Likely I've been too available to fix problems (and not made room/left a gap
for others), but that is 'cos stubornness won't let me walk away when the
mess is mine. I didn't know Python, I didn't know Gump well enough, I was
overly optomistic in my abilities. I created a monolithic mess (that worked,
basically), but that was a barrier.
I don't think Python is the reason that no more folks are working on Gump
code.
> * get people involved from outside the Java community
>
> didn't work either.
Have we really tried yet? Have we solicited? Have we even picked a
languare/tool/codebase we wish to go after? If we wanted to compile C, via
Ant or whatever, let's do it. Heck, I'm starting to think a Python Gump (for
Gumping Python) would be a sweet idea. Basically, I think we've not given
this any focus.
Personally, I do feel that the language plays no part in how Gump can do
this, other than perhaps appealing to people's curiosities.
> * simplify things
>
> Not sure. For me finding the time to actually learn Python idioms to
> get beyond my very basic understanding (what you get by reading Mark's
> "Dive into Python") has proven to be almost impossible.
Python Gump may not be simpler than traditional, but reading archives (on
why to start Python Gump) I see one problem with traditional was that it was
too simple, and had weak error reporting/correction. Python Gump has
simplified the installation (far less tools, reasonably more
portable/consistent), and has far more debuggable output (no editing
monsterous bat|sh files to look for CLASSPATHs, better remote debugging of
builds). The internals might not be simpler, but usage is (IMHO).
I really wish I could go back in time and understand what was so hard about
Python. I swear I write Java-like middle-of-the-road style Python (beaner
methods, etc.). I just don't see that the language is hard to read. Heck,
when I look at this code I see Java, just with less syntax. Gosh, I wish I
could see what is causing folks grief here, I really do. Would people be
open enough to post issues here, and I'll work with them to get past them?
I'm no Pythonic Guru, but I would willingly help explain any of the
relatively simple Python in Gump code.
> I don't know whether it's a matter of the code-base or the language or
> my abilities - and as such would need to look into Adam's rework. I
> know that I managed to wrap my head around the Java side of
> "traditional Gump" in far less time than I've spent on reading the
> Gumpy code so far - and I still don't get Python Gump. I never tried
> to really understand all parts of "traditional"'s XSLT sheets, I never
> had to.
I know I need to take 'full credit' for this. Heck, Sam (Mr Gump/Mr Python)
came back and dabbled, and then walked away 'cos it was too complicated (and
one couldn't simple edit/run/tinker). Sam clearly had no Python barrier, the
problem was the codebase/design.
Heck, Nicola was happily hacking a Gump GUI in Python (with no prior Python
experience) and he's no longer able to follow what I did to the code. Sure,
the code at that point did little to nothing (but load metadata) and I've
had to add a lot to make it actually launch tools, etc. Unfortunately I went
overboard (and got too focused in Forrest presentation).
I honestly feel I can fix that, and make this code acessible. Again, I feel
it is the codebase not the language (for most folk).
> But before we try to start all over again. Who is actually willing to
> write code for Gump as opposed to just toss around ideas - and who
> really has the time to do so and isn't already overcomitted to too
> many things? If it turns out to be just Adam anyway, there is little
> to no reason to change anything.
I didn't come at ASF interested in one project, I run a lot of ASF software
and hate jar hell (read: early days of AXIS on C-L in my App Server, yuk!).
I hate jar hell (hence Depot Version, hence Depot) and I came to Gump with
that focus. Gump was a passion before it came (via Python) my primary focus.
It may seem daft that I make Gump my primary project, but I see it as the
best way I can help the most projects (I use a lot of them).
I don't think I can make 'a big difference' to projects individually, so I
continue to work on Gump. I admit a lot of it is stubornness, I refuse to
leave a mess, but it is also passion. I want Gump to grow and succeed. I
think there is 'untapped potential' w/ Gump, something that can really
(significantly) contribute to OSS/software development. I feel we are close
to being able to explore that potential (now the core is getting
stable/clean). I've found a niche for my contributions, in Gump, and I want
to see it through to the end...
> What I'm trying to say is that Python didn't help Gump but I'm not
> sure it did harm to it either. For most (if not all?) of us Gump is a
> very interesting project, but a second or third project next to our
> main project(s) and as such simply suffers from "if I only had
> time ..." syndroms.
Heck, rightly or wrongly, Python Gump contributed to take us TLP. :)
I know I've considered a Java Gump, and I know there have been a lot of
times I've bitched that Python isn't mature enough, but I do not think I've
allowed Python Gump the chance it deserved. I don't think we can blame
Python for the past 6 months, I don't think it has had it's chance.
I think that Python does bring a certain something that Java can't. I think
Python allows a separation from the languages it builds, and tools that it
uses, that is healthy to it's goals. I think that Python has the potential
for developer productivity (and fun/quick entensions) above and beyond Java.
I think that Python is (despite imperfections) a good tool for this task.
I don't want to see us throw away the period of effort that has gone into
Python Gump. I feel a re-write in Java would gain little or nothing from the
Python implementation ('cos folks don't know it) so we'd not even have
benefitted as a prototype. Basically, I can stand to see the effort thrown
away when it has finally reached a point where it could flourish.
I ask that folks give me 6 months (no more) to attempt to rectify the issues
with Python Gump & it's community interactions. If folks will give me that
time, and continue to be open minded to this approach, I'd greatly
appreciate that & work to document/open.
That said, I am but one person on this project, and not even a founder.
Again, I won't fight a re-write, if folks see it as the best course for the
project.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
