| |||||||||||||
GNOME platform librariesGNOME platform librariesPosted Jul 29, 2012 11:29 UTC (Sun) by anselm (subscriber, #2796)In reply to: GNOME platform libraries by rleigh Parent article: Otte: staring into the abyss
In the case of the canvas, the situation was that the "official" libgnomecanvas was not being actively developed, with there being another five or so separate canvas implementations, each slightly different. So the issue here was not lack of manpower, but wasted manpower. Speaking of wasted manpower, libgnomecanvas was inspired by the Tk canvas widget. It would have been perfectly possible to save loads and loads of manpower by improving Tk, which is not at all a bad inter-platform GUI toolkit, and which was around, quite usable, and (unlike Qt at the time) permissively licensed when the GIMP was starting out, rather than coming up with a new GUI toolkit from scratch. Whatever work it would have taken to fix the shortcomings of Tk is vastly overshadowed by the work it actually took to implement Gtk+, and fix its shortcomings, again and again and again. The main problem with the current DE landscape in Linux is the tendency to reimplement stuff from scratch instead of fixing or improving existing stuff that is mostly working. Of course it is more fun to reimplement stuff from scratch (especially if, like most programmers, you think you are a lot better at implementing stuff than whoever came up with the original), but in many cases it does indeed lead to a lot of wasted effort.
(Log in to post comments)
GNOME platform libraries Posted Jul 29, 2012 13:30 UTC (Sun) by Company (guest, #57006) [Link]
These arguments always sound like a bunch of people got together and said "Hey, it's way too easy and boring to use the awesome $EXISTING_THING, let's just do $NEW_THING, it's way more fun!" which is almost never the case in real life.
So you should be aware that what you're saying is likely completely wrong. Which makes me wonder why you're saying it. Are you just trying to make GTK developers look bad?
GNOME platform libraries Posted Jul 29, 2012 16:06 UTC (Sun) by raven667 (subscriber, #5198) [Link]
I'm going to have to disagree here. I'm a sysadmin by trade and work with developers extensively to maintain production. In my experience developers often prefer writing new code to figuring out how to use existing tools or how existing systems work. More experienced developers might try harder to reuse code but there is never a problem that can't be solved by more code.
Programmers are trained to write code, not read it. Posted Jul 29, 2012 23:32 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
Unfortunately, even formal training for programmers is primarily focused on writing code, not reading code. This makes many programs 'write only' in any language.
The percentage of programmers who can read other people's code (or even their own from many years ago) and understand it, figure out what it is intending to do, and fix it is rather small. As a result the tenancy of programmers when presented with a malfunctioning piece of software is to re-write it from scratch.
In the more extreme cases, you find people who write great code, but can't debug or optimize it. I've run into a surprising number of such programmers in the commercial world.
I was fortunate in my early classes there was far more emphasis on debugging and understanding other people's code. On one final exam, half of the grade of the final was a one-page printout (no comments) with the statement "this program doesn't work, figure out what it's supposed to do, what's wrong with it, and fix it and explain what it's doing"
As a programmer, I consider it a failure on my part if I can't fix a bug in an existing program and instead have to write a replacement
Programmers are trained to write code, not read it. Posted Jul 30, 2012 13:52 UTC (Mon) by Wol (guest, #4433) [Link]
:-)
One of my first assignments, as a junior programmer, was to take a stack of uncommented FORTRAN code, six inches high, and work out what on earth it was doing!
Like you, I tend to consider clear, well-commented code is rather important - if I can't go back and work out what something is doing, and fix it, then the original guy (maybe even me) didn't do their job properly.
Cheers,
Programmers are trained to write code, not read it. Posted Jul 30, 2012 14:40 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> I tend to consider clear, well-commented code is rather important - if I can't go back and work out what something is doing, and fix it, then the original guy (maybe even me) didn't do their job properly.
And the most important thing about the comments is that they need to tell you WHY the code is doing something, not WHAT it's doing (unless you are doing something _really_ tricky, usually as a performance optimization). The what question is usually best answered by reading the code.
Programmers are trained to write code, not read it. Posted Jul 30, 2012 22:00 UTC (Mon) by kleptog (subscriber, #1183) [Link]
I actually got into a discussion at my work with fellow programmers who were trying to convince me that comments we unnecessary, because you could always just read the code. Good variable naming solved everything.
It's a silly argument. Yes, much code doesn't need comments if done properly. But there's always a function where when you open it up it's all clear except for a few lines which you look at and think "why is it done like that, surely that could be done simpler". Turns out the simpler version breaks some corner case which isn't obvious. My motto is that if there's a line of code that looks out of place and it takes you more than 5 seconds to work out why, then it's a candidate for a comment.
A nice side effect if you follow this religiously is that lines of code that look weird and have no comment are almost certainly bugs.
(My beginner experience in code reading was figuring out how Zork (the game) encoded its strings, by reading a printed(!) disassembly of the DOS binary.)
Programmers are trained to write code, not read it. Posted Jul 30, 2012 23:37 UTC (Mon) by neilbrown (subscriber, #359) [Link]
I like to be welcomed when I go somewhere new, and that includes when I visit someone's code. Often all I get is a license statement (which is certainly useful) and then straight into the code.
Sometimes the function names and class names etc are welcoming enough, but often the import of the name doesn't become apparent until I understand the general structure of the code.
So a welcoming comment at the top which outlines what this file of code does and where it fits into the big picture is ... well ... welcoming!
Programmers are trained to write code, not read it. Posted Jul 31, 2012 7:02 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> My motto is that if there's a line of code that looks out of place and it takes you more than 5 seconds to work out why, then it's a candidate for a comment.
That sounds like a very good rule to go by. I'm stealing it :-)
> My beginner experience in code reading was figuring out how Zork (the game) encoded its strings, by reading a printed(!) disassembly of the DOS binary
how many of us got our start by wanting to 'modify' some game? (this is a good reason for games to have local or single-user modes so that people can 'cheat' without hurting others who don't want to)
Programmers are trained to write code, not read it. Posted Jul 31, 2012 22:59 UTC (Tue) by nix (subscriber, #2304) [Link]
Quite. I tend to use both approaches: stealing an idea from literate programming, the comments should not only tell you why obscure cases were there but also almost take the place of a walkthrough. After all, when you *write* the code you are not relying on pure C: you have the benefit of your own train of thought. A reader of the code (or you in six months) does not have that. So it is best to describe what the code is doing, as well as why, as a train-of-thought substitute.
I've tried coding the l-k way, with just 'why' comments and nothing else, and invariably I find I come back to the code in a few months and it's a real struggle to figure out what the hell it's doing, because of the lack of any sort of narrative comments: I'm left reverse-engineering my own work or trying to recall six-months-gone trains of thought, and neither seem like a good use of time. The GNU Project's toolchain software is my personal idea of the sort of comment density that makes sense: frequent expansive block comments (not little 'do this' scribbles) and if a page doesn't have a comment on it you're probably doing something wrong. LLVM is well-commented, too.
Probably as a consequence of this, I find many parts of the core kernel's small-scale structure comprehensible only with noticeable effort, despite having written C for nearly twenty years now and fairly frequently dreaming in it. The small-scale structure of GCC is relatively easy to grasp by comparison, despite its much greater complexity, because it's so much better commented (its large-scale interactions are something else entirely). I suspect the l-k comment policies could only survive for a system like a kernel where most of the thing is relatively pedestrian and the complex stuff, like mm, is limited enough in scope that a few people can devote most of their time to it and never get rusty. Something where the *whole thing* is complex, like a modern compiler, can probably not survive with such harsh anti-comment policies.
(For reference: drivers/md/md.c has about a third to a fifth of the density of comments I would consider acceptable for my own work. raid5.c is much better, though I note that the heavily-commented bits seem to be the buggy bits, and investigation of the git history suggests that these comments mostly got added as bugs appeared. Personally I prefer to write the comments *before* their absence causes misapprehension-induced bugs, but that's just me. ;) )
Now perhaps I just have a particularly crap memory, and nobody else needs this sort of comment density, but I suspect the real cause is that most people just don't like writing comments, whether they are a good thing or not, any more than they like writing documentation. I suspect also that hackers for whom English is not their first language might *actually* find the C easier than comments in a language not their own: it's hard for me to judge this as an English monoglot. Maybe we need multilingual autotranslated comments!
Programmers are trained to write code, not read it. Posted Jul 31, 2012 23:06 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
The biggest problem I have with 'what' comments is that they don't always match what the code actually does (due to bugs in the code or the comments, or simply due to the code being changed by someone who didn't change the comments).
When they don't, and people rely on the comments rather than the code, it's worse than having no comments.
Programmers are trained to write code, not read it. Posted Aug 1, 2012 9:15 UTC (Wed) by mpr22 (subscriber, #60784) [Link] "If the code and the comments disagree, both are wrong."
Programmers are trained to write code, not read it. Posted Aug 1, 2012 14:14 UTC (Wed) by nix (subscriber, #2304) [Link]
Quite. Probably the code was changed by someone who didn't bother to look at or change the comment right above it, in which case that person was sufficiently sloppy that you can't trust the code change either.
GNOME platform libraries Posted Jul 30, 2012 17:42 UTC (Mon) by rleigh (subscriber, #14622) [Link]
I think that in the case of GTK+ being a separate toolkit, there was a legitimate reason to implement a "native" canvas, or at the very least have a native API to a canvas. It also allowed embedding widgets on the canvas, so needed to be native to some degree.
I don't think that there was ever a good reason to fork six or more implementations from the original libgnomecanvas. It resulted in a plethora of buggy and incomplete libraries, none of which were ever supported or completed properly, including the "official" one. This is the major technical failing of GNOME: a failure to provide sane set of usable and stable APIs and tools.
Regards,
GNOME platform libraries Posted Jul 30, 2012 19:56 UTC (Mon) by anselm (subscriber, #2796) [Link] I think that in the case of GTK+ being a separate toolkit, there was a legitimate reason to implement a "native" canvas, or at the very least have a native API to a canvas. It also allowed embedding widgets on the canvas, so needed to be native to some degree. Instead of starting GTK+ in the first place, it would have been perfectly feasible to write The GIMP based on Tk, possibly by implementing an »editable bitmapped graphics« widget or by augmenting the existing (object-based) canvas widget to include editable bitmap layers. The Tk canvas could already embed other widgets, so one would have been able to get that functionality (along with the rest of the toolkit) for free. That approach would also have had the side benefit of making the »bitmapped graphics« extensions available to other Tk-based programs.
|
|||||||||||||