On Wed, October 24, 2007 7:09 pm, Gus Wirth wrote: > Lan Barnes wrote: >> On Wed, October 24, 2007 1:37 pm, Gus Wirth wrote: >>> Lan Barnes wrote: >>> [snip] >>>> MythTV (which is on my mind a lot these days) could probably have been >>>> done faster and with fewer segfault defects in Tcl/Tk. My hat's off to >>>> them for what they've done in C, but I can't help but think it would >>>> have >>>> been easier and more robust in a scripting language. >>> MythTV is written in C++ and uses the QT widget set. It needs to solve >>> several hard problems that are directly related to hardware >>> interaction. >>> One is getting the full OSD (On Screen Display) to work which QT >>> handles >>> nicely. Another is getting the player to work, although I think a >>> wrapper around mplayer or xine-lib could have worked just as well. Not >>> sure if there is a Tcl/Tk ability to do OSD. Other things include doing >>> the commercial marking which requires some fairly impressive data >>> analysis, doing the video capture off a device, and transcoding. >>> Although transcoding could also be handled by some external program >>> like >>> mencoder or transcode, mythtranscode has better abilities than these >>> programs for MPEG2 editing. >>> >>> The project has also been going on for quite a few years now and was >>> started by one developer whose tools of choice were C++ and QT. >>> >> >> Yup. That's all too often exactly how a tool set is chosen. > > Is there any better reason?
Yes. While programmer familiarity is an important factor, it can be a negative factor, too. Every language worth its salt was written with a philosophy, a problem set to solve, and a set of tools for that problem set. For example, I don't even know MUMPS, but I wouldn't even consider trying to write a medical records app w/o studying enough MUMPS to assess it. I sure as hell wouldn't reach for Tcl or the C's just because I'm familiar with them. C is a systems language, really structured assembler (and a beautiful creation). C++ is, well, C++. Once C was the only language WAS, and apps had to be written in it. But that is simply no longer the case. Another good example is perl. perl was designed to be the systems administrator's Swiss Army chainsaw, and it still excels at that (perl 5, I know nothing about 6). But when the perl mongers declared it was the Last Language Ever Needed and proceeded to prove that elaborate perl apps couldn't scale and defied maintenance (when developers of different perl styles contributed), did they do anybody a service? How 'bout Forth? I don't think anybody has found a better way to evolutionarily develop a one-off real-time close control system for a single piece of HW ... like an astronomical telescope. Does that mean we should do everything in Forth (IIRC there were once even word processors in Forth)? Ask La Quey. I submit without any sense of malice that C/C++ is usually not the optimal language choice for user applications in 2007. > >>> Are there drop in replacements for all those functions in Tcl/Tk? >> >> Tcl/Tk (I'll assume Python, too) excels at user interface. > > The only user interface Python has is the command line. Anything else is > an add-on. But it has lots of add-ons. The classic GUI is Tkinter (Tool > Kit Interface). Tkinter is pretty much deprecated because of its low > number of available widgets and non-native look. But because of good > separation between the the GUI widget set and the programming language, > you can get bindings to GTK (PyGTK), QT (PyQT), wxWidgets (wxPython) and > probably others I'm not aware of. > OK. I'll stop being nice to Python. NB: I said above "I assume." >> It has >> excellent facilities for exec'ing processes. It has integrated >> interfaces >> to just about every back end available (including Isaac's choice, >> mySQL). >> And it's fully extensible with facilities for tying in C/C++ routines as >> new Tcl commands. It's also cross platform FWIW. > > As does QT. > Then I'm guilty of showing ignorance of QT. I thought it was a graphics library, not a widget set. >> The low level data analysis not handled in external binaries like >> mythtrancode (easy to exec to that) could, indeed, be made Tcl commands >> giving the app programmers a flexible way of experimenting and advancing >> the program w/o needing to refactor or even recompile the C. > > Do you mean that the data crunching should be done by routines written > in Tcl, or that you write the routines in C/C++ as it is now and expose > them as Tcl commands? > Both. Usually Tcl programmers juat grab existing working C code, but if that isn't to be found, they often just rough it out in Tcl (unless it obviously NEEDS to be C or asm) and then, depending on the acceptibility of performance, replace parts with integrated C using the Tcl as pseudocode. >> As for the >> scheduling logic, if you want to try to convince me that that sort of >> programming challenge is easier in C than a scripting language, I will >> gratefully lie on the floor and have a good, loud, long laugh. > > I have never tried to argue for that. But maybe I should since you seem > to be in need of a good laugh. > Nah. A smile a day is quite enough. And you've been good about providing those. >> As for "the project has also been going on for quite a few years now," >> well, DUH! Isn't that what I'm saying? I'm betting if they had ditched >> QT >> and done the user interface in a scripting language with a good Tk, they >> could have cut at least one of those years off. They'd have been able to >> concentrate at the high end on the program flow, and at the low end on >> perfecting the C/C++ code that does the actual data capture and >> manipulation. But that's just my sense of it, and to repeat, I'm very >> appreciative of the job they've done with the tools they're familiar >> with. > > You are so wrong it hurts. The QT widget set is one of the few things > that I would consider to be well written C++ code from people who > actually "get" Object Orient Programming. The KDE project uses QT as > its foundation, not only for the graphical interface but its support > routines as well. QTDesigner is a wonderful GUI builder. Fire it up and > you will get a program builder that rivals anything you can do in > Tcl/Tk. QT has all the things you need to build applications like MythTV > and has a large number of widgets plus the documentation is > outstanding. It is also relatively easy to build new widgets if you need > something more than what already exists either by extending classes, > combining classes, or directly grabbing the Paint routine. If you don't > like C++ you can still get to the functionality of QT by using some of > its bindings like PyQT for Python, PerlQt for Perl, etc. > > I've been working with QT originally through Kylix (Borland Delphi for > Linux) and now Lazarus with FreePascal > <http://www.lazarus.freepascal.org> (an object oriented Pascal) and it > works great. In addition to QT I can also bind Lazarus to GTK, GTK2, > Carbon (on Macintosh), fpGUI (a GUI specialized for FreePascal), > Win32/Win64 and wince (Windows Compact Edition) which demonstrates that > your choice of GUI toolkit and programming language need not be tightly > coupled. > >>> You >>> are always welcome to fork the project :) >>> >> >> I think I'm on record as having the opinion that this kind of comment is >> gratuitous snarkiness. In fact, I'm toying with the idea of starting my >> own project to compete with an established C/C++ project that will IMHO >> never get done and be the wrong thing (and too brittle to fix) when it >> finally stops crashing on alternate keystrokes. But it isn't Myth, and >> frankly, because I'm not a developer, I shy at the challenge. > > Of course it is. Your problem is that you are in an abusive relationship > with your hardware and won't acknowledge where you are really getting > the segfaults from. > I don't recall dragging my HW problems into my innocent reflection that, IMO, C/C++ programmers far to often reach for their accustomed tools ignoring the greater productivity available in scripting languages. My HW has nothing to do with that. And while I will acknowledge that you have convinced me that I have a POS CB MB, I will point out that the myth-users mailing list is about 30% "help! crash", "freeze up", "broken front end?", "mysterious exits", and the like. It ain't just me. >> As for Myth, Isaac and Co have done a wonderful job with their tool set >> of >> choice, and I'm hardly arrogant enough to try to improve on that. But I >> feel quite free to cite it as an example of a project that missed an >> easier, more robust path to success. > > The hard parts of the project had nothing to do with the UI. In fact, > the UI parts are rather trivial BECAUSE of using QT (see the source > code. I have). The hard parts would all have to be done in > C/C++/Fortran/some-compiled-language anyway because processing video is > something that requires performance and Tcl code (nor Python, Perl, > scripting-language-dejour) isn't going to cut it. > > Gus Your defense seems very personal. I sure didn't mean my mild statement of personal opinion to anger anyone. Maybe we should put a spike in this discussion. I'd much rather have you on my side than fuming at me. When I get in this position with my wife, I have to do one of those "I was wrong, I was so wrong, I was the jerk" numbers to make it go away. Would that work with you, or is that just a wife thing? -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
