When you control-click or right-click on any running application's Dock icon, you get a pop-up list of all of that application's windows. The foreground window has a check mark next to it's name.
Cut and paste does not work consistently across applications on any Linux desktop. It's no use saying that it *could* if only application developers would implement it for their apps. They haven't, and the result is an abortion compared even to the indifferent support seen across Windows apps. Of course the complete consistency of cut, copy, paste, copy/paste style in Mac OS is in the realm of distant fantasy for x86 desktop users on both sides of the Linux/windows fence. Maybe if every Linux app were rewritten for a particular desktop (say KDE), but that aint gonna happen any time soon.
Which won't help you if the top window with the instructions is opaque and covers the one you're typing into.
The whole point of translucency is to be able to see the contents of both stacked windows at the same time. This has nothing to do with focus-follows-mouse, and everything to do with seeing two stacked windows' contents at the same time.
This is essentially what Apple is doing with Mac OS X's window manager - using hardware accelerated OpenGL to draw all the translucent window contents as alpha blended texture maps. This requires a video card that can do non-square rectangular texture maps, so only newer machines benefit from this acceleration, which Apple calls Quartz Extreme.
Apple's version of Xfree for MacOS X does OpenGL hardware acceleration, but it doesn't do translucency (presumably, at least in part, to keep Xfree a good step and a half behind the native OS X window manager).
I too am surprised it's taken this long for someone to do it for Xfree on Linux.
Re:And now for something completely different...
on
Python in a Nutshell
·
· Score: 1
That's: "Two peanuts were walking down the Strasse. One was assaulted... peanut."
I suppose it hasn't occurred to either of you that the authors of the Gospels were fully aware of the Old Testament prophesies, and crafted their versions of the events to fit the pre-existing prophetic verses.
Fortunately for the rest of us, precisely this notion has occurred to bible scholars, and it's commonly understood among historians that in antiquity, books were quite commonly written in such a way as to appeal to older, pre-existing literary authorities.
"And what's up with putting us in a universe where we can harm each other? What "good" god would ever do such a thing. Such a god is not "good" in any meaningful sense of the word."
Now you're catching on. Any useful definition of god would have to include the fact that god creates both good, and evil.
BTW, I'm not religious, and I certainly don't live by the Bible, but this little known feature of the almighty is stated explicity in that book:
Isaiah 45:7 (King James Version):
I form the light, and create darkness: I make peace, and create evil: I the LORD do all these things.
Note that "create evil," is in the present tense, meaning that god is continually making bad stuff happen right now! Even if one argues that the word translated as "evil" should be translated more mildly as "bad," or "rotteness," it still isn't the doing of a god who is all good.
"I've been thinking that maybe time does not existat[sic] all. That it's just an illusion caused by our memories of the past and our predictions about the future. All we really have access to is our mental state at a given instant."
This is the zen buddhist view, that reality is just a single present moment, which unfolds, or changes. We have taken this to mean, merely by convention, that there exists some abstract linear thing called time.
If you set this verbal and conceptual convention aside, you'll see that the past cannot possibly exist. It is just an abstraction from our present memories (which are quite imperfect) and observational evidence gleaned from present experience.
This does not mean that there is no causality, but rather, the buddhist interpretation is that causality is more holistic, that everything that is, is interdependent, and that it all changes continuously, in the present, in an intricately interdependent way. Teasing apart this complete interdependence into the kind of linear causality beloved of science is then seen to be impossible.
As to beginnings, we may have to accept, at least for the present, that there are limits both to our powers of observation (light cones, world lines, and all that), and our powers of conceptualization.
"And in the town I work in (and I think in most of the state) ALL mail, every single frikkin piece of it, goes to one town in the state, then gets sent back out. EVEN IF ITS LOCAL!"
You do realize that this is exactly the same transport model used by Fedex? And that their founder was laughed at for it, just as you mock the USPS for it, until he proved that it not only worked, but is more efficient than having a multitude of shipping routes locally and nationally, because it centralizes sorting.
You're joking right? I knew a guy in college who worked in a Toronto post office in high school. Every day, they would pick a package or two from one of the bins, nail it to the wall. and use it as a dart board.
Then there are those periodic Canada Post strikes when no mail moves at all.
The USPS has an incredible record for delivering thousands of tons of mail daily, over a huge territory, to hundreds of millions of people, reliably, and cheaply.
Your parent post was a joke - see the smiley? It was *sarcasm*.
Re:I thought so.
on
Genome Surprise
·
· Score: 2, Interesting
The reason that there is no genetic basis for the naive (and racist) concepts of race is that all the racisits conveniently omit that large portion of humanity whose superficial charateristics fall between the racial stereotypes.
What are north africans? Are they black? "Yes," says the Norwegian racist, "because they don't have pink skin and blue eyes." "No," says the Kenyan racist, "because they have straight hair, and their skin is too light."
And so on, and on, for central asians (are they Caucasian, or Mongoloid?), and Dravidians (are they "black" or caucasian), etc. etc.
There's no genetic basis for races, because there's no real definition of what constitutes one race or the other. The only thing people ever define are the extremes (practically albino white, with straight blonde hair and blue eyes v. the darkest possible skin tone with very kinky hair) but no one can agree on where to classify the vast number of people who fall in between these extremes, and who occupy a substantial portion of the land area of our planet.
"Who knows if five (or fifty) years from now a coprocessor is designed that makes string functionality as easy to implement as arithmetic."
You've read Graham's argument completely backwards, and are, in fact, arguing his point here. Graham is saying that, with computational power increasing, we no longer need to segregate our treatment of strings from sequences of other types, and so, can deal with all sequences in a unified way, relying on the compiler and hardware to optimize the treatment of each sequence sub-type.
Now multiply this abstraction and simplification by all the disparate data types in a typical program and see how much easier it would be to program with a data type optimizing compiler doing all the book keeping for you.
Lisp is alive and well (franz.com, lispworks.com, digitool.com, alu.org, cons.org, etc.)
" Java's ideas (especially the virtual machine) will survive and take over."
The virtual machine is not a Java idea. Neither is Java's broken object system. Hint: Java cribbed Smalltalk's real object system and got it wrong. Guess which OO language from the 70s ran, and still runs, on cross platform virtual machines?
The reason Java is an evolutionary dead end is not that these are not good things (Yes, a VM and garbage collection are good things). The reason is that Java didn't invent them, and has implemented OO in a broken fashion, so it is a step backwards, not a step forward. There will be no descendants of Java in a century, because future languages will be descendants of Smalltalk, or Lisp, or ML, or Erlang, i.e., descendants of languages that got the basics right, not broken.
You can write Matlab in Lisp. You can't write Lisp in Matlab.
See the difference? Graham is talking about a flexible language that can be used to write the domain specific languages (like Matlab).
Languages that are very powerful, each in its own domain, are all much less generally useful than a small, flexible language that programmers can build domain specific languages on top of. This is the power of turing complete macros. It's this flexibility that makes such a language likely to last 100 years.
"Projects like Squeak are looking more and more like Java these days, in terms of re-usability and VM-based platform independence."
Wow, do you know anything about the history of programming languages?
Java's OO is based on Smalltalk, quite intentionally, not the other way around.
Smalltalk ran on cross platform virtual machines long before Sun decided to foist it's failure of a set-top box language (i.e., Java) on the internet in the mid '90s.
Squeak is a deliberate attempt to recreate the original Smalltalk from ca. 1970.
So, yes, Java is an evolutionary dead end because it badly implements only some of the features that Smalltalk had 30 years ago, and contributes nothing new, unless, of course, you consider the exalted levels of marketing hype.
Because Paul Graham was one of the founders of the company that made the online store creation software that was purchased by Yahoo, and now forms the basis of Yahoo Store.
Unless I missed my guess, paulgraham.com is hosted on yahoo store. To wit:
whois paulgraham.com
[snip] Domain Name: PAULGRAHAM.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS5.STORE.YAHOO.COM
Name Server: ST-NS1.YAHOO.COM
Status: ACTIVE
Updated Date: 05-nov-2001
Creation Date: 29-oct-1998
Expiration Date: 28-oct-2004 [snip]
"Graham says we should get rid of strings and use lists to represent them. But people naturally THINK in terms of character strings all the time, so it helps developers to support strings in a language."
No, programmers only "think" in terms of character strings because they've only ever worked with languages that enforced this distinction. Same way many programmers "think" that variables have a type because they've only ever worked with statically typed languages.
People who haven't been mind f*cked by restrictive programming languages don't "think" in terms of character strings. Most people wouldn't know what you were talking about if you said the phrase "character string." Most people think in terms of words. There's absolutely no reason that a programming language couldn't treat sequences of unicode characters the same way as sequences of integers, or reals, or IP addresses.
In other words, the underlying sequence primitives could be the same. We, as programmers, have only habitually thought of them as different because a distinct underlying machine representation was necessitated by efficiency, and that underlying machine representation was unfortunately allowed to creep into the syntax and even semantics of the languages we use.
Graham's point is that with increasing computational power, we can have unified underlying primitives, which can then be optimized by the compiler. This unification would greatly simplify coding, because we wouldn't need separate whole libraries for string manipulation, as opposed to any other sequence data type. For example, in the following pseudo-code, both:
"9. It's designed for large organizations. Large organizations have different aims from hackers. They want languages that are (believed to be) suitable for use by large teams of mediocre programmers-- languages with features that, like the speed limiters in U-Haul trucks, prevent fools from doing too much damage. Hackers don't like a language that talks down to them. Hackers just want power. Historically, languages designed for large organizations (PL/I, Ada) have lost, while hacker languages (C, Perl) have won. The reason: today's teenage hacker is tomorrow's CTO."
Moreover, he argues, and quite convincingly, that one cannot afford to make the investment of time and energy to determine if every new fad language is actually worth retooling your whole consultancy or enterprise around. One *must* read the signs surrounding a language before one bothers to get up to speed on it, which might take a year or more of full time effort.
Paul Graham is saying that the evidence surrounding Java is very damning, because it shows all the signs of a language beloved of large, bureaucratic organizations (e.g., the Department of Defense), and none of the signs of languages beloved of truly excellent programmers (e.g., C, Perl, Lisp). Java is all about managerial control of programmers who have very restricted power. Real programmer's languages are all about giving the programmer great power, and trusting that he knows what to do with it.
Which means: "The bison from the city of buffalo who are pushd around by other bison from the city of buffalo, themselves push around still other bison from the city of buffalo."
"There is a delicate balance at many points in the Constitution, between making sure each individual is represented the same, and making sure each state is represented the same."
This was a necessary compromise to get small states (like Rhode Island) to ratify the constitution. It is *not* a desirable form of democratic representation, since it makes one-person-one-vote irrelevant.
In other words, the idea that states as such, and not their people, should have representation is absurd (there are chunks of federal land larger than the whole state of Rhode island -should they have two senators each?). Democracy means, quite literally, rule of the *people*, not rule of the land. The current system is a terropoly (rule of the land), not a real representative democracy.
Let's clarify this discussion. The court has *not* ruled against reverse engineering per se. The court has ruled against decrypting copyrighted material in order to accomplish reverse engineering.
So, you can reverse engineer all you want using other means (in the test case, for example, by seeing what the censor-ware blocks, and doesn't block), but you cannot reverse engineer by breaking their encryption.
SUVs are good for the planet, because the atmosphere doesn't have enough CO2, and partially combusted hydrocarbons. I thought everyone knew that.
Moreover, we need to drive cars with lower gas milage so we can become even more dependent on imported oil.
Finally, they don't have to meed passenger vehicle safety standards since they're classified as light trucks, not passenger cars, so it's far easier to be thrown from the vehicle to your death in an accident when the door flies open (you can thank not having to meet those pesky passenger vehicle standards for this one).
Seriously (in case you can't tell the above was sarcasm), what possible benefit is there to SUVs? They are purely a status vanity, and one that has demonstrably negative environmental, economic, and political impact.
Slashdot Mirror
The standard of proof in civil actions (law suits) is "preponderance of evidence," that is, "probable."
You are, perhaps confusing this with the standard for criminal trials which is "beyond a reasonable doubt," a much higher standard.
In other words, yes, "probable" is enough in a civil suit.
When you control-click or right-click on any running application's Dock icon, you get a pop-up list of all of that application's windows. The foreground window has a check mark next to it's name.
Thanks for the laugh.
Cut and paste does not work consistently across applications on any Linux desktop. It's no use saying that it *could* if only application developers would implement it for their apps. They haven't, and the result is an abortion compared even to the indifferent support seen across Windows apps. Of course the complete consistency of cut, copy, paste, copy/paste style in Mac OS is in the realm of distant fantasy for x86 desktop users on both sides of the Linux/windows fence. Maybe if every Linux app were rewritten for a particular desktop (say KDE), but that aint gonna happen any time soon.
Which won't help you if the top window with the instructions is opaque and covers the one you're typing into.
The whole point of translucency is to be able to see the contents of both stacked windows at the same time. This has nothing to do with focus-follows-mouse, and everything to do with seeing two stacked windows' contents at the same time.
This is essentially what Apple is doing with Mac OS X's window manager - using hardware accelerated OpenGL to draw all the translucent window contents as alpha blended texture maps. This requires a video card that can do non-square rectangular texture maps, so only newer machines benefit from this acceleration, which Apple calls Quartz Extreme.
Apple's version of Xfree for MacOS X does OpenGL hardware acceleration, but it doesn't do translucency (presumably, at least in part, to keep Xfree a good step and a half behind the native OS X window manager).
I too am surprised it's taken this long for someone to do it for Xfree on Linux.
That's: ... peanut."
"Two peanuts were walking down the Strasse. One was assaulted
I suppose it hasn't occurred to either of you that the authors of the Gospels were fully aware of the Old Testament prophesies, and crafted their versions of the events to fit the pre-existing prophetic verses.
Fortunately for the rest of us, precisely this notion has occurred to bible scholars, and it's commonly understood among historians that in antiquity, books were quite commonly written in such a way as to appeal to older, pre-existing literary authorities.
"And what's up with putting us in a universe where we can harm each other? What "good" god would ever do such a thing. Such a god is not "good" in any meaningful sense of the word."
Now you're catching on. Any useful definition of god would have to include the fact that god creates both good, and evil.
BTW, I'm not religious, and I certainly don't live by the Bible, but this little known feature of the almighty is stated explicity in that book:
Isaiah 45:7 (King James Version):
I form the light, and create darkness: I make peace, and create evil: I the LORD do all these things.
Note that "create evil," is in the present tense, meaning that god is continually making bad stuff happen right now! Even if one argues that the word translated as "evil" should be translated more mildly as "bad," or "rotteness," it still isn't the doing of a god who is all good.
"I've been thinking that maybe time does not existat[sic] all. That it's just an illusion caused by our memories of the past and our predictions about the future. All we really have access to is our mental state at a given instant."
This is the zen buddhist view, that reality is just a single present moment, which unfolds, or changes. We have taken this to mean, merely by convention, that there exists some abstract linear thing called time.
If you set this verbal and conceptual convention aside, you'll see that the past cannot possibly exist. It is just an abstraction from our present memories (which are quite imperfect) and observational evidence gleaned from present experience.
This does not mean that there is no causality, but rather, the buddhist interpretation is that causality is more holistic, that everything that is, is interdependent, and that it all changes continuously, in the present, in an intricately interdependent way. Teasing apart this complete interdependence into the kind of linear causality beloved of science is then seen to be impossible.
As to beginnings, we may have to accept, at least for the present, that there are limits both to our powers of observation (light cones, world lines, and all that), and our powers of conceptualization.
"And in the town I work in (and I think in most of the state) ALL mail, every single frikkin piece of it, goes to one town in the state, then gets sent back out. EVEN IF ITS LOCAL!"
You do realize that this is exactly the same transport model used by Fedex? And that their founder was laughed at for it, just as you mock the USPS for it, until he proved that it not only worked, but is more efficient than having a multitude of shipping routes locally and nationally, because it centralizes sorting.
You're joking right? I knew a guy in college who worked in a Toronto post office in high school. Every day, they would pick a package or two from one of the bins, nail it to the wall. and use it as a dart board.
Then there are those periodic Canada Post strikes when no mail moves at all.
The USPS has an incredible record for delivering thousands of tons of mail daily, over a huge territory, to hundreds of millions of people, reliably, and cheaply.
Your parent post was a joke - see the smiley? It was *sarcasm*.
The reason that there is no genetic basis for the naive (and racist) concepts of race is that all the racisits conveniently omit that large portion of humanity whose superficial charateristics fall between the racial stereotypes.
What are north africans? Are they black? "Yes," says the Norwegian racist, "because they don't have pink skin and blue eyes." "No," says the Kenyan racist, "because they have straight hair, and their skin is too light."
And so on, and on, for central asians (are they Caucasian, or Mongoloid?), and Dravidians (are they "black" or caucasian), etc. etc.
There's no genetic basis for races, because there's no real definition of what constitutes one race or the other. The only thing people ever define are the extremes (practically albino white, with straight blonde hair and blue eyes v. the darkest possible skin tone with very kinky hair) but no one can agree on where to classify the vast number of people who fall in between these extremes, and who occupy a substantial portion of the land area of our planet.
"Who knows if five (or fifty) years from now a coprocessor is designed that makes string functionality as easy to implement as arithmetic."
You've read Graham's argument completely backwards, and are, in fact, arguing his point here. Graham is saying that, with computational power increasing, we no longer need to segregate our treatment of strings from sequences of other types, and so, can deal with all sequences in a unified way, relying on the compiler and hardware to optimize the treatment of each sequence sub-type.
Now multiply this abstraction and simplification by all the disparate data types in a typical program and see how much easier it would be to program with a data type optimizing compiler doing all the book keeping for you.
"Lisp died in the early 90ies."
Lisp is alive and well (franz.com, lispworks.com, digitool.com, alu.org, cons.org, etc.)
" Java's ideas (especially the virtual machine) will survive and take over."
The virtual machine is not a Java idea. Neither is Java's broken object system. Hint: Java cribbed Smalltalk's real object system and got it wrong. Guess which OO language from the 70s ran, and still runs, on cross platform virtual machines?
The reason Java is an evolutionary dead end is not that these are not good things (Yes, a VM and garbage collection are good things). The reason is that Java didn't invent them, and has implemented OO in a broken fashion, so it is a step backwards, not a step forward. There will be no descendants of Java in a century, because future languages will be descendants of Smalltalk, or Lisp, or ML, or Erlang, i.e., descendants of languages that got the basics right, not broken.
You can write Matlab in Lisp. You can't write Lisp in Matlab.
See the difference? Graham is talking about a flexible language that can be used to write the domain specific languages (like Matlab).
Languages that are very powerful, each in its own domain, are all much less generally useful than a small, flexible language that programmers can build domain specific languages on top of. This is the power of turing complete macros. It's this flexibility that makes such a language likely to last 100 years.
"Projects like Squeak are looking more and more like Java these days, in terms of re-usability and VM-based platform independence."
Wow, do you know anything about the history of programming languages?
Java's OO is based on Smalltalk, quite intentionally, not the other way around.
Smalltalk ran on cross platform virtual machines long before Sun decided to foist it's failure of a set-top box language (i.e., Java) on the internet in the mid '90s.
Squeak is a deliberate attempt to recreate the original Smalltalk from ca. 1970.
So, yes, Java is an evolutionary dead end because it badly implements only some of the features that Smalltalk had 30 years ago, and contributes nothing new, unless, of course, you consider the exalted levels of marketing hype.
Neanderthals had children too, just not many evolutionary descendants.
I'm betting that Paul Graham doesn't think C# is likely to be around in 100 years either.
Because Paul Graham was one of the founders of the company that made the online store creation software that was purchased by Yahoo, and now forms the basis of Yahoo Store.
Unless I missed my guess, paulgraham.com is hosted on yahoo store. To wit:
whois paulgraham.com
[snip]
Domain Name: PAULGRAHAM.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS5.STORE.YAHOO.COM
Name Server: ST-NS1.YAHOO.COM
Status: ACTIVE
Updated Date: 05-nov-2001
Creation Date: 29-oct-1998
Expiration Date: 28-oct-2004
[snip]
"Graham says we should get rid of strings and use lists to represent them. But people naturally THINK in terms of character strings all the time, so it helps developers to support strings in a language."
No, programmers only "think" in terms of character strings because they've only ever worked with languages that enforced this distinction. Same way many programmers "think" that variables have a type because they've only ever worked with statically typed languages.
People who haven't been mind f*cked by restrictive programming languages don't "think" in terms of character strings. Most people wouldn't know what you were talking about if you said the phrase "character string." Most people think in terms of words. There's absolutely no reason that a programming language couldn't treat sequences of unicode characters the same way as sequences of integers, or reals, or IP addresses.
In other words, the underlying sequence primitives could be the same. We, as programmers, have only habitually thought of them as different because a distinct underlying machine representation was necessitated by efficiency, and that underlying machine representation was unfortunately allowed to creep into the syntax and even semantics of the languages we use.
Graham's point is that with increasing computational power, we can have unified underlying primitives, which can then be optimized by the compiler. This unification would greatly simplify coding, because we wouldn't need separate whole libraries for string manipulation, as opposed to any other sequence data type. For example, in the following pseudo-code, both:
sort some-string-container comparison-operator:english-alphabetical
sort some-integer-container comparison-operator: less-than
would use the same sort function, which takes a comparison function as one of its arguments.
Parent post: "He admits that the entire essay is based not on fact, but on his spooky 'Hacker's radar.'"
Not so. In fact, this is a gross mischaracterization of his essay. He enumerates 12 very specific reasons, such as:
from Java's Cover
"9. It's designed for large organizations. Large organizations have different aims from hackers. They want languages that are (believed to be) suitable for use by large teams of mediocre programmers-- languages with features that, like the speed limiters in U-Haul trucks, prevent fools from doing too much damage. Hackers don't like a language that talks down to them. Hackers just want power. Historically, languages designed for large organizations (PL/I, Ada) have lost, while hacker languages (C, Perl) have won. The reason: today's teenage hacker is tomorrow's CTO."
Moreover, he argues, and quite convincingly, that one cannot afford to make the investment of time and energy to determine if every new fad language is actually worth retooling your whole consultancy or enterprise around. One *must* read the signs surrounding a language before one bothers to get up to speed on it, which might take a year or more of full time effort.
Paul Graham is saying that the evidence surrounding Java is very damning, because it shows all the signs of a language beloved of large, bureaucratic organizations (e.g., the Department of Defense), and none of the signs of languages beloved of truly excellent programmers (e.g., C, Perl, Lisp). Java is all about managerial control of programmers who have very restricted power. Real programmer's languages are all about giving the programmer great power, and trusting that he knows what to do with it.
The canonical long single word sentence is:
"Buffalo buffalo, buffalo buffalo buffalo, buffalo buffalo buffalo."
Which means: "The bison from the city of buffalo who are pushd around by other bison from the city of buffalo, themselves push around still other bison from the city of buffalo."
"There is a delicate balance at many points in the Constitution, between making sure each individual is represented the same, and making sure each state is represented the same."
This was a necessary compromise to get small states (like Rhode Island) to ratify the constitution. It is *not* a desirable form of democratic representation, since it makes one-person-one-vote irrelevant.
In other words, the idea that states as such, and not their people, should have representation is absurd (there are chunks of federal land larger than the whole state of Rhode island -should they have two senators each?). Democracy means, quite literally, rule of the *people*, not rule of the land. The current system is a terropoly (rule of the land), not a real representative democracy.
Let's clarify this discussion. The court has *not* ruled against reverse engineering per se. The court has ruled against decrypting copyrighted material in order to accomplish reverse engineering.
So, you can reverse engineer all you want using other means (in the test case, for example, by seeing what the censor-ware blocks, and doesn't block), but you cannot reverse engineer by breaking their encryption.
SUVs are good for the planet, because the atmosphere doesn't have enough CO2, and partially combusted hydrocarbons. I thought everyone knew that.
Moreover, we need to drive cars with lower gas milage so we can become even more dependent on imported oil.
Finally, they don't have to meed passenger vehicle safety standards since they're classified as light trucks, not passenger cars, so it's far easier to be thrown from the vehicle to your death in an accident when the door flies open (you can thank not having to meet those pesky passenger vehicle standards for this one).
Seriously (in case you can't tell the above was sarcasm), what possible benefit is there to SUVs? They are purely a status vanity, and one that has demonstrably negative environmental, economic, and political impact.