Now, I've no problem with literate programming, but given that even semi-literate practices like "write good comments" hasn't caught on in many places, I think Don is flogging a dead horse by suggesting that code should be entirely documentation driven. To be fair to Knuth, I don't think the failure to write good comments detracts from literate programming. What Knuth wants is an inversion of thr traditonal code/documentation relationship: you write the documentation and embed the code within that, as opposed to concentrating on code, and incidentally embedding documentation (as comments) within the code. Ultimately the failure of good comments and good documentation is because people are focussing on the code; as long as documentation and comments are an afterthought they will be forgotten or poorly written. If you switch things around and focus on the documentation and insert the code, comment-like, within that, then you're focussing on the documentation and it will be good.
The reason I think literate programming doesn't catch on has mostly to do with the fact that a great many programmers don't bother to think through what they want to do before they code it: they are doing precisely what Knuth mentions he does use unit testing for -- experimental feeling out of ideas. Because they don't start with a clear idea in their heads, of course they don't want to start by writing documentation: you can't document what you haven't thought through. This is the same reason why things like design by contract don't catch on: to write contracts it helps to have a clear idea of what your functions and classes are doing (so you can write your pre-conditions, post-conditions and invariants) before you start hammering out code. The "think first" school of programming is very out of favour (probably mostly because it actually involves thinking).
Ben's point is that discussion is not being permitted in academia, and in fact the opposite is happening, it is being suppressed. Yes, biologists who reject evolution are being suppressed and rejected by academia... In much the same way that astronomers who reject the heliocentric view of the solar system and geographers who suggest the earth is flat and geologists who still cling to the expanding earth theory over plate tectonics tend to find their careers going nowhere and their views getting suppressed. Honestly, if you actually come to the table with some real solid and credible evidence (but, given the weight of evidence aginst you, it's going to have to be damn good) rather hand-waving and vague "yeah, but what if" statements then academia will probably listen. In the meantime, you can expect a little ridcule.
You mean like the racist western conspiracy that instigated a war with a formerly allied country mainly because of that countries despicable actions in China? That's a rather interesting reading of history. Certainly there were actions by western countries that precipitated the war in the pacific; to suggest that was "mainly because of [Japan's] despicable actions in China" is perhaps stretching things a little much. Japan invaded and occupied Manchuria in 1931. The invasion of the Republic of China in earnest (the second Sino-Japanese war) began in 1937 after years of "incidents" and other minor battles. The Nanking massacre was in late 1937, spanning into early 1938. Japan went on to have clashes with the Soviet Union in 1939. It wasn't until the Japanese invasion of French-Indochina in 1940 that western powers started embargoes (the beginning of the actions that precipitated the war in the Pacific). Certainly Japan's actions in China were a factor in these considerations, but, given the significant time lag (2 to 3 years) between the atrocities in China and any action being taken (especially in light of the relatively swift action upon occupation of French-Indochina), it seems remarkably unlikely that it was even close to being "the main reason".
On Linux if you have palettes set to hint as "Utility windows" you will get exactly the Mac like behaviour (presuming your window manager understands such hints -- most do), and yes, hitting TAB will toggle visibility of the utility windows, just like photoshop.
I think the answer is that they aren't all that serious about multiplatform. There are Windows and Mac ports but they are very much secondary. The Windows port, especially, tends to be exactly that: a port of a Linux application, with little beyond enough to get it working in Windows. I'm sorry GIMP on Windows doesn't work for you; that doesn't make GIMP a bad application, just a poor Windows port.
Apparently 2.5 does exactly this: it instantiates an empty image window on startup and has the palette/toolbox windows set as "Utility Windows". That means that they don't appear on the taskbar and raise/lower along with the image window. Better yet you can hit TAB to have utility windows toggle their visibility, so if you want them out of the way just hit TAB and they'll vanish.
Of course the question then becomes: exactly how does pure quantum randomness qualify as my "will", let alone conscious will? How is an utterly random choice of "spin up" or "spin down" actually any better than a purely predetermined one? Quantum physics gets you out of determinism, but it doesn't get you to free will.
I'm mathematically inclined. Your argument starts falling apart at about the point where you suggest that the universe is a consistent formal system. Setting that aside for the moment, there's the "sufficiently complex" part -- the formal system has to be able to encode the natural numbers and natural number arithmetic. That's not as straightforward as you might think (there exists, for instance, a consistent and complete axiomization of the real numbers). Setting that aside for a moment there's the issue of how to interpret incompleteness anyway. A valid way is to simply say that there are different models that satisfy the axiom system; take Euclid's first four axioms (i.e. less the parallel postulate) -- that's incomplete in that there are different geometries that satisfy it. In this sense one could claim that, despite incompleteness we are simply inhabiting one particular model (and remember, that's ignoring the first two points).
On Linux what you want is to set Preferences->Window Management:Hint for Toolbox to "Utility". You may as well set it to that for "Hint for other Docks" as well. Now you will only have image windows appearing in the taskbar, and clicking on the image window will raise the toolbox and other docks with it. Moreover you can hit TAB to make the toolbox and other docks disappear and reappear as needed. You may ask "Why isn't this the default behaviour?!". A fine question -- it doesn't work so well when there is no image window up, such as when GIMP starts up. As noted in TFA, in GIMP 2.5 there is an empty image window on startup, and docks do have "Utility" hints by default... so it will shortly be the default behaviour.
The issue is that, what for you are "some interface quirks", for real world designers are completely craptacular design decisions. Well that really depends on what they are doesn't it? If you could actually explain what the problems are that might go a long way toward fixing them. It's also worth noting that, ultimately, GIMP isn't really targetting the professional design community. I mean, I'm sure the GIMP developers are aspiring to get there, but professionals are a relatively small group with very high powered and exacting needs*. On the other hand there are a lot of semi-professionals, quasi-professionals, and amateurs, who don't have anywhere near such high powered and exacting needs; for them GIMP may well be more than sufficient -- and ultimately that's currently GIMP's target market: the great swathes of people below hard core professionals who still have some need for powerful graphics and photo manipulation tools. As long as the interface quirks don't bother that market I don't see that they are yet that much of a problem.
* Let's be honest, if you're doing serioius photo-retouching in print work in a professional capacity it is GIMPs features, rather than it's UI, that are going to be your biggest hurdles: 16-bit colour and CMYK not the least of them.
In GIMP 2.4.5: File->Preferences->Window Management: Set "Hint for the toolbox/other docks" to "Utility Window". This also takes them out of the taskbar. And, it should be noted, is apparently the default in 2.5.0.
Thank you, you're one of the first people with some interesting complaints that aren't largely fixed in recent releases. Some of your complaints are a little odd to me though:
Let's start with File>Print... which opens the same dialog you'd see with Notepad. The ability to set up a printout are nearly null I'm not sure what to make of this. I have GIMP 2.4 here and the Gutenpring dialog, while clunky, is far from lacking in options, previews, and so on. If anything it is rather overstuffed with options.
There's no way to save a set of dialogs. You can save a window layout in the preferences, or revert to a default layout. Not sure if that's quite what you want.
The other points are largely reasonable. The toolbox layout changign can be quirky (though also makes sense in some way. Some manner of logical grouping might be a good start though. The translations -- I can't comment, but that's a problem with many packages, not just GIMP. The font and text tools do suck somewhat, but apparently that's a focus in the current version, so you should see that much improved soon. The brush editor; yes well, I'll happily admit that's a nasty quirk. I've never run into the eraser problems you describe, but they may well exist. While I've never done it, it sounds like GIF animation certainly sucks.
So thank you, these are actually a bunch of quirks and complaints that make good sense, and I agree should be fixed (though some of them are already being worked on). I still wouldn't go so far as to say the whole interface is batshit insane though -- it seems more like GIMP sucks at a few tasks (GIF related) and has a few annoying quirks; lots of applications have annoying UI quirks though. Can we go with "some specific areas that could definitely use significant improvment"?
Okay, some of these are valid, if exaggerated, but others are just a little odd.
The facts that gimp opens up ~200 windows to do the simpler tasks is already insane. Okay, that's a wild exaggeration, but yes, the many windows is a complaint that has some weight behind it. It is a problem that has been and is being worked on. In particular dockable palettes, and the recent (2.5) approach of defaulting to docking all the palettes in one utility window (hinted as such for the window manager), helps to alleviate this.
Add the lack of predefined shortcuts (you can customize them, but you will lost on everybody else computer, plus they are lost from time to time). I'm not sure what to make of this; a lot of shortcuts are pre-defined; particularly the all tools and most common operations. Mostly the operations lacking shortcuts are the various colour and filter operations, which are sufficiently numerous that keybindings would quickly get out of hand. Are there particular operations that you want keybindings for that are currently lacking them by default?
Mix it with modifier keys wich interfer with each other (i.e. if I press CTRL to subtract a rectangular selection, I will have to subtract a *square* selection instead). Well you could hold CTRL to start and get subtraction, then let it go to allow you to draw a rectangle. The last stable version fixed this by actually separating the options: if you hold CTRL before starting a selection you get a subtraction of the selection with rectangle selection. To get centered selection (what CTRL does -- use shift tio get a fixed ratio) you must press CTRL after you've started your selection. Add in the ability to modify selelction shapes (including modifying subtraction) provided in 2.4 and I think we can call this problem largely solved.
I can also recall the insane scripting language, even if it is not interface in the stricter sens. Script-fu is lisp based if I recall. Of course there are bindings for Python, Perl, Ruby, and probably a dozen other scripting languages. You can script GIMP in whatever you're comfortable with. I have to admit I don't see quite how this is a major problem.
The printing interface sucks This one I have to grant. I understand it is being worked on, but yes, currently the printing interface is on the clunky side. Of course you could save your image and print from something else with a simpler print interface, but that's a little clunky too. Better printing would be nice, but I'm not sure the slightly complicated interface for printing makes the whole software package "batshit insane" -- lots of programs have clunky printing interfaces that could be much improved (I'm looking at you Adobe Reader for Linux!).
i know the separate-screen gui drove me away for years. It's not so weird. As someone else pointed out, Photoshop for the Mac works the same way as GIMP, and UNIX and X11 historically have favoured multi-window interfaces to things -- in large part because virtual desktops were mat least as prevalent as taskbars in many early window managers. If you're on Windows then I can see how it may still annoy you -- although as TFA points out, while not going with a Windows style MDI they are smoothing things out a little (relegating the tool palettes to utility windows that window managers should handle differently, as well as having a default main image window at startup). If you are on Windows and are still bugged by it all then This plugin for GIMP is the way to go: it makes GIMP a Windows style MDI interface with a single background window.
Having not used it in 2 years, I'll try: That may be part of the problem -- as I said, they have been working on various issues...
The multiple windows thing This was slimmed down in 2.0 with dockable palettes so you could just have one tool window and then image windows. The docked windows also solve the issue of windows resizing (palettes don't when docked; they may, at worst, acquire scroll bars). This particular release sees the start of further UI overhauls the first of which is to provide a default main window with a single "tools window" which has the various palettes docked into it. Furthermore, the "tools window" is marked as a utility window, so windowing systems that understand such things will consider it as different (i.e. not a main window). This fixes (I presume, I haven't tried it) your window navigation keybinding issue.
I guess the long answer is: GIMP was initially designed for systems that didn't have taskbars, and did have multiple desktops; the result was the interface you seem familiar with, which, I agree, had serious shortcomings when ported to Windows. Over the years various efforts have been made to clean this up, and are still ongoing. Windows, of course, is still not the best platform, though there are plugins like Portable Background Window which provide a single background window which contains all the GIMP windows, providing an MDI style interface for Windows.
Unusual use of menus...To a new user, the app is useless because once you open something, you get a window with no menus. This was fixed in, I believe, 2.0 (or possibly 2.2). All image windows have menu bars with a menu that replicates the right click menu. This means users can simply use the menu at the top of the window as they might expect, or use the right click menu if they prefer. The latest version from TFA goes so far as to remove the menu from the tool window and provide a default empty image window (with menubar) upon start up. While the last problem is still potentially somewhat irksome depending on taste (though with plugins it can be "fixed") I think this one has been safely dealt with since the last time you used the GIMP... indeed, it was dealt with some time ago.
How about this menu: http://news.softpedia.com/images/extra/LINUX/large/gimp25preview-large_009.jpg ? Doesn't seem very sane to me. Given that that is a menu attached to an as yet very loosely integrated feature (GEGL) in a first development release... not such a great complaint. Sure, it's a terrible menu, but then it's clearly something that was slapped in to provide testers with access to GEGL's functionality. There's no way that's going to survive to 2.6 (the stable release).
...the very first item in the list of "noteworthy" improvements is a new splash screen.:'( It's a development release. The odd numbered releases (2.1, 2.3, 2.5) are all unstable development releases when new features are integrated in. Usually there are around 20 such development releases (i.e., we got to around 2.3.20 before 2.4 was finally released). In this case we have 2.5.0 -- the very first development release, with just the beginnings to structural changes to integrate new functionality. In this case that means enough behind the scenes work to get GEGL working, and the beginnings of an apparent UI overhaul. Expect another 20 or so releases each adding more improvements before you get the next stable release: 2.6.0.
You forgot "no interface elements that aren't batshit insane." I'm curious; can you tell me some interface elements that are batshit insane, and explain why they are insane? Don't get me wrong, I'm happy to admit that GIMP has some interface quirks and problems around and about. Personally, however, I've found most things to work reasonably well, and, more importantly, to be steadily improving (the dockable palettes that showed up in 2.0 or so, and the Image Window + Tools Window shown in TFA for 2.5, etc.). That leaves me honestly curious as to what leads one to the point of view that apparently all the interface elements are insane -- so please: can you explain some of the things that bug you so much about the interface?
Rights are properly configured on Linux by default. Your hypothetical kids in the library won't be able to touch anything system related, or anything not owned by the user. There is no configuration required to enforce this. Actually if you read the article it is better than that: they're using KDE because it has Kiosk mode, which basically offers a simple checkbox approach to completely locking systems down to be library machines etc. Scroll to the bottom to see the KDE Kiosk Tool, and skim through the options shown: you can very simply lock the box down to a significant degree. No run command, no shell access, no programs that require superuser access, etc. That doesn't give you much leverage to "hack" anything.
Here there is a chicken and egg scenario. The likes of Sage aren't going to port their product unless they've got serious numbers of customers lining up to say "We're putting Linux on the desktop. Port it or lose the contract.", and no customer can seriously make such a threat because right now, Sage can easily turn around and say "OK then. Let us know how you get on running a desktop platform which doesn't have any serious accounting packages." This has been the problem for any upstart OS ever since Microsoft cemented their monopoly over a decade ago. Indeed, most OSs, such as BeOS, were simply crushed under the weight oif the problem. Back in 2000 the problem for Linux was that there just wasn't any credible office software -- that complaint continued for quite some time, but has steadily evaporated as OpenOffice.org has improved. Prior to that I recall complaints about the lack of a really good browser (back when the only option was Netscape or a painfully bloated and beta Mozilla). Slowly but surely the complaints have moved further off into the niches; important niches, but niches none the less. As the need becomes more apparent Linux will, I expect, acquire some open source accounting software options. They won't be great, and they won't compete with the professional ones in any way shape or form, but they'll work well enough for some people to use them. They will also improve, and gather more users for whom they are "good enough". That will widen the userbase, and eventually some companies will think about porting to Linux, seeing as there is now a market. This is how it has always gone. There aren't going to be any crushing victories, or "Year of the Linux Desktop", but just the steady crawl as Linux* spreads a little bit wider year after year.
* Note that is isn't even Linux really: it's the FOSS software stack, and that could run just as well on OpenSolaris or *BSD if need be.
Whenever I'm offered an un-needed plastic bag, I say "No thanks, Save a Dinosaur" Oddly enough you can (help to) save a turtle by skipping the plastic bag. As bizarre as it sounds plastic bags are a surprisingly common cause of death in sea turtles -- the bags, when blown out to sea, look an awful lot like jellyfish, which the turtles eat. Needless to say they aren't quite as digestible as jellyfish.
The "Mini Ice Age" of 1400-1800 destroyed the Wine Industry in Britannia. For 1400 years Romans and their descendents had been growing vineyards and producing wine in the warm England climate. Then suddenly the earth grew cold, and the vines stopped growing. That's a somewhat dubious claim. There were vineyards in southern England around 1000 (based on Domesday records), however the reason for their demise is rather speculative. Certainly a cooling climate may have played a role, but there is also the fact that the English had a significant culutural shift toward beer as the preferred drink, and that may have had at least as much to do with the decline. This can be seen in the recent rise of the English wine industry, which has been driven far more by English drinking taste shifting toward domestic wine as it has been driven by climate.
Virtually every culture has a story of a great flood (Australian aborigines, Mayans, etc.) There are lots of stories of floods, but then floods are a natural disaster that many cultures would have experienced. So what are all the various flood myths? Conveniently someone has gone to the trouble of creating a fairly thorough compilation of flood myths. There certainly are a lot of them. If you actually read them, however, the thing that stands out is how remarkably different they all are: there really aren't any common threads except between stories that are clearly inter-related (usually from the same regions). It ranges from Noah's global flood, to floods that were threatened but never happened. Dates (when given) are all over the map, and there is absoluitely no reason to assume the stories refer to some common flood. Given the dramatic variation in stories it is far more reasonable to presume they are all quite different, stemming from different local floods (and, in the case of most of the pacific island stories, very clearly tsunamis).
How come the studios don't stop him from making movies? It's not like they're drowning in the money he's raking in with Bloodrayne. I have asked that question of people in the know some time ago, and as I recall it had something to do with German tax loopholes. This meant that the movie could turn a profit (for the right people, presumably it was a huge loss in many books) no matter how badly it did. Have a look at Boll's IMDb entry and note how many films he has in production or post-production right now. He's not slowing down, he's speeding up.
Having never seen a Uwe Boll movie, can someone tell me what's so bad about him? He's got some serious hate going on on the internet, and I'm just a bit curious as to why? He engenders the degree of hate (particularly on the internet) that he does for a couple of reasons. The first is that his movies are bad -- and I mean really, painfully, teeth-grindingly bad. Of course that alone doesn't generate that much hate; there are, after all, an endless supply of incredibly bad movies and abysmal movie makers in the world. The second point is that Uwe Boll has a great love of "adapting" computer games for the screen, and he is highly prolific at doing so. This manages to piss of geeks by raping their fond memories of games (Boll has a habit of going after older games, as far back as the 80s) by butchering what made the game good and simultaneously making something that, while attractive from the title, is painful to sit through. For those who have wised up and don't attend his films, there's still the niggling fact that, by producing so many video game based films that are so very bad, Boll has gone a long way toward discrediting both video games, and the idea of making films based on video games (in this latter point he is hardly alone of course). Since internet geeks and video game geeks have a nice large overlap, this makes internet based Boll hate something that gets noticed.
Slashdot Mirror
The reason I think literate programming doesn't catch on has mostly to do with the fact that a great many programmers don't bother to think through what they want to do before they code it: they are doing precisely what Knuth mentions he does use unit testing for -- experimental feeling out of ideas. Because they don't start with a clear idea in their heads, of course they don't want to start by writing documentation: you can't document what you haven't thought through. This is the same reason why things like design by contract don't catch on: to write contracts it helps to have a clear idea of what your functions and classes are doing (so you can write your pre-conditions, post-conditions and invariants) before you start hammering out code. The "think first" school of programming is very out of favour (probably mostly because it actually involves thinking).
On Linux if you have palettes set to hint as "Utility windows" you will get exactly the Mac like behaviour (presuming your window manager understands such hints -- most do), and yes, hitting TAB will toggle visibility of the utility windows, just like photoshop.
I think the answer is that they aren't all that serious about multiplatform. There are Windows and Mac ports but they are very much secondary. The Windows port, especially, tends to be exactly that: a port of a Linux application, with little beyond enough to get it working in Windows. I'm sorry GIMP on Windows doesn't work for you; that doesn't make GIMP a bad application, just a poor Windows port.
Apparently 2.5 does exactly this: it instantiates an empty image window on startup and has the palette/toolbox windows set as "Utility Windows". That means that they don't appear on the taskbar and raise/lower along with the image window. Better yet you can hit TAB to have utility windows toggle their visibility, so if you want them out of the way just hit TAB and they'll vanish.
Of course the question then becomes: exactly how does pure quantum randomness qualify as my "will", let alone conscious will? How is an utterly random choice of "spin up" or "spin down" actually any better than a purely predetermined one? Quantum physics gets you out of determinism, but it doesn't get you to free will.
I'm mathematically inclined. Your argument starts falling apart at about the point where you suggest that the universe is a consistent formal system. Setting that aside for the moment, there's the "sufficiently complex" part -- the formal system has to be able to encode the natural numbers and natural number arithmetic. That's not as straightforward as you might think (there exists, for instance, a consistent and complete axiomization of the real numbers). Setting that aside for a moment there's the issue of how to interpret incompleteness anyway. A valid way is to simply say that there are different models that satisfy the axiom system; take Euclid's first four axioms (i.e. less the parallel postulate) -- that's incomplete in that there are different geometries that satisfy it. In this sense one could claim that, despite incompleteness we are simply inhabiting one particular model (and remember, that's ignoring the first two points).
On Linux what you want is to set Preferences->Window Management:Hint for Toolbox to "Utility". You may as well set it to that for "Hint for other Docks" as well. Now you will only have image windows appearing in the taskbar, and clicking on the image window will raise the toolbox and other docks with it. Moreover you can hit TAB to make the toolbox and other docks disappear and reappear as needed. You may ask "Why isn't this the default behaviour?!". A fine question -- it doesn't work so well when there is no image window up, such as when GIMP starts up. As noted in TFA, in GIMP 2.5 there is an empty image window on startup, and docks do have "Utility" hints by default... so it will shortly be the default behaviour.
* Let's be honest, if you're doing serioius photo-retouching in print work in a professional capacity it is GIMPs features, rather than it's UI, that are going to be your biggest hurdles: 16-bit colour and CMYK not the least of them.
The other points are largely reasonable. The toolbox layout changign can be quirky (though also makes sense in some way. Some manner of logical grouping might be a good start though. The translations -- I can't comment, but that's a problem with many packages, not just GIMP. The font and text tools do suck somewhat, but apparently that's a focus in the current version, so you should see that much improved soon. The brush editor; yes well, I'll happily admit that's a nasty quirk. I've never run into the eraser problems you describe, but they may well exist. While I've never done it, it sounds like GIF animation certainly sucks.
So thank you, these are actually a bunch of quirks and complaints that make good sense, and I agree should be fixed (though some of them are already being worked on). I still wouldn't go so far as to say the whole interface is batshit insane though -- it seems more like GIMP sucks at a few tasks (GIF related) and has a few annoying quirks; lots of applications have annoying UI quirks though. Can we go with "some specific areas that could definitely use significant improvment"?
I guess the long answer is: GIMP was initially designed for systems that didn't have taskbars, and did have multiple desktops; the result was the interface you seem familiar with, which, I agree, had serious shortcomings when ported to Windows. Over the years various efforts have been made to clean this up, and are still ongoing. Windows, of course, is still not the best platform, though there are plugins like Portable Background Window which provide a single background window which contains all the GIMP windows, providing an MDI style interface for Windows. Unusual use of menus...To a new user, the app is useless because once you open something, you get a window with no menus. This was fixed in, I believe, 2.0 (or possibly 2.2). All image windows have menu bars with a menu that replicates the right click menu. This means users can simply use the menu at the top of the window as they might expect, or use the right click menu if they prefer. The latest version from TFA goes so far as to remove the menu from the tool window and provide a default empty image window (with menubar) upon start up. While the last problem is still potentially somewhat irksome depending on taste (though with plugins it can be "fixed") I think this one has been safely dealt with since the last time you used the GIMP... indeed, it was dealt with some time ago.
...the very first item in the list of "noteworthy" improvements is a new splash screen.* Note that is isn't even Linux really: it's the FOSS software stack, and that could run just as well on OpenSolaris or *BSD if need be.