Recent Features
| |||||||||||||
Sobotka: Why GIMP is inadequateSobotka: Why GIMP is inadequatePosted Jan 12, 2011 3:01 UTC (Wed) by bug1 (subscriber, #7097)In reply to: Sobotka: Why GIMP is inadequate by daniel Parent article: Sobotka: Why GIMP is inadequate
"Having been coding C continuously for 30 years in projects both big and small, I can say with some confidence that for any project over a thousand lines long, C sucks. A lot."
The Linux kernel (and the majority of Free software projects) are doing it all wrong ?
What sucks, is when experienced programmers think a language makes large projects complex. They should instead acknowledging the complexity of design.
(Log in to post comments)
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:47 UTC (Wed) by romanfi (guest, #72329) [Link]
bug1 wrote:
> The Linux kernel (and the majority of Free software projects)
Does the kernel have a GUI? Not really ... except ... xconfig is coded using C++, in Qt3 oder Qt4, depending on the kernel version.
The kernel code itself is full of object oriented designs, be it the kobjects, SCSI, ATA, DMA, MMU and almost all of the low level drivers as well, be it inheritance, virtual functions, inline functions, member functions, namespaces, etc. It all has to be programmed in C, Motif did and does something similar, resulting in code that's not readable that much.
One of Linus' arguments also was that many programmers just do not know how to code in C++. Then my question is, following this argumentation, why's the kernel not written using compiled BASIC? ;)
The argument C is good to piss of bad C++ programmers is only acceptable because Linus "invented" Linux, because there are at least as many good C++ programmers as there are C programmers.
Of course you can create bad designs using C++, but when I look at horrible macro constructs to circumvent C's shortcomings, the you'll have to admit, that the language itself is no reason to create or avoid horrible designs.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:32 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> The Linux kernel (and the majority of Free software projects) are doing it all wrong?
It may be debatable for low level projects like the kernel; there were probably no good alternatives around in 1991. But for an application like the Gimp, C is about as bad as it gets. Yes, they did it wrong.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:44 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
Well, back when Gimp started, there wasn't much choice either. They even started with motif... And it's not fixable, but I am convinced that it's a problem for interested newcomers to have to write in C within the constraints of the gobject system.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:04 UTC (Wed) by anselm (subscriber, #2796) [Link] The GIMP developers might have started by implementing a pixel-based image editing widget for Tk, which was very much available at the time. That would have saved them from having to come up with a complete graphics toolkit, freeing that many resources for the development of the actual image editor in the process, and might even have changed the GUI toolkit landscape considerably (since somebody else would have had to come up with Gtk). But then again NIH remains a potent incentive to reinvent the (square) wheel.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:20 UTC (Thu) by daniel (subscriber, #3181) [Link]
However much GTK sucks, Tk sucks more.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 21:43 UTC (Thu) by anselm (subscriber, #2796) [Link] Thank you for this well-reasoned contribution :^) Speaking as somebody who has done Tk development at a variety of levels, including Tk widgets in C, I'm personally convinced that Tk doesn't actually suck all that much. Certainly not enough to write a whole new toolkit instead – Tk did have its shortcomings but they aren't anything that the application of developer effort on the order of that wasted on Gtk wouldn't have been able to sort out (as, in fact, many of them have indeed been sorted out over the years). YMMV.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 18:35 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Thank you for this well-reasoned contribution"
Fair comment. Like many projects, Tk gets better with age. I have always basically hated every single interface I have ever used that is implemented in Tk (e.g., Gitk) but who knows, maybe it got better recently. I picked tkdesk as a representative example. Installed it, did a file open, and saw that much of what I'd expect to be present in a modern file dialog is actually there. And the mouse and keyboard interaction is basically OK and what you would expect. The icons less than pretty and lack text labels, a failing I have long associated with Tk. Theming is just the basic ugly Tk look. Then things started going south, Tk toolbar icons started painting themselves on top of my other windows. I closed the main tkdesk but the toolbar refused to go away. I right click on the topmost toolbar icon, which has no label, I just guess there could be some forward progress there and a menu pops up... *under* the toolbar. I go back to my browser to continue this report and the toolbar icons are now overlaid on top of my text entry window, and now right clicking on the toolbar has no apparent effect.
Basically, a bucket of bugs. This is exactly the sort of mess I have come to associate with a program that grew beyond the ability of the underlying framework to structure it. So I stand by my initial overly curt characterization of Tk. IMHO, the only practical cure is to migrate to a better structured language.
By the way, I'm still trying to figure out how to get rid of tkdesk and its phantom icons. Xkill didn't work. Time to kill -9.
Sobotka: Why GIMP is inadequate Posted Jan 19, 2011 21:37 UTC (Wed) by anselm (subscriber, #2796) [Link] I don't think I would want to judge a toolkit based on a single »representative« application. I've seen Tk applications that work really well, as well as applications using other toolkits – such as Gtk or Qt – that really suck. In general, this probably tells us more about application developers than toolkit developers. As far as Tkdesk is concerned, I just installed the Debian package and gave it a quick spin. The first thing that occurs to me is that the splash screen says »2004«. I wouldn't say that this is an application that is representative for Tk as of 2011, just like a 2004-vintage Qt application would not be representative for Qt as of 2011. (In 2004, Qt was still at version 3, and the fact that, e.g., the KDE project decided to rewrite basically their whole desktop environment for Qt 4 should give one pause. I don't recall having to rewrite lots of code, either at the Tcl or C level, for Tk version changes, not since Tcl/Tk 8.0 at least, which came out in 1997.) I didn't notice any of the adverse effects you describe but many of these sound suspiciously like window manager issues (rather than Tk issues). The icons are a matter of taste (I don't find them that hot either), but it does not seem entirely fair to compare them to the SVG-based icon sets that desktop environments like KDE, with a much larger number of artists behind them, have acquired in the meantime. Even within the Tcl/Tk community, Tkdesk is not a program with lots of mindshare, and to my knowledge there are no people who have seen fit to dedicate themselves to creating artwork especially for it. (If there was enough interest it would probably be possible to have Tkdesk use the same icon sets that, say, KDE uses.) Some of the things in Tk that people regularly find fault with, such as the fixed Motif look (which used to be the latest fashion when Tk was new) have been successfully addressed in the meantime – Tk now supports a fairly capable theming engine. Tk itself is quite well-engineered and well-documented, arguably more so than various competing products. Finally, your contention that tkdesk should »migrate to a better structured language« suggests that you seem to be confusing Tk (the X11 toolkit) with Tcl (the programming language). Tk was first developed for Tcl, but there are Tk bindings for various other programming languages that one can use if one isn't enthusiastic about Tcl. Tcl is admittedly not everyone's cup of tea – but then again, which single programming language is? In my own experience it is quite possible to write large, reasonably maintainable programs in Tcl. In fact, I personally, having tried both Tcl and C++, would much rather program in Tcl. YMMV.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 16:32 UTC (Wed) by daniel (subscriber, #3181) [Link]
"The Linux kernel (and the majority of Free software projects) are doing it all wrong?"
I find your claim that the majority of free software projects are written in C to be dubious. In the Graphics world for example, C++ projects vastly outnumber C projects, the latter relegated largely to low level libraries such as Mesa and Xlib.
Linux kernel is entirely written in C for exactly one reason: Linus wants it that way. It's Linus's ball and bat, I won't comment further. Oh, just one comment. C99 is also banned from Linus's kernel, nuff said.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 20:49 UTC (Wed) by bug1 (subscriber, #7097) [Link]
I had read that C is more popular than C++, but double checking, on freshmeat.net there are 5367 projects tagged C++, 9594 tagged C.
However, the point i was trying to make in my original post is that complexity doesnt come from language, it comes from design.
If you have a really good design for a project, it should be just as easy for a C programmer to implement that design in C, as it would be for a C++ programmer to implement it in C++.
Design can be really hard, for simple tasks a lot of programmers do it themselves without thinking about it, its only when projects get larger that it gets recognized as a separate problem.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 21:53 UTC (Wed) by HelloWorld (guest, #56129) [Link] However, the point i was trying to make in my original post is that complexity doesnt come from language, it comes from design. If you have a really good design for a project, it should be just as easy for a C programmer to implement that design in C, as it would be for a C++ programmer to implement it in C++. This is just nonsense. The whole point of a programming language is to give you the means to express things more easily. The converse of your argument is essentially that we shouldn't have bothered with programming languages in the first place, since, given the right design, we might as well implement it in assembly language. An object-oriented design with heavy use of inheritance, virtual function calls etc. will be much cleaner, terser and simpler in C++ than in C.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 16:11 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
Why not go all the way and recommend something like Python then? *Much* cleaner, terser and simpler than C++.
(Of course there's a cost -- larger memory usage, slower running speed. Just like C++ has costs that C doesn't have -- gotchas in the language design, longer compilation times, increased memory usage, slower application startup due to eager linking overhead for vtables, etc.)
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 17:27 UTC (Thu) by HelloWorld (guest, #56129) [Link]
It's all about tradeoffs. Python is slow and uses more memory. I also dislike dynamic typing, and it's easier to use a C library in a C++ program than in Python. If these aren't problems for you - great, use Python.
If instead you're looking for a programming language that offers both flexibility and suitability for systems programming (perhaps even in the embedded world), then C++ is in my opinion a reasonable option.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:31 UTC (Thu) by daniel (subscriber, #3181) [Link]
"The point i was trying to make in my original post is that complexity doesnt come from language, it comes from design."
If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree. The absence of essential organizational constructs in C is a breeding ground for complexity. Look at Xlib for example, you have to match up discriminated unions properly by hand, which involves keeping track of struct names, typedefs and union field names, all spelled differently and sometimes inconsistently. The resulting code is unnecessarily hard to write, harder to read (at least if "understanding" is a required part of reading) and full of accidents waiting to happen. I do not see how that can fail to translate into design complexity. You just can't cover up those flaws with a design, the underlying mechanism insists on showing through.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 22:31 UTC (Thu) by bug1 (subscriber, #7097) [Link]
"If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree."
Design _should_ be separate from its implementation, they are separate stages.
But if you are designing as you go then its likely to all turn to shit a few times anyway, the efficiency loss of the language probably isnt significant compared to lost time due to re-writing whole sections of code.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 17:54 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Design _should_ be separate from its implementation, they are separate stages."
That is the waterfall method. I do not find it as effective or efficient as the iteration method.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 17:52 UTC (Tue) by daniel (subscriber, #3181) [Link]
It is hard to get reliable data on language popularity. That said, a search for "int main" lang:c vs lang:c++ on code.google.com shows C and C++ nearly tied. I think it is safe to say that a few years ago C++ would not have been anywhere close. (Caveat: it is naive to assume that a lot of care and attention goes into ensuring accurate search stats in a search engine.)
As far as freshmeat goes, it would be nice to know the relative popularity of C vs C++ for active and new projects versus inactive and old projects.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 12:16 UTC (Thu) by error27 (subscriber, #8346) [Link] C99 is also banned from Linus's kernel, nuff said.Kernel style is one variable declaration per line. The declarations are separated from the code by a blank line. C99 allows people to mix code and variable declarations, but in the kernel it's considered horribly bad style. The kernel style is to use kernel-doc comments and so C99 comments are considered non-standard and thus wrong. On the other hand, the kernel has pretty much all been updated to use C99 style structure initialization and it uses __func__ instead of using the old GCC extensions. And the kernel often takes advantage of the latest features in GCC where possible. For example, v2.6.37 uses the new local label declarations. When you say that we've banned C99 code that makes it sound like we're retarded. There are tons of things that we hate but only because they are ugly and not because they are new.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:34 UTC (Thu) by daniel (subscriber, #3181) [Link]
"When you say that we've banned C99 code that makes it sound like we're retarded."
It does sound like that, doesn't it?
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 7:36 UTC (Fri) by bronson (subscriber, #4806) [Link]
Yep. So why don't you apologize? Your statement was clearly wrong.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 18:45 UTC (Tue) by daniel (subscriber, #3181) [Link]
"So why don't you apologize?"
I will when the ban on inline declarations and // comments ends.
Sobotka: Why GIMP is inadequate Posted Jan 19, 2011 16:56 UTC (Wed) by bronson (subscriber, #4806) [Link]
haha, fair enough.
|
|||||||||||||