On Thu, Sep 17, 2015 at 9:42 PM, Andrej Prsa <[email protected]> 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 >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
