My two examples were really of one principle: Code's look should be a hint to its function, and violating that is a problem. The point of the first example, for instance, was not that the 'z' line is necessarily incorrect; the point was that the programmer who wrote it was unclear about her intentions, effectively saying one thing to the computer and another to human readers. This being a problem is not a myth; it's common sense.
Your claim comes down to: No, such violations do not matter (or never happen in practice). You even claim to have some quantitative argument to support that. I doubt the argument will hold -- most such studies conflate to many factors to make strong positions on one language feature or other. And barring such data, your position seems quite irrational.
In a letter to one of the Israeli Activists, RMS writes:
I saw that you sent an E-mail message canceling all of your talks in Israel in the upcoming visit.
Not all of them -- only the ones at universities. It is the universities that the funders object to. I have one planned talk which is not at a university, which I still plan to give.
Apparently RMS is OK with an academic boycott, as long as he gets to talk to somebody.
There are about as many Jews in israel whose origins are in Arab and North-African countries as Jews of European descent. The claim that the state was erected "in order to oppress the people of the region" is patently false.
While Israel has its faults, many of which related to how it treats its internal non-Jewish minority as well as the semi-occupied west bank, your presentation of its origins and current state are completely misinformed and misguided.
In particular, Israeli prime minister (not president) Netanyahu made nothing like the statement you quote for him. His vision for the end of the conflict is unacceptable to Palestinians, but that's ok; no Palestinian leader has ever accepted any solution that is consistent with the existence of a Jewish state in the region.
"What's important about how Linux and open-source software is created isn't the side issues of how its developers are perceived or that its fundamental methodology produces better software; it's the politics, collaboration and empowerment of users"
Amen. Exactly what I've been saying for a couple of years. There are only two things I would like to add:
1) You missed an important factor in Java's favor: The availability of far superior IDEs. I have left the Java world, but I can tell you that VS2008 is still inferior to Intellij Idea 3.5 (of 2002).
2) You probably mean (what the grandpa forgot) auto-implemented properties:
int XXX { get; set; }
which makes the equivalent Java look like an exercise in boilerplating.
A pigeon is a kind of bird. A pidgin is a kind of language -- one that is created as a mix of others by children. It usually turns into a full-blown language within a generation or two.
You're reading his code wrong, and third-party cookies are not required.
It's not what I would call "XSS" (those, I thought, had to do with code on one frame or tab accessing objects on another, and are therefore browser problems, not site problems); it's a JavaScript injection vulnerability. The link generated by the Ruby script, allegedly, inserts JavaScript code into a Yahoo page. This code is then executed with the same permissions as Yahoo code, and what it does is read your Yahoo cookies and submit them to some other site as request arguments.
The Perl code then parses the submitted data into cookies and pretends to be Firefox accessing Yahoo with your cookies.
For those who scratch their heads in wonder, like I first did: Sys-con attributes the story to "Enterprise Open Source News Desk", but in the little letters in the end they give credit: "first appeared in Client Server News". That is www.clientservernews.com, which identifies itself as belonging to "G2 Computer Intelligence", with MoG as publisher.
25*10^4 lines of code, stored in 25*10^6 bytes, would make your average line 100 chars long. That is, visually, your code would indeed look like a novel...
His nutjobness notwithstanding, you added up communications in both directions, then compared the sum against his upload bandwidth. Unless he needs to echo back the login and denial messages (which would surprise me a great deal), he only needs (by your numbers) 135*20=3.7kB/Sec upload. Although about triple that for download would exceed a 56K modem, see the other responses about compression.
Java 1.5 is very different from older Java versions. Likewise, C# 2.0 is a lot different from 1.0. Of the two, C# seems to be evolving in much more interesting ways (and saying this pains me, as a Unix and OSS fan). The C# 3 spec drafts (available from MS, and mentioned on Lambda the Ultimate) bring in a lot of functional programming, for example. So, educationally speaking, if you are going to learn the newer versions, I would advocate C#. Note I'm doing so mainly for its non-OO features. As long as you only care about OO (and older versions), C#'s delegates are IMO an advantage, but the difference is not that big.
If you're asking "which is more fun", though, then you have to remember that you work in an environment, not just a language. Visual Studio.NET 2003 is downright retarded in comparison with any major Java IDE, for any purpose other than GUI programming. I don't know yet about 2005, and I have a feeling that SharpDevelop or MonoDevelop are not better than VS.NET.
While your 1 and 2 are essentially valid, point 3 is moot: When some company manages to retroactively claim a patent on some double-click feature, it becomes illegal to distribute the software freely, under any open source license; there's nothing wrong with the GPL there, the problem is with retroactive patents in particular and software patents in general.
The specific case where I cursed the most about not having delegates in Java was a little parser which had to modify a "result object" according to "events" detected in the input string. Nothing to do with UI. There was one state object, with many methods to effect the changes, and the most natural thing would have been to install those methods as callbacks in the more general parser object. Which I ended up doing, but I had to use reflection to do it, so I passed method names (strings) instead of method objects.
Let me rephrase your parent post: Wrapping the function in an interface (anonymous class) or an inner class makes for cumbersome, cluttered code. Instead of code you can look at and see what it's doing, you get a place for documentation that can go miles out of sync with the code.
Dynamic functions, my dear totally uninformed friend, are functions built on the fly by the program, in myriad ways -- basically, composing functions, applying higher-order functions to functions (look it up), and many other interesting things. C++ supports these notions in its standard library, in a header called <functional>, because they are elements of the functional programming paradigm. Java thinks functional is not useful, because it aims at a very low common denominator of programmers -- hence its uncoolness.
What you said earlier about passing functions around amounts to "I am not familiar with the abstractions you like, therefore they are bad". This fits in with the head-in-the-wall object-oriented approach of Java, but is not good for you. If you want to evolve as a programmer, you'll always look for new ways to abstract things.
You were wrong about the directions of casts, you were wrong about the meaning of templates. You should at least consider the possibility that your all-Java education (yes, it shows) has led you to miss a few other useful notions.
BTW: the templates In Java 1.5 are indeed only syntactic sugar, because the JVM doesn't support templates and is itself cast in stone. The CLR -- which I generally don't think too highly of -- does make room for templates, and their implementation in C#2.0 will be closer in spirit to C++'s). And even though Java's generics are only syntactic sugar, they are a great improvement.
Java is considered uncool among good programmers because good programmers seek abstractions, and factoring out commonalities. Java limits painfully the set of abstractions you can express.
The one most painful issue for me (when I wrote Java) was function objects. Java makes using functions as arguments, variables, etc. very painful (not to mention Lisp or Python's ideas of constructing functions on the fly). C# delegates cover a whole lot of that ground. I read the articles on java.sun.com explaining why there will never be delegates in Java; they are nothing but hubris and NIH syndrome.
Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts. Now, go read Stroustroup about downcasts. In C++, there are exactly two situations where you really need downcasts: 1) you're interfacing with non-C++ code, sending pointers back and forth 2) A design error This is because C++ supports proper type abstractions. Then look at Python, Perl, JavaScript, or any other dynamic language: downcasts are not needed and make no sense.
So -- the most common operation (modulu assignment and method call) in Java is one that is not needed in dynamic languages, and indicative of a design error in proper static-typed languages.
Java forces one to repeat oneself, because it excludes important classes of abstractions. This is why it sucks, and why it is uncool.
Actually, the spoken language is different in every country, and they're all different from the written language. The written language _is_ used orally in formal contexts; these include the media.
As an example, in the written language, "I learn" translates to something like "Ana a'limu" (where the ' stands for the "ayin" consonant which does not exist in any Western language I'm aware of); in Egyptian and Palestinian spoken Arabic, this becomes "Ana Bat'alam", a totally different inflection. This is not a pronunciation issue: It's an entirely different form.
Besides, there are issues of pronunciation w.r.t to the written language. E.g., Arabic has a letter pronounced like "J" in most places, but "G" (as in "go") in Egypt.
ehmm, no. Actually I'm quite straight. And I think that a man who finds his sexual orientation condemned by society is more likely than others to have issues of gender his mind. The argument wasn't that putting gender in the test was so brilliant -- from the reaction of generations later, it wasn't -- but that it was a flavor affected by his homosexuality. And in this, his homosexuality affected one of his important achievements, and was, therefore, relevant.
I didn't mean to imply that they should have named him "Gay Genius", only to remind people about the gender thing and note that it is probably related to his sexuality.
I probably should have put it in a reply higher up the thread... I didn't intend to contradict you at all, I agree with most of what you said before and all of what you said now.
I don't how it's relevant to discuss Alan Turing's sexuality in the context of his contributions to computer science.
Actually it is relevant, if you know that in the original Turing Test the computer is not just generally asked to "pass for human"; the specific setting in which it is required to do so is a game where a man and a woman are trying to convince the referee about their genders (I think they're both trying to be the woman). Now, if you can replace a computer for one of the participants without the referee noticing, you pass the test.
This is probably entirely coincidental, but in Hebrew, an "Alia" means "a coming up" or "a going up" -- as in servers or websites, but also as in going uphill, or prices going up, etc. "Alioth" is the plural. And this is a very fitting name for a place where people can upload software...
In my opinion, there is no reason that an object-oriented environment cannot implement the relational model, and thus be a true relational database.
You seem to have read the site, but missed some important points... Especially, their vehement opposition to objects as they are understood in most OO settings, and inheritance as it is understood in C++ and Java.
In particular, object Id's (=pointers, references) violate the Information Principle, one of the basic tenets of the relational model.
There are quite a few reasons for making it web-based; the main one is that applications -- and this includes company-internal applications -- require maintenance and upgrades; clients on each desktop make for a sysadmin's nightmare. Depending on context, platform-neutrality may also be important.
Most of the advantages you cite for clients can be gained through Java applets, w/out compromising any of the advantages of being web-based.
Slashdot Mirror
Oh well.
My two examples were really of one principle: Code's look should be a hint to its function, and violating that is a problem. The point of the first example, for instance, was not that the 'z' line is necessarily incorrect; the point was that the programmer who wrote it was unclear about her intentions, effectively saying one thing to the computer and another to human readers. This being a problem is not a myth; it's common sense.
Your claim comes down to: No, such violations do not matter (or never happen in practice). You even claim to have some quantitative argument to support that. I doubt the argument will hold -- most such studies conflate to many factors to make strong positions on one language feature or other. And barring such data, your position seems quite irrational.
You have got to be kidding.
In general, managed-code languages killed a whole category of bugs that you find in C/C++ programs.
In particular, Python's "if it isn't properly indented it won't work" approach prevents two kinds of bugs:
1) As noted above, the statement-intended-to-be-under-if-but-isn't.
2) The bugs that follow from misunderstanding weirdly formatted code. I have seen code that looks like
In a letter to one of the Israeli Activists, RMS writes:
There are about as many Jews in israel whose origins are in Arab and North-African countries as Jews of European descent. The claim that the state was erected "in order to oppress the people of the region" is patently false.
While Israel has its faults, many of which related to how it treats its internal non-Jewish minority as well as the semi-occupied west bank, your presentation of its origins and current state are completely misinformed and misguided.
In particular, Israeli prime minister (not president) Netanyahu made nothing like the statement you quote for him. His vision for the end of the conflict is unacceptable to Palestinians, but that's ok; no Palestinian leader has ever accepted any solution that is consistent with the existence of a Jewish state in the region.
FTFY.
Amen. Exactly what I've been saying for a couple of years. There are only two things I would like to add:
1) You missed an important factor in Java's favor: The availability of far superior IDEs. I have left the Java world, but I can tell you that VS2008 is still inferior to Intellij Idea 3.5 (of 2002).
2) You probably mean (what the grandpa forgot) auto-implemented properties:
int XXX { get; set; }
which makes the equivalent Java look like an exercise in boilerplating.
A pigeon is a kind of bird. A pidgin is a kind of language -- one that is created as a mix of others by children. It usually turns into a full-blown language within a generation or two.
http://en.wikipedia.org/wiki/Pidgin
You're reading his code wrong, and third-party cookies are not required.
It's not what I would call "XSS" (those, I thought, had to do with code on one frame or tab accessing objects on another, and are therefore browser problems, not site problems); it's a JavaScript injection vulnerability. The link generated by the Ruby script, allegedly, inserts JavaScript code into a Yahoo page. This code is then executed with the same permissions as Yahoo code, and what it does is read your Yahoo cookies and submit them to some other site as request arguments.
The Perl code then parses the submitted data into cookies and pretends to be Firefox accessing Yahoo with your cookies.
For those who scratch their heads in wonder, like I first did: Sys-con attributes the story to "Enterprise Open Source News Desk", but in the little letters in the end they give credit: "first appeared in Client Server News". That is www.clientservernews.com, which identifies itself as belonging to "G2 Computer Intelligence", with MoG as publisher.
25*10^4 lines of code, stored in 25*10^6 bytes, would make your average line 100 chars long. That is, visually, your code would indeed look like a novel...
His nutjobness notwithstanding, you added up communications in both directions, then compared the sum against his upload bandwidth. Unless he needs to echo back the login and denial messages (which would surprise me a great deal), he only needs (by your numbers) 135*20=3.7kB/Sec upload. Although about triple that for download would exceed a 56K modem, see the other responses about compression.
Java 1.5 is very different from older Java versions. Likewise, C# 2.0 is a lot different from 1.0. Of the two, C# seems to be evolving in much more interesting ways (and saying this pains me, as a Unix and OSS fan). The C# 3 spec drafts (available from MS, and mentioned on Lambda the Ultimate) bring in a lot of functional programming, for example. So, educationally speaking, if you are going to learn the newer versions, I would advocate C#. Note I'm doing so mainly for its non-OO features. As long as you only care about OO (and older versions), C#'s delegates are IMO an advantage, but the difference is not that big.
.NET 2003 is downright retarded in comparison with any major Java IDE, for any purpose other than GUI programming. I don't know yet about 2005, and I have a feeling that SharpDevelop or MonoDevelop are not better than VS.NET.
If you're asking "which is more fun", though, then you have to remember that you work in an environment, not just a language. Visual Studio
While your 1 and 2 are essentially valid, point 3 is moot: When some company manages to retroactively claim a patent on some double-click feature, it becomes illegal to distribute the software freely, under any open source license; there's nothing wrong with the GPL there, the problem is with retroactive patents in particular and software patents in general.
The specific case where I cursed the most about not having delegates in Java was a little parser which had to modify a "result object" according to "events" detected in the input string. Nothing to do with UI. There was one state object, with many methods to effect the changes, and the most natural thing would have been to install those methods as callbacks in the more general parser object. Which I ended up doing, but I had to use reflection to do it, so I passed method names (strings) instead of method objects.
Yuck.
Let me rephrase your parent post: Wrapping the function in an interface (anonymous class) or an inner class makes for cumbersome, cluttered code. Instead of code you can look at and see what it's doing, you get a place for documentation that can go miles out of sync with the code.
Dynamic functions, my dear totally uninformed friend, are functions built on the fly by the program, in myriad ways -- basically, composing functions, applying higher-order functions to functions (look it up), and many other interesting things. C++ supports these notions in its standard library, in a header called <functional>, because they are elements of the functional programming paradigm. Java thinks functional is not useful, because it aims at a very low common denominator of programmers -- hence its uncoolness.
What you said earlier about passing functions around amounts to "I am not familiar with the abstractions you like, therefore they are bad". This fits in with the head-in-the-wall object-oriented approach of Java, but is not good for you. If you want to evolve as a programmer, you'll always look for new ways to abstract things.
You were wrong about the directions of casts, you were wrong about the meaning of templates. You should at least consider the possibility that your all-Java education (yes, it shows) has led you to miss a few other useful notions.
BTW: the templates In Java 1.5 are indeed only syntactic sugar, because the JVM doesn't support templates and is itself cast in stone. The CLR -- which I generally don't think too highly of -- does make room for templates, and their implementation in C#2.0 will be closer in spirit to C++'s). And even though Java's generics are only syntactic sugar, they are a great improvement.
Java is considered uncool among good programmers because good programmers seek abstractions, and factoring out commonalities. Java limits painfully the set of abstractions you can express.
The one most painful issue for me (when I wrote Java) was function objects. Java makes using functions as arguments, variables, etc. very painful (not to mention Lisp or Python's ideas of constructing functions on the fly). C# delegates cover a whole lot of that ground. I read the articles on java.sun.com explaining why there will never be delegates in Java; they are nothing but hubris and NIH syndrome.
Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts. Now, go read Stroustroup about downcasts. In C++, there are exactly two situations where you really need downcasts:
1) you're interfacing with non-C++ code, sending pointers back and forth
2) A design error
This is because C++ supports proper type abstractions.
Then look at Python, Perl, JavaScript, or any other dynamic language: downcasts are not needed and make no sense.
So -- the most common operation (modulu assignment and method call) in Java is one that is not needed in dynamic languages, and indicative of a design error in proper static-typed languages.
Java forces one to repeat oneself, because it excludes important classes of abstractions. This is why it sucks, and why it is uncool.
Actually, the spoken language is different in every country, and they're all different from the written language. The written language _is_ used orally in formal contexts; these include the media.
As an example, in the written language, "I learn" translates to something like "Ana a'limu" (where the ' stands for the "ayin" consonant which does not exist in any Western language I'm aware of); in Egyptian and Palestinian spoken Arabic, this becomes "Ana Bat'alam", a totally different inflection. This is not a pronunciation issue: It's an entirely different form.
Besides, there are issues of pronunciation w.r.t to the written language. E.g., Arabic has a letter pronounced like "J" in most places, but "G" (as in "go") in Egypt.
ehmm, no. Actually I'm quite straight. And I think that a man who finds his sexual orientation condemned by society is more likely than others to have issues of gender his mind. The argument wasn't that putting gender in the test was so brilliant -- from the reaction of generations later, it wasn't -- but that it was a flavor affected by his homosexuality. And in this, his homosexuality affected one of his important achievements, and was, therefore, relevant.
Ahh, forget reasoning. You're a homophobic troll.
I didn't mean to imply that they should have named him "Gay Genius", only to remind people about the gender thing and note that it is probably related to his sexuality.
I probably should have put it in a reply higher up the thread... I didn't intend to contradict you at all, I agree with most of what you said before and all of what you said now.
You think homosexuality is irrelevant to that?
"software that display advertisements...pop-up windows... without permission"
It's here.
(Plug alert: I work for Platonix; this is a toy).
Thought you'd like to know.
You seem to have read the site, but missed some important points... Especially, their vehement opposition to objects as they are understood in most OO settings, and inheritance as it is understood in C++ and Java.
In particular, object Id's (=pointers, references) violate the Information Principle, one of the basic tenets of the relational model.
There are quite a few reasons for making it web-based; the main one is that applications -- and this includes company-internal applications -- require maintenance and upgrades; clients on each desktop make for a sysadmin's nightmare. Depending on context, platform-neutrality may also be important.
Most of the advantages you cite for clients can be gained through Java applets, w/out compromising any of the advantages of being web-based.