that wasn't my title, actually its been completely rewritten by K Dawson, editors do a lot more than people think on here.
Are you insinuating that kdawson would deliberately change a story title to be inflammatory and sensationalist!? Perhaps if kdawson had some sort of long history of trolling Slashdot with badly written articles I might be inclined to believe you!
Anonymity and security are generally incompatible concepts. I.e. to be anonymous you have to be anybody, but to be secure you have to be someone in particular.
No you don't. You're confusing security with authentication.
You must still assume that the Tor nodes you are using are not hacked NSA or Chinese intelligence agency nodes, with a nice 'log traffic to disk' function added.
Tor is a service for browsing anonymously, not securely. Security is handled by SSL.
Sadly I believe this will NEVER ever be fixed, because its cause is rooting in those that treat Linux like a religion, rather than an Operating system, ala RMS.
But Stallman does not develop the Linux kernel; Linus Torvalds does. The lack of a stable ABI is not for religious reasons, but for technical ones.
The HTC Dream is without a doubt inferior to the N900.
The HTC Hero is pretty comparable, though. It's got a slightly less powerful processor, but it's slimmer and has a better touch screen, and like the N900 supports Flash video.
Measurements based on one project may not be as statistically robust as measurements based on a number of projects, but they are at least measurements which is better than anecdotes which is all you seem to have.
That's what he really speaks of when he talks about a language plus a great IDE... from his point of view, your inability to use really advanced refactoring tools is every bit of much a wooden leg. You just have one on the other stump.
I've programmed in Java with a number of IDEs, and yes, the refactoring tools are extremely useful. But I also found that I didn't miss them much when I programmed in dynamic languages. It's my opinion that the very attributes that allow Java to be easily refactor, i.e. its restrictive and rigid syntax, are the very attributes that ensure you need to do a lot of refactoring work in the first place.
Secondly, even if we accept that being to easily rename things is an equally useful trait in any language, then I'm still not convinced that good refactoring tools are a cost that is worth Java's terrible syntax. At best, refactoring tools make hard things easier, but Java's syntax makes some solutions infeasible.
In other words, you're saying "In order to make naming easier, I'm going to make these classes of solution infeasible." In my view, this ain't a good trade-off.
Java could do the same thing just as easily. Its not a feature of the language that has made someone write the function like that
I never said it was. My first example was an attempt to show that Clojure's syntax and basic data-structures support loose-coupling in a way that Java doesn't. My second example, the one you object to, was supposed to be an example of how Clojure's supporting libraries all tend to be loosely coupled.
I guess my example wasn't very clear. Here's the source-code of the read-lines function in question:
The read-lines function doesn't care what the type of its argument is, so long as it can create a reader from it.
The Java standard libraries don't do this because Java's type system isn't sophisticated enough to do this with any type safety. I guess you could use switch statements and casts, but it would be unusual to see such a design in Java, and counter to its culture.
The problem starts when you have a team of several programmers (8 in my case). Since most of 'smart' languages usually have many ways to implement a certain task, it results in arguments, disagreements and sometimes in ugly code.
I haven't really had a problem with this. In all the projects I've worked on, there doesn't tend to be much disagreement over technology. We get into very detailed discussions that can last for hours, but we almost always come to an agreement as to what to do. Even when developers can't agree, there's always a project lead to make the decision, and in that case everyone goes with the decision and moves on.
While I understand your first and third points, I'm not sure I get this one. Java makes it relatively easy to enforce loose coupling with its "private" keyword.
That's not quite what I mean. Whilst Java provides keywords to enforce loose coupling, its syntax and standard library don't make it easy to do so.
The collection we're going to turn into a bag could be any sequencable data. In Java, you could use generics, but you wouldn't be able to treat, say, strings in the same way:
In this case, the duck-streams library is equally happy reading lines from a file or from a URL.
In other words, functions in Clojure, like many dynamic languages, usually pay more attention to the traits of an argument than to its type. Java's type system isn't flexible enough to do this on the same scale, and Java's standard types are also too inconsistently structured.
I've measured it, and Scala code requires more time to support it
Measurements based on one project aren't exactly statistically robust. Especially if this is the first project your team has written in Scala, as your post would seem to imply.
I haven't used Scala for any considerable project, but I have written a lot of Clojure, and my experience with Clojure is the opposite to yours. I find code written in Clojure tends to be considerably more maintainable than any code in Java or C# that I've been involved in supporting.
This is partially because the source code is much shorter than it would be in Java or C#, and partially because functions are much more loosely coupled in a dynamic language.
In fact, power of Java tools is so great, it can argued that Java+IDE is in fact a higher-level language.
Java tools are useful in the same way as a wooden stump is useful. It's better than nothing, but I'd rather keep my actual leg.
In the same way, I'd prefer a language with lambdas, macros, dynamic loading, immutable fast data structures and homoiconicity. Java's IDEs go a long way to making Java bearable, but it can't compare with better designed languages.
Its easy to write unmaintainable code in any language.
In my experience, the size of the source code is a big factor in how maintainable a project is. Java source is much more verbose than other languages, so I'd say it was easier to write unmaintainable code in Java than in, say, Clojure.
Unfortunately, as the grandparent points out, in languages that aren't as rigid as Java, its more difficult to fix unmaintainable code
Again, I disagree. Languages that are less restrictive than Java result in a smaller source code and more loosely-coupled functions which makes for code that is more easily altered. This makes refactoring easier than in Java.
Java's restrictive nature makes it possible to have advanced automated refactoring tools; but these tools would be largely unnecessary if Java was more functional.
Of course, the easiest way to fix unmaintainable code is to not write it in the first place - a solution that is equally easy (or difficult, as the case may be) to apply across languages.
Disagree with this, too. Because Java is such a restrictive language, your solution space is reduced. There are patterns and program designs that are infeasible within the Java syntax. I'd argue that because it's harder to create a good design in Java, it's easier to create a bad design.
But in Java, the easy things and the hard things are equally verbose (which is great).
I'd say that in Java, the easy things are verbose and the hard things are usually infeasible.
Comparing to Python: Maintaining Java is way easier because due to its strictness, great IDEs have been developed. Refactoring code, call hierarchies and so on are just not doable in Python.
There are refactoring tools for Python, but it's true that they are not as comprehensive as the ones for Java. However, refactoring in a dynamic language like Python or Ruby is, in my experience, less important than it is in Java. In Java, you're dealing with a lot of verbose source code with a rigid class structure spread across a number of files. In Python or Ruby, you're dealing with a small amount of concise source code with a flexible class structure that's only spread across a few files.
The very things that make Java easy to refactor, such as its restrictive syntax and static classes, tend to be the same things that increase the need for refactoring in the first place.
I think a good way of explaining this is to say that the Java way of doing things compartmentalizes the complexity of a system.
Well, yes, but that wasn't quite what I was getting at. For instance, let's say I want to allow the user of my API to add a callback to an event like clicking a button. In Ruby, I could just use a block. In Java, I'd have to write an callback interface to mimic the functionality that is already built into Ruby.
When I start a new professional project, I pick the most productive language for the job, according to the circumstances. Usually it's Java because this is the language that everyone in my industry is going to know.
I agree with the gist of your post that it's easier to find Java developers than Ruby developers. But I find your use of the word "productive" a strange choice in this case. Wouldn't "maintainable" or "well-known" be better? Java may be many things, but I'm not sure it's particularly productive.
but imo nothing comes close to Java in the maintainability department.
I disagree, for two reasons. First, as Java is a very restrictive and verbose language, projects written in Java tend to use more lines of code than projects written in, for instance, Python. I find that it's much easier maintaining a small amount of complex code than it is to maintain a large amount of simple code.
Second, you cannot reduce the complexity of a project by restricting the complexity of the programming language you write it in. By not supporting complex types or lambda expressions Java becomes a more straightforward language, but the cost is that Java APIs are generally more complicated than equivalent APIs in other languages. Take a look at almost any library written in Ruby and contrast the API to an equivalent library in Java; 9 times out of 10, the Java API will a large number of methods and classes that the Ruby version can sidestep through the use of blocks and dynamic classes.
In my experience, Java is one of the least maintainable languages in widespread use.
See, you're not looking towards the future. You need to be thinking what browsers people will be using.
Are you suggesting that by the time HTML5 video becomes common, the primary method of browsing the web will be through low-power handheld devices?
I'm inclined to disagree. I think the HTML5 video format war will be largely decided before handheld devices overtake desktop machines.
And that is my greatest criticism for OSS (yes, I know generalities)--it only thinks of its own self-importance, too busy playing 'me too', and not taking the big picture into consideration
It's not just that Mozilla doesn't want to support H.264. They legally cannot do so and remain open source.
Slashdot Mirror
that wasn't my title, actually its been completely rewritten by K Dawson, editors do a lot more than people think on here.
Are you insinuating that kdawson would deliberately change a story title to be inflammatory and sensationalist!? Perhaps if kdawson had some sort of long history of trolling Slashdot with badly written articles I might be inclined to believe you!
I don't see how piracy is an idiotic term, especially from the standpoint of the people whose products are being stolen.
Piracy is a term used to refer to copyright infringement, not theft.
It's idiotic because the use of violence to rob ships at sea, is rather different act than copying data without the author's permission.
Anonymity and security are generally incompatible concepts. I.e. to be anonymous you have to be anybody, but to be secure you have to be someone in particular.
No you don't. You're confusing security with authentication.
The recent abuse of the term to refer to unauthorized duplication is idiotic.
It's idiotic, but not a recent term. Unauthorized distribution of content was called "piracy" as far back as 1603.
You must still assume that the Tor nodes you are using are not hacked NSA or Chinese intelligence agency nodes, with a nice 'log traffic to disk' function added.
Tor is a service for browsing anonymously, not securely. Security is handled by SSL.
FF started getting too slow compared to IE, both in load time and render time.
Aside from a few edge cases, FF is generally faster than IE8, especially for sites that make heavy use of Javascript.
Sadly I believe this will NEVER ever be fixed, because its cause is rooting in those that treat Linux like a religion, rather than an Operating system, ala RMS.
But Stallman does not develop the Linux kernel; Linus Torvalds does. The lack of a stable ABI is not for religious reasons, but for technical ones.
The HTC Dream is without a doubt inferior to the N900.
The HTC Hero is pretty comparable, though. It's got a slightly less powerful processor, but it's slimmer and has a better touch screen, and like the N900 supports Flash video.
Measurements based on one project may not be as statistically robust as measurements based on a number of projects, but they are at least measurements which is better than anecdotes which is all you seem to have.
What would you propose I measure?
That's what he really speaks of when he talks about a language plus a great IDE... from his point of view, your inability to use really advanced refactoring tools is every bit of much a wooden leg. You just have one on the other stump.
I've programmed in Java with a number of IDEs, and yes, the refactoring tools are extremely useful. But I also found that I didn't miss them much when I programmed in dynamic languages. It's my opinion that the very attributes that allow Java to be easily refactor, i.e. its restrictive and rigid syntax, are the very attributes that ensure you need to do a lot of refactoring work in the first place.
Secondly, even if we accept that being to easily rename things is an equally useful trait in any language, then I'm still not convinced that good refactoring tools are a cost that is worth Java's terrible syntax. At best, refactoring tools make hard things easier, but Java's syntax makes some solutions infeasible.
In other words, you're saying "In order to make naming easier, I'm going to make these classes of solution infeasible." In my view, this ain't a good trade-off.
Java could do the same thing just as easily. Its not a feature of the language that has made someone write the function like that
I never said it was. My first example was an attempt to show that Clojure's syntax and basic data-structures support loose-coupling in a way that Java doesn't. My second example, the one you object to, was supposed to be an example of how Clojure's supporting libraries all tend to be loosely coupled.
I guess my example wasn't very clear. Here's the source-code of the read-lines function in question:
The read-lines function doesn't care what the type of its argument is, so long as it can create a reader from it.
The Java standard libraries don't do this because Java's type system isn't sophisticated enough to do this with any type safety. I guess you could use switch statements and casts, but it would be unusual to see such a design in Java, and counter to its culture.
The problem starts when you have a team of several programmers (8 in my case). Since most of 'smart' languages usually have many ways to implement a certain task, it results in arguments, disagreements and sometimes in ugly code.
I haven't really had a problem with this. In all the projects I've worked on, there doesn't tend to be much disagreement over technology. We get into very detailed discussions that can last for hours, but we almost always come to an agreement as to what to do. Even when developers can't agree, there's always a project lead to make the decision, and in that case everyone goes with the decision and moves on.
While I understand your first and third points, I'm not sure I get this one. Java makes it relatively easy to enforce loose coupling with its "private" keyword.
That's not quite what I mean. Whilst Java provides keywords to enforce loose coupling, its syntax and standard library don't make it easy to do so.
For example, in Clojure I could write:
The collection we're going to turn into a bag could be any sequencable data. In Java, you could use generics, but you wouldn't be able to treat, say, strings in the same way:
Here's another example:
In this case, the duck-streams library is equally happy reading lines from a file or from a URL.
In other words, functions in Clojure, like many dynamic languages, usually pay more attention to the traits of an argument than to its type. Java's type system isn't flexible enough to do this on the same scale, and Java's standard types are also too inconsistently structured.
I've measured it, and Scala code requires more time to support it
Measurements based on one project aren't exactly statistically robust. Especially if this is the first project your team has written in Scala, as your post would seem to imply.
I haven't used Scala for any considerable project, but I have written a lot of Clojure, and my experience with Clojure is the opposite to yours. I find code written in Clojure tends to be considerably more maintainable than any code in Java or C# that I've been involved in supporting.
This is partially because the source code is much shorter than it would be in Java or C#, and partially because functions are much more loosely coupled in a dynamic language.
In fact, power of Java tools is so great, it can argued that Java+IDE is in fact a higher-level language.
Java tools are useful in the same way as a wooden stump is useful. It's better than nothing, but I'd rather keep my actual leg.
In the same way, I'd prefer a language with lambdas, macros, dynamic loading, immutable fast data structures and homoiconicity. Java's IDEs go a long way to making Java bearable, but it can't compare with better designed languages.
Obviously "fun" is subjective, but may I ask why you find a restrictive language like Java more fun than more flexible and functional languages?
Its easy to write unmaintainable code in any language.
In my experience, the size of the source code is a big factor in how maintainable a project is. Java source is much more verbose than other languages, so I'd say it was easier to write unmaintainable code in Java than in, say, Clojure.
Unfortunately, as the grandparent points out, in languages that aren't as rigid as Java, its more difficult to fix unmaintainable code
Again, I disagree. Languages that are less restrictive than Java result in a smaller source code and more loosely-coupled functions which makes for code that is more easily altered. This makes refactoring easier than in Java.
Java's restrictive nature makes it possible to have advanced automated refactoring tools; but these tools would be largely unnecessary if Java was more functional.
Of course, the easiest way to fix unmaintainable code is to not write it in the first place - a solution that is equally easy (or difficult, as the case may be) to apply across languages.
Disagree with this, too. Because Java is such a restrictive language, your solution space is reduced. There are patterns and program designs that are infeasible within the Java syntax. I'd argue that because it's harder to create a good design in Java, it's easier to create a bad design.
Which is why, to my mind, C is still the best overall language. Yes, it doesn't give you the hand-holding that other languages do
It also lacks a lot of the functionality other languages have.
What is wrong with the use his use of caps?
I think it is very readable as is.
I too see NOTHING wrong with HIS use of CAPITALIZATION.
But in Java, the easy things and the hard things are equally verbose (which is great).
I'd say that in Java, the easy things are verbose and the hard things are usually infeasible.
Comparing to Python: Maintaining Java is way easier because due to its strictness, great IDEs have been developed. Refactoring code, call hierarchies and so on are just not doable in Python.
There are refactoring tools for Python, but it's true that they are not as comprehensive as the ones for Java. However, refactoring in a dynamic language like Python or Ruby is, in my experience, less important than it is in Java. In Java, you're dealing with a lot of verbose source code with a rigid class structure spread across a number of files. In Python or Ruby, you're dealing with a small amount of concise source code with a flexible class structure that's only spread across a few files.
The very things that make Java easy to refactor, such as its restrictive syntax and static classes, tend to be the same things that increase the need for refactoring in the first place.
I think a good way of explaining this is to say that the Java way of doing things compartmentalizes the complexity of a system.
Well, yes, but that wasn't quite what I was getting at. For instance, let's say I want to allow the user of my API to add a callback to an event like clicking a button. In Ruby, I could just use a block. In Java, I'd have to write an callback interface to mimic the functionality that is already built into Ruby.
When I start a new professional project, I pick the most productive language for the job, according to the circumstances. Usually it's Java because this is the language that everyone in my industry is going to know.
I agree with the gist of your post that it's easier to find Java developers than Ruby developers. But I find your use of the word "productive" a strange choice in this case. Wouldn't "maintainable" or "well-known" be better? Java may be many things, but I'm not sure it's particularly productive.
I find Java a lot of fun.
Ah, but how many other programming languages do you regularly use?
but imo nothing comes close to Java in the maintainability department.
I disagree, for two reasons. First, as Java is a very restrictive and verbose language, projects written in Java tend to use more lines of code than projects written in, for instance, Python. I find that it's much easier maintaining a small amount of complex code than it is to maintain a large amount of simple code.
Second, you cannot reduce the complexity of a project by restricting the complexity of the programming language you write it in. By not supporting complex types or lambda expressions Java becomes a more straightforward language, but the cost is that Java APIs are generally more complicated than equivalent APIs in other languages. Take a look at almost any library written in Ruby and contrast the API to an equivalent library in Java; 9 times out of 10, the Java API will a large number of methods and classes that the Ruby version can sidestep through the use of blocks and dynamic classes.
In my experience, Java is one of the least maintainable languages in widespread use.
See, you're not looking towards the future. You need to be thinking what browsers people will be using.
Are you suggesting that by the time HTML5 video becomes common, the primary method of browsing the web will be through low-power handheld devices?
I'm inclined to disagree. I think the HTML5 video format war will be largely decided before handheld devices overtake desktop machines.
And that is my greatest criticism for OSS (yes, I know generalities)--it only thinks of its own self-importance, too busy playing 'me too', and not taking the big picture into consideration
It's not just that Mozilla doesn't want to support H.264. They legally cannot do so and remain open source.