On Sun, 22 Jan 2012 11:31:20 -0500
Calvin Morrison <mutantturkey@...> wrote:

> On 22 January 2012 08:17, E. Liddell <ejlddll@...> wrote:
> 
> > On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
> > Darrell Anderson <humanreadable@...> wrote:
> >
> > >Calvin Morrison <mutantturkey@...> wrote:
> >
> > > > In other words, I see usefulness from tdebindings.
> > > >
> > > > Meh. I see it like this: it is unlikely that any new
> > > > developer with develop on the trinity platform with Python
> > > > etc at this stage. Python and other languages are slow
> > > > anyway. I see weaning off them as a good thing.
> >
> > Unless you're already good at C++, just about any other language is going
> > to be faster
> > to program in.  Programmer time is more valuable than machine time these
> > days for
> > the majority of applications--and for small- to medium-sized programs, no
> > one is going
> > to notice the difference in execution speed between one and three
> > milliseconds anyway.
> >
> 
> A few milliseconds being executed often enough slows you down.

Relevant only for those programs in which execution takes place
"often enough".  I did specify "small and medium-sized programs"
for a reason--for something as large as Trinity, C++ is a perfectly
reasonable choice of implementation language.
 
> > > Slow compared to what? I'm learning Python right now too. I have learned
> > that Python has a built-in
> > >quasi compiler, that creates something called byte code. I'm no expert in
> > that kind of jargon, but Python
> > >will run faster than a pure interpreted language like shell scripts. And
> > everything I have read thus far
> > >indicates Python is not slow like Java.
> >
> > Any interpreted language is going to be a bit slower than a compiled one
> > because the interpreter takes
> > time to start up (and bytecode is still interpreted, it's just interpreted
> > faster).
> >
> 
> Not to mention start up, but also the overhead. A simple python script can
> take 10Mb of memory very easily.

This is another thing which is going to vary in importance depending on
the individual user and their hardware . . . but language wars are about
as profitable as OS wars, really.

> My real quarrel is this:
> 
> > tdebindings is one of those packages most people avoid
> > building. As a team, if we want to provide a quality
> > product, we need to ensure tdebindings will build even when
> > we personally don't have a use. :)
> 
> HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY UNDERSTANDS IT. Tim even
> mentioned he won't mess with it because he doesn't use those languages. I
> think we have to be kidding ourselves if we are trying to provide a
> "quality product".

Seems to me that we need to start by finding the answers to these questions:

-Which languages are involved?  Looking at the source in GIT, I think I see 
 Java, Perl,  Python, C#, C, Ruby, XPart (whatever that is), and Javascript, 
 plus some other stuff (written mostly in Perl) that appears to be 
 autogeneration/framework code for C# and Java.  Does anyone see 
 anything that I may have missed or be misinterpreting?

-Which of these languages do we have potential maintainers for?

-Which of these bindings have actually been used for creating software?
 Frex, Amarok has a Ruby dependency--will we need this interface to
 maintain/further develop it?

-If there are bindings which have never been used, can we safely drop
 them?  My instinct is that most of them can probably be dumped if they
 were never used, but it would be nice to keep one set (probably Python)
 for those who want to code small interface modules for personal use
 without dipping into the morass of C++.

-The autogeneration code for Java/C# represents a special problem if
 we want to keep those modules.  My Perl is good enough for me to
 be able to tell that this code contains a morass of QT- and KDE-related 
 classnames that probably come from the shared libraries.  This needs
 attention from someone who knows Perl-XS *and* C++ *and* at
 least one of the target languages to update it to TQT/TDE--pure Perl 
 code I might volunteer to handle, but the interface code used by 
 Smoke is beyond my skills.
 
-If, after all that, we have modules that we want/need to keep, and no
 maintainers, where do we go about looking for them?  That is, where
 are the active communities for the relevant languages?  For Python I
 expect the community centers around python.org, and for Perl I would 
 probably try perlmonks, but I haven't been much involved with Java 
 since before the Oracle buy-out, and have no familiarity at all with
 the other languages.  Even if we decide that maintaining bindings for
 a given language is not important, it might be nice to give the relevant
 community a heads-up and see if anyone steps forward.