Divecomputer nickname handling..

[Tomaz Canabrava]

On Thu, Sep 17, 2015 at 9:42 PM, Andrej Prsa <aprsa09 at gmail.com> wrote:

> > Not because of disrespect of devels efforts, no.
>
> Good. :)
>
> > Python is not suited for a desktop application: it's too slow, uses
> > too much resources, the legibility of the code is worse than c++,  it
> > has no good library for reading dive computers, it's hard to package
> > it on osx Windows and Linux regarding libraries, bindings to another
> > languages are a pain to be made. You don't see c or c++ apps going to
> > python, but the opposite : once the python app stops scalling, it
> > must go to either c or c++.
>
> I would respectfully disagree on several of these points:


And that`s how good conversations starts :)


> the GUI is
> not appreciably slower than in C (granted, I only compared gtk and
> pygtk, and have no experience with qt), and any speed loss is
> certainly offset by convenience;


That`s true if you are comparing only the UI speed - but when you asked why
it was not in python I understood "the whole code", for only the interface
my point about speed is moot.


> the legibility ultimately depends on
> the programmer (and the programmer's affinity to document code) in both
> languages;


not really - and I say that having worked in a insanely large app both in
C++ and in Python, two different apps for two different companies that did
the same thing: earth simulations to find oil, both softwares had a LOC
count of around 5 Million lines. in Python I didn't know what types I
should send to a random class method, in C or C++ you dont need to document
that, in python people tend to forget to document that.

and C APIs can be wrapped more-or-less easily. Packaging
> might indeed be an issue for windows and osx, I don't know enough to
> comment because I am ignorantly exclusive to linux. I would never
> suggest C or C++ number crunching code to be ported to python, but I
> would advocate for porting the (G)UI into python.


there is a Qt for python bundle already made, it's PyQt, but there's a few
libraries that we use that do not have that part done so this would be yet
another hassle: port external libraries to python. also, the Subsurface
project already uses a few languages: json, xstl, c, c++ - C++ was choosed
for the interface because I'm the interface developer and I'm proeficient
with it ( it was C with GTK before it was ported to C++, and you just read
how much linus hates c++, why on earth he allowed me to port away from
C/GTK to C++/Qt you can watch a few videos on why this was made.



> Mixing C and python
> (not sure about C++, never tried it) is really not that much of a pain
> once you get used to it.


Since both languages ( c and c++ ) are fairly similar, the learning curve
is small.


> I am an astrophysicist by day and I can tell
> you that most of our field is rapidly migrating all of the UI stuff to
> python. Our own code (phoebe) runs C for number-crunching under the
> hood, but all UI is done in python, and we never regretted the move.
> Your mileage may vary, of course, I just figured I'd ask because, if
> subsurface UI was in python, I'd be much better positioned to
> contribute to the code -- for whatever that's worth.
>

If I may say a thing or two: GTK is a terrible UI library - currently tons
of applications are shifting away from it, I can say about: whireshark,
gcompris, lxde, subsurface, even Ubuntu And that's maybe why Python code in
GTK is better than C code in GTK - it unsuck it a bit.

If you know how to handle python, then C++ won't be that much of a pain, if
you really wanna try to help on subsurface you can :)

I surely can stop what I'm doing to help you get your first bits of Qt. And
maybe you would like to try to port your app from PyGTK to PyQT.

(
https://www.reddit.com/r/linux/comments/2dxik3/future_of_gnome_and_gtk_when_whole_world_is/
)

Cheers,
Tomaz Canabrava


> Cheers,
> Andrej
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150917/550069d5/attachment.html>