22 Jan
2012
22 Jan
'12
6:02 p.m.
On Sun, 22 Jan 2012 11:31:20 -0500
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
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.
On 22 January 2012 08:17, E. Liddell
<ejlddll(a)googlemail.com> wrote:
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.
On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
A few milliseconds being executed often enough slows you down. Calvin Morrison <mutantturkey(a)gmail.com>
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.
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).
My real quarrel is this:
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.
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".