On 22 January 2012 13:02, E. Liddell <ejlddll@...> wrote:
>
> 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?


I think XPart allows you to embed any X11 window using the xlib
embedding calls, with the Kparts API.

As for C#:
"Qt# was an attempt to create a set of classes that bind the C#
language to the Qt toolkit. The bindings appear abandoned based on the
Qt# home page."

It's clearly abandoned. Do any of our applications utilize it? I
always had a thing against .NET on Linux. it never felt right.

>
> -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?

Amarok uses Ruby for extra things, like the scripting. This is a good
thing as I see 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++.

I think this is the real question. Is anyone going to throw their
hands in the air and yell if we drop it? Keeping it in the archives is
fine if someone wanted to pick it up later. But aren't there bigger
fish to fry?

Calvin