In some countries (including the US, where Gimp development is, as far as I know, still centered) "gimp" is an extremely derrogatory term for a crippled person.
Needless to say, the name is something of a barrier to business uptake...
Adobe's interfaces tend to be pretty bad, actually, but they are an improvement on the GIMP's in some respects. I wonder if GimpShop really manages to incorporate the subtle things that give Photoshop an advantage, though...
Also, can we PLEASE get a name that doesn't contain the world "GIMP"? Pretty please? Pleeeease?
Izzard would be great, but I'd be too worried about RTD not being able to resist the temptation to take advantage of cross-dressing humor, which isn't really Doctor-Who-ish at all (okay, so Patrick Troughton did it once...).
There's a point near the end of the first episode of the new series where the Nestine Consciousness addresses the Doctor accusingly as "Time Lord!" -- it's quite noticable, as it's the only thing it says in English rather than random burbling.
Sounds like the Time Lords will be referenced somehow at least. IIRC in a magazine interview Eccleston also mentioned that the Doctor is so fond of the Tardis in part because it's the only thing left of his civilization.
Re:Flame fest part deux (Re:Anecdotal evidence:)
on
Return of the Mac
·
· Score: 1
LISP's conceptual roots are functional, but the language in general is not particularly pure. LISP proper (i.e. Common LISP) is a multi-paradigm language, and lists aren't the only fundamental data structure (it does have non-list-based arrays, for example).
LISP is more... well, you can do functional programming in it, but you can do OO or anything else you like equally well, and most LISP code has a fairly conventional (non-purely-functional) structure.
The biggest power of LISP is how easy it is to craft a domain-specific language out of it, and there aren't really any programming paradigms that haven't been done in it. All the neat "new" (non-syntactic) features you see in recent programming language were in LISP for decades.
Did you really struggle against old habits? Many programmers I know, who were brought up on BASIC, turned out to be the strongest zealots for other types of programming and weren't held back by some extra knowledge about gotos at all.
Yes, I did. The knowledge wasn't a problem, but the habits that came from using them extensively were obstacles to constructing useful abstractions. Note that I grew up with old-school BASIC. Mandatory line numbers, and GOSUB was the highest level of abstraction you could reach. None of this QBasic stuff.
It took me a long time before I could stop thinking about loops in terms of gotos, and be able to recognize things like e.g. the potential for parallelism/vectorization.
A formal CS education would have helped me (I got a degree in graphic design instead), but I think I would have been much better off learning about control constructs at first in their own right, and only later learning about how they could be implemented with goto, once I had learned to reason about them abstractly.
Coming at gotos from that direction, I might have been frustrated with their limitations, but I don't think I would have found them particularly hard to understand.
Regarding the paper, I'm not all that impressed. I agree with some things -- Dijkstra gets quoted a lot without real understanding, and everyone could stand exposure to systems programming, because they're going to run up against it at some point in their career whether they like it or not.
However, in my current programming job, I'm part of a team that ends up cleaning up other's failed projects a lot. Very often the deepest problems are due to inappropriate use of global or shared state (the next deepest tend to be due to poor error handling, and the use of long imperative-style blocks where code was cut-and-pasted instead of being refactored into common functions/objects -- the availability of gotos seem to exacerbate this last problem).
Frankly, I don't think the current crop of programmers is averse _enough_ to using global variables. The opposite extreme (overly avoiding global state) can be just as bad, but the resulting code is still significantly easier to reason about and clean up with a good refactoring tool.
Some global state is unavoidable (if nothing else the outside world is a global resource); the Platonic ideal (for non-systems-programming) is to have well-defined areas of code which are in contact with the "outside" world, where your IO, your external event sources, and your singletons go. Everything else need not have any global knowledge (e.g. the singleton you get via dependency injection just implements an interface you use; you needn't know it's a singleton).
I suppose Haskell's use of monads comes closest to this ideal, though I think they still haven't figured out all of the practical aspects yet.
Dijkstra purports to know better than this author what is clearer to this author!
I'd be more concerned with whether the author was clear to their audience. Dijkstra, as part of that audience, is more qualified than the author to speak on that point.
load image translate it 10 pixels in x and 10 pixels in y blur it save image
which is closer to English (hmmm...and Applescript come to think of it)....
Quite close to AppleScript, in fact. But AppleScript is not English, and similarity to natural English can create more problems for inexperienced users than it solves.
For example, is "translate it 10 pixels in x and 10 pixels in y" really an obvious wording to an English speaker, or would the user find it necessary to repeatedly look up the required grammar in a reference manual because it conflicts with natural English usage?
Adobe has not adopted JavaScript (in spite of existing AppleScript support) for their graphic design suite without reason.
Being a graphic designer by training, I certainly understand the psychological barriers to using a formal-looking notation, but I would submit that the big problem with "new_image=blur(translate(image,10,10))" is not the notation, but that it doesn't fit well with the designer's mental model. They don't see the intermediate states of the image as distinct objects, and for simple things shouldn't have to.
That's what really makes your English example different, and that has nothing to do with syntax.
Your API could even provide global functions that call the corresponding methods on the most recently referenced image (Ruby again):
load "image.png" translate 10, 10 blur save
Note that, unlike the proposed "EnglishScript", this doesn't preclude using the more explicit forms in cases where you need to work with multiple images.
A good interface should make the common things easy and the hard things possible; "natural language" approaches invariably accomplish neither.
So is that an axiom then? That what Dijkstra said 30 years ago is true. I certainly don't see any arguments building up to your conclusion.
That would have been unnecessary, given a better citation. Which portions of Dijkstra's original argument are no longer applicable?
I seem to remember Dijkstra saying that people educated with gotos were irreperably impaired and couldn't write good code and yet there is a generation of successful coders out there who grew up with BASIC and yet had no problem pushing the boundaries with more sophisticated programming styles as fashions changed.
That was a weaker argument. Yet, as part of that generation, I wouldn't say there was "no problem". For many years I had to struggle against habits learned during that time, in order to use more structured approaches effectively. I have also seen similar struggles in my contemporaries.
English specs only work at all because humans interpret them and negotiate their meaning over time.
If you try to replace that human-to-human component with software (as in TFA), you're doomed to failure.
Put another way, it's at least as hard a problem as Strong AI. Look how hard it is to even write a decent grammar checker for English, let alone extract unambiguous meaning from it!
Well, that's one promise I can't make. Hopefully they will at least fix the audio levels.
I just know the leaked copy didn't use the final opening theme because there are clips of the new arrangement of the opening theme in one of the videos on the BBC site.
Oh for heaven's sakes. It was a rough cut with unfinished editing, audio work, and SFX. They're not going to leak that deliberately, as it would (and did) reflect negatively on the show.
It's a credit to the production staff that even that was so well recieved.
Are we just supposed to trust that the search engine *actually* found media we can safely use?
Empthatically no! It's always going to require resonsibility on the part of the person doing the search and using the content.
This isn't something that can feasibly be enforced through technological means; it's not a technologically tractable problem, and any serious attempts would basically end up being crappy DRM that still didn't work.
The point of having the machine-readable descriptions and a search engine like this is that it can at least do the hard work of finding candidate works for you to evaluate.
Some people have very low sales resistance. They don't really want the spam (and opt to block it if possible), but once presented with it they have little willpower.
I hate to say it, but given the current software patent regime, that is the strongest guarantee ANY software project can give (Free or otherwise).
Let's say you're writing a piece of software. Can you guarantee that you aren't violating any patents?
Probably not -- you're almost assured that there are already patents in place, even for relatively trivial things; your safety from those depends wholly on either the patent-holder's ignorance or good graces.
Oh, and by the way, don't go looking for yourself to make sure there aren't any patents covering what you want to do. Once you've read a patent you're liable for triple damages if a court later determines that you violated it. That you think you're safe (per your interpretation of the patent) doesn't matter; before the law only patent lawyers are deemed legally competent to make those evaluations.
Yes, Virginia, things really are that bad.
In Mono's case at least Novell had patent lawyers look at the situation before proceding.
Such small black holes have lifetimes of far less than a second. If somehow you could get it in your hand before it decayed, you would get heavily irradiated by hawking radiation as the hole decayed.
So yes, you would eventually die. Admittedly, you'll eventually die anyway; it'd just come a lot sooner that way...
Well, to be fair it's very possible the director might have made different cinematographic choices if he'd had color to work with.
On the other hand, in cases where the director is DEAD... chances are he either doesn't care anymore or has bigger issues to worry about.
From a historical perspective I do think it's a shame if the original versions are lost or suppressed, but otherwise the result of colorization or anything else deserves to be judged on its own merits. Not whether it might offend dead people.
Seems to me it at least deserves an attempt at revial. I may email the developer tonight if I have time and see if he'd be interested in participating (in an advisory capacity at least).
I don't have time to do it all myself, but I can at least try to start the ball rolling...
IIRC, XFree86 politicking did indeed prevent server-side double buffering from being implemented properly. Hopefully X.org will resolve this if they've not already..
The files the ebuild grabs do not have to be grabbed from a central server (many are not), and if I want to add a package, I can. That's why Gentoo has an ebuild for NVidia drivers, VMWare, and JEdit. Whereas Debian has none of these. RPM based distros have similar problems. Ebuilds don't even have to break EULAs - you can program the ebuild to download the files from the owner's site, so there is no issue of distribution right infringement.
There's nothing stopping similar things from being done with Debian as well -- and sometimes they are; c.f. the existing Debian packages for the MS corefonts and Macromedia's Flash player plugin. It's just that Debian usually doesn't choose to do things that way.
Slashdot Mirror
In some countries (including the US, where Gimp development is, as far as I know, still centered) "gimp" is an extremely derrogatory term for a crippled person.
Needless to say, the name is something of a barrier to business uptake...
Hmm, good point.. internationalization is important. ^_-
Adobe's interfaces tend to be pretty bad, actually, but they are an improvement on the GIMP's in some respects. I wonder if GimpShop really manages to incorporate the subtle things that give Photoshop an advantage, though...
Also, can we PLEASE get a name that doesn't contain the world "GIMP"? Pretty please? Pleeeease?
Factoring in shipping costs, $50 mil won't buy very much rocks and dirt.
Izzard would be great, but I'd be too worried about RTD not being able to resist the temptation to take advantage of cross-dressing humor, which isn't really Doctor-Who-ish at all (okay, so Patrick Troughton did it once...).
There's a point near the end of the first episode of the new series where the Nestine Consciousness addresses the Doctor accusingly as "Time Lord!" -- it's quite noticable, as it's the only thing it says in English rather than random burbling.
Sounds like the Time Lords will be referenced somehow at least. IIRC in a magazine interview Eccleston also mentioned that the Doctor is so fond of the Tardis in part because it's the only thing left of his civilization.
LISP's conceptual roots are functional, but the language in general is not particularly pure. LISP proper (i.e. Common LISP) is a multi-paradigm language, and lists aren't the only fundamental data structure (it does have non-list-based arrays, for example).
... well, you can do functional programming in it, but you can do OO or anything else you like equally well, and most LISP code has a fairly conventional (non-purely-functional) structure.
LISP is more
The biggest power of LISP is how easy it is to craft a domain-specific language out of it, and there aren't really any programming paradigms that haven't been done in it. All the neat "new" (non-syntactic) features you see in recent programming language were in LISP for decades.
Yes, I did. The knowledge wasn't a problem, but the habits that came from using them extensively were obstacles to constructing useful abstractions. Note that I grew up with old-school BASIC. Mandatory line numbers, and GOSUB was the highest level of abstraction you could reach. None of this QBasic stuff.
It took me a long time before I could stop thinking about loops in terms of gotos, and be able to recognize things like e.g. the potential for parallelism/vectorization.
A formal CS education would have helped me (I got a degree in graphic design instead), but I think I would have been much better off learning about control constructs at first in their own right, and only later learning about how they could be implemented with goto, once I had learned to reason about them abstractly.
Coming at gotos from that direction, I might have been frustrated with their limitations, but I don't think I would have found them particularly hard to understand.
Regarding the paper, I'm not all that impressed. I agree with some things -- Dijkstra gets quoted a lot without real understanding, and everyone could stand exposure to systems programming, because they're going to run up against it at some point in their career whether they like it or not.
However, in my current programming job, I'm part of a team that ends up cleaning up other's failed projects a lot. Very often the deepest problems are due to inappropriate use of global or shared state (the next deepest tend to be due to poor error handling, and the use of long imperative-style blocks where code was cut-and-pasted instead of being refactored into common functions/objects -- the availability of gotos seem to exacerbate this last problem).
Frankly, I don't think the current crop of programmers is averse _enough_ to using global variables. The opposite extreme (overly avoiding global state) can be just as bad, but the resulting code is still significantly easier to reason about and clean up with a good refactoring tool.
Some global state is unavoidable (if nothing else the outside world is a global resource); the Platonic ideal (for non-systems-programming) is to have well-defined areas of code which are in contact with the "outside" world, where your IO, your external event sources, and your singletons go. Everything else need not have any global knowledge (e.g. the singleton you get via dependency injection just implements an interface you use; you needn't know it's a singleton).
I suppose Haskell's use of monads comes closest to this ideal, though I think they still haven't figured out all of the practical aspects yet.
I'd be more concerned with whether the author was clear to their audience. Dijkstra, as part of that audience, is more qualified than the author to speak on that point.
Quite close to AppleScript, in fact. But AppleScript is not English, and similarity to natural English can create more problems for inexperienced users than it solves.
For example, is "translate it 10 pixels in x and 10 pixels in y" really an obvious wording to an English speaker, or would the user find it necessary to repeatedly look up the required grammar in a reference manual because it conflicts with natural English usage?
Adobe has not adopted JavaScript (in spite of existing AppleScript support) for their graphic design suite without reason.
Being a graphic designer by training, I certainly understand the psychological barriers to using a formal-looking notation, but I would submit that the big problem with "new_image=blur(translate(image,10,10))" is not the notation, but that it doesn't fit well with the designer's mental model. They don't see the intermediate states of the image as distinct objects, and for simple things shouldn't have to.
That's what really makes your English example different, and that has nothing to do with syntax.
A fairer comparison might be (in JavaScript):
Or, if you wanted a language with less mandatory punctuation (which is admittedly distracting), Ruby:
Your API could even provide global functions that call the corresponding methods on the most recently referenced image (Ruby again):
Note that, unlike the proposed "EnglishScript", this doesn't preclude using the more explicit forms in cases where you need to work with multiple images.
A good interface should make the common things easy and the hard things possible; "natural language" approaches invariably accomplish neither.
That would have been unnecessary, given a better citation. Which portions of Dijkstra's original argument are no longer applicable?
That was a weaker argument. Yet, as part of that generation, I wouldn't say there was "no problem". For many years I had to struggle against habits learned during that time, in order to use more structured approaches effectively. I have also seen similar struggles in my contemporaries.
Sorry, English isn't precise enough, full stop.
English specs only work at all because humans interpret them and negotiate their meaning over time.
If you try to replace that human-to-human component with software (as in TFA), you're doomed to failure.
Put another way, it's at least as hard a problem as Strong AI. Look how hard it is to even write a decent grammar checker for English, let alone extract unambiguous meaning from it!
China doesn't have the one child law because of a gender imbalance; the one child law has resulted in a gender imbalance.
Well, that's one promise I can't make. Hopefully they will at least fix the audio levels.
I just know the leaked copy didn't use the final opening theme because there are clips of the new arrangement of the opening theme in one of the videos on the BBC site.
Haha. You have a point ... but seriously, watch the episode when it's released; you'll notice the difference.
One obvious one would be that IIRC the "leaked" copy didn't have the new version of the theme song.
Oh for heaven's sakes. It was a rough cut with unfinished editing, audio work, and SFX. They're not going to leak that deliberately, as it would (and did) reflect negatively on the show.
It's a credit to the production staff that even that was so well recieved.
Empthatically no! It's always going to require resonsibility on the part of the person doing the search and using the content.
This isn't something that can feasibly be enforced through technological means; it's not a technologically tractable problem, and any serious attempts would basically end up being crappy DRM that still didn't work.
The point of having the machine-readable descriptions and a search engine like this is that it can at least do the hard work of finding candidate works for you to evaluate.
Some people have very low sales resistance. They don't really want the spam (and opt to block it if possible), but once presented with it they have little willpower.
It's scary and sad and unfortunately true.
Wake up.
I hate to say it, but given the current software patent regime, that is the strongest guarantee ANY software project can give (Free or otherwise).
Let's say you're writing a piece of software. Can you guarantee that you aren't violating any patents?
Probably not -- you're almost assured that there are already patents in place, even for relatively trivial things; your safety from those depends wholly on either the patent-holder's ignorance or good graces.
Oh, and by the way, don't go looking for yourself to make sure there aren't any patents covering what you want to do. Once you've read a patent you're liable for triple damages if a court later determines that you violated it. That you think you're safe (per your interpretation of the patent) doesn't matter; before the law only patent lawyers are deemed legally competent to make those evaluations.
Yes, Virginia, things really are that bad.
In Mono's case at least Novell had patent lawyers look at the situation before proceding.
Such small black holes have lifetimes of far less than a second. If somehow you could get it in your hand before it decayed, you would get heavily irradiated by hawking radiation as the hole decayed.
So yes, you would eventually die. Admittedly, you'll eventually die anyway; it'd just come a lot sooner that way...
Well, to be fair it's very possible the director might have made different cinematographic choices if he'd had color to work with.
On the other hand, in cases where the director is DEAD... chances are he either doesn't care anymore or has bigger issues to worry about.
From a historical perspective I do think it's a shame if the original versions are lost or suppressed, but otherwise the result of colorization or anything else deserves to be judged on its own merits. Not whether it might offend dead people.
Seems to me it at least deserves an attempt at revial. I may email the developer tonight if I have time and see if he'd be interested in participating (in an advisory capacity at least).
I don't have time to do it all myself, but I can at least try to start the ball rolling...
IIRC, XFree86 politicking did indeed prevent server-side double buffering from being implemented properly. Hopefully X.org will resolve this if they've not already..
You know, what you're describing sounds rather feudal, with developers withdrawing to the protection of corporate Lords with IP "castles".
There's nothing stopping similar things from being done with Debian as well -- and sometimes they are; c.f. the existing Debian packages for the MS corefonts and Macromedia's Flash player plugin. It's just that Debian usually doesn't choose to do things that way.
Remember that because of the filter in front, at any given moment the grey will represent the R, G, or B level.
For example, when the filters are on red:
dim spectrum -> filter -> dim red
dim red -> photomultiplier -> bright white
bright white -> filter -> bright red
Similarly, for green:
dim spectrum -> filter -> dim green
dim green -> photomultiplier -> bright white
bright white -> filter -> bright green
Get the idea?