Let's assume that he is even right for a moment on all his issues. He is in an environment of people who really don't like any of these positions; yet he keeps bringing them up and pushing them in others' faces.
So you're saying that if a publicly funded research lab has a strong and vocal left-leaning majority, then people with different political views should just acquiesce? Well, from a practical point of view, you are right of course: there is simply no way to win in such a work environment.
Reasonable people just quit their job before things get out of hand. Many people who hold independent or conservative views simply get out of careers in science altogether because there are few if any work environments where they would feel comfortable. But let's not pretend that this is the way it should be.
The most damning problem in the ActiveState report is that the CLR cannot directly support a number of Python's language features.
C doesn't "directly" support a number of Python's language features and neither does the JVM. Yet, both of them have excellent Python implementations based on them.
But, I think that if anyone can pull this off, Jim can. The concern I have is whether he can keep the language alive. Development on his Jython project seems to have ground to a halt since the release of Jython-2.2a1 last summer.
Well, I used to be a very active Java and Jython user myself, but I just got pissed off by Sun's policies and have no incentive to contribute to Java or Java-related technologies anymore. I suspect many people in the OSS community feel the same way. And I suspect that's also the reason why Hugunin, a long-time open source developer and Java developer, himself is now building a project like IronPython on top of the CLR.
You will note that IronPython is not yet passing enough of Python's regression tests to work on many interesting language problems. Once it gets to that point, then I'll be interested.
It should require no more work to do that with IronPython than it did with Jython.
As an aside, I think in part, however, some of these issues are better addressed by changing the Python language; Python exposes implementation details (e.g., the use of dictionaries in objects) that make efficient implementations unnecessarily hard. I hope Hugunin will actually push for language changes and not strive for full compliance with Python's regression tests. Jython already had some beneficial effects on the Python language in that way.
Almost all those are convienences, except for operator overloading where you are basically showing a lack of working on large projects.
Value classes and a better native code interface are crucial performance improvements. Fixed exception handling and generics are important for large projects.
Operator overloating, on the other hand, is not a problem for large projects (or small projects or anybody else): if your project management can't enforce a rule as simple as "no overloaded operators on this project", then you might as well give up before you start.
There are many other open source things that do what you are looking for without resorting to a Java clone - like Parrot or TCL or...
Parrot and Tcl are slow interpreters. Mono contains a JIT that gives near-native performance on a lot of code. Mono and C# can replace C and C++ as general purpose languages, Parrot, Tcl, and Java cannot.
Java's evolution is actually handled by the JCP (independant of Sun), not by a puppet-standards body (It's why Generics was not in 1.4 as it would have been if Sun were master).
The JCP is not independent of Sun, and just because the JCP nominally manages the evolution of Java doesn't make Java "independent" or open. Sun pretty much owns Java: the specifications are proprietary, Java technology is patented with license terms that are not compatible with OSS implementations, and the only existing compliant implementations rely on Sun source code.
Is.Net really going to evolve in ways that will not help Microsoft? Get real.
First of all, Mono is not.NET; Mono, as you would know if you bothered to read the article, is both a fully independent set of APIs and libraries and a set of.NET compatibility libraries. You don't have to use the.NET compatibility libraries in Mono at all; in fact, most Mono applications don't and won't.
Second, I really don't care about whether Mono helps or hurts Microsoft. Why would that make any difference to me?
Now that's blaming the victim for the crime. There is already a huge base of Java code, which is being ported as fast as possible to.Net.
I don't see Sun as a victim. And, yes, I hope that people will port open source Java code to Mono as fast as possible so that that code will finally run on an OSS platform (I don't care one way or another whether it also gets ported to.NET).
The Javadoc claims the class never gets instantiated. But why is the existance of that class so poor design? I thought it was fairly conventient.
"System" is being used as a namespace full of static variables and functions. But because that would not be "object oriented", there is no such thing as a static variable or a static function; you have to declare a class and then put static methods and static members into it. But classe are not namespaces in Java (for example, you can import java.io.*, but you can't import System.*). To fix such limitations of such a construct, Java 1.5 adds even more kludges to the language. Object-oriented dogma has led to unnecessary language complexity. Sorry, but I find that stupid, in particular in light of several decades of experience with "class" and "module" concepts in computer science.
If you want design, go to a designer. Unless you are already highly artistic by nature as well as being a coder, your designs will look shoddy.
Yeah, and we all should go to interior decorators to have our houses decorated, professional cleaning companies to have our bathrooms cleaned, and professional shoppers to do the shopping for us.
Back in the real world, real people have to do interior decoration, cleaning, and shopping themselves. And they also have to do design themselves because they can't charge it to someone else.
Fortunately, contrary to what you claim, basic design isn't hard: color harmony, typography, and layout follow basic rules and you can use a cookbook if you really can't figure it out yourself.
Real designers do things like create original artwork, have an instinct about how colours, shapes and navigation can reinforce branding and company strategy...all those intangibles.
Yes, real designers often create web sites that load slowly, look confusing, and are hard to navigate. And, as a customer, I don't want "reinforced branding strategies", I want information, and if I don't get it quickly and with minimum hassle, any reinforcement will be negative. KISS is a good principle for web site design, and it's not hard to master (except, perhaps, for some overly trained designers).
First I thought, "What the hell is he saying. Of course it goes to an instance of the class system. What does he think all those 'final' and 'static' keywords stand for?" Then I decided to test it. I was amazed that this worked, and without even a warning!
String Integer = new String("Hello");
System.out.print(Integer);
Sorry, but you still don't understand. "out" is just a final static variable that happens to be in the class "System". "System.out" actually holds values of type "java.io.PrintStream". You can even change the code that gets invoked when you call "System.out.print" by using "System.setOut". I doubt java.lang.System ever gets instantiated (its existence just attests to another design stupidity in Java).
With the method overloading, you have the class which the method belongs to, so it is fairly easy to check what it does.
The same is true for operator overloading. "x + y" means nothing other than "x.__plus__(y)".
I gave them very explanatory names, but even with something more cryptic, non static like
x.print(d); I know that the behaviour of print MUST be defined in the class x and nowhere else.
"x" isn't a class, it's a variable that holds an instance of a class. You need to know both the class of the instance of x and the type of the argument d to determine which piece of code will get invoked. The same would be true if you used operator syntax like, say, "x << d".
On the other hand, with operator overloading, whenever you join a new project you must keep in mind that it is possible that an operator has been overloaded to do something surprising.
That is always the case with overloading or method dispatch; "x.print()" may reboot your computer instead of the expected operation.
Other classes can have print methods, such as
System.out.print("Hello"); but I always see the classname first, so there is no risk of confusion between the methods.
You are only seeing a class name first because "out" happens to be a static variable in class System. In fact, "System.out.print" doesn't even invoke a method on an instance of class System, it invokes a method defined in the class of the instance that the variable System.out happens to hold. You can't even tell at compile time what class that instance belongs to (but it's a sure bet that it isn't an instance of class "System").
With the method overloading, you have the class which the method belongs to, so it is fairly easy to check what it does.
The same is true for operator overloading. "x + y" means nothing other than "x.__plus__(y)".
I gave them very explanatory names, but even with something more cryptic, non static like
x.print(d); I know that the behaviour of print MUST be defined in the class x and nowhere else.
"x" isn't a class, it's a variable that holds an instance of a class. You need to know both the class of the instance of x and the type of the argument d to determine which piece of code will get invoked. The same would be true if you used operator syntax like, say, "x On the other hand, with operator overloading, whenever you join a new project you must keep in mind that it is possible that an operator has been overloaded to do something surprising.
That is always the case with overloading or method dispatch; "x.print()" may reboot your computer instead of the expected operation.
Other classes can have print methods, such as
System.out.print("Hello"); but I always see the classname first, so there is no risk of confusion between the methods.
You are only seeing a class name first because "out" happens to be a static variable in class System. In fact, "System.out.print" doesn't even invoke a method on an instance of class System, it invokes a method defined in the class of the instance that the variable System.out happens to hold. You can't even tell at compile time what class that instance belongs to (but it's a sure bet that it isn't an instance of class "System").
All the languages in use in industry today represent decades-old technology.
Sorry, that should have read
All the languages in
common use in industry today represent decades-old technology.
Of course, in niche applications, people are using more sophisticated technologies. But C#, Java, Eiffel, C++, VisualBasic, COBOL, Perl, Python, and all that are basically equivalent to languages from the early 1980's or before.
Seriously though,.Net is a nice language with some advancements over Java, but not different enough from Java to make its existence worthwhile.
Maybe not if your idea of programming is limited to hacking J2EE server-side components and a few flaky GUI apps.
For the rest of us, C#'s better native interface, value classes, operator overloading, fixed generics, and fixed exception handling alone are worth it as a language alone.
Add to that that there is a high-quality open source implementation (Mono) and a complete stack of non-proprietary open-source libraries (Gtk#, etc.), and people have really strong reasons for preferring Mono to Java.
But as it is I see the tremendous duplication of effort across the world to do the same things in Java and C#, and it just makes me sad.
Well, do you think that Microsoft and the OSS community are spending time on.NET and Mono respectively for the fun of it? Sun forced this duplication: through their proprietary license requirements for Java and through their poor handling of Java's technical evolution. In the end, Java's evolution is primarily driven by what makes money for Sun, and that's why Sun has neglected client-side Java and Java numerics, for example. And the reason why they could get away with that is because they have retained legal control of Java.
So, if this "duplication of effort" makes you "sad", complain to McNealy and Gosling and Schwartz and all of the other Sun managers: it's their responsibility, it's their greed, and it's their fault that it has come to this.
Autoboxing yes, but I don't believe that they have operator overloading in mind. I've heard Gosling say that it adds a lot of complexity to interpreting a program while adding relatively little expressive power.
The "complexity" comes with overloading, which Java already has. Once you have added overloading to a language, you might as well add operator overloading.
This is just one of the many stupid things Gosling keeps saying; people should just stop taking him seriously.
I realize that this is an unpopular opinion here on Slashdot, but C# is actually a pretty cool language and the.NET runtime is a promising platform.
Yes, I agree.
Microsoft didn't just dream this up overnight... they had a lot of smart people working a long time creating this beast. It would certainly benefit us to learn about these technologies and leverage them, rather than to unilaterally declare them evil, wrong, stupid, etc. and just bury our heads in the sand and pretend they dont exist.
You make it sound like Microsoft came up with some amazing new technology when they created C#, but they didn't. While C# is (in some sense) more advanced than, say, Java or C++, there is nothing significantly new in C#. All the languages in use in industry today represent decades-old technology.
If you want to learn something, don't bother looking to either Sun or Microsoft, look to the computer science literature. If more people did that, software might be a lot better than it is.
Nah, it costs ~$10K to prepare and file for a patent and 95% of that money goes to the lawyers preparing your application.
You have typical corporate blinders on: you think the only costs associated with a patent are those that show up under the heading "patent expenses".
You are forgetting about all the other costs that writing a patent involves, foremost the work that goes into it on the part of the researchers and engineers, clerical work, patent incentive programs, etc. You see, that doesn't come for free either: those people want to get paid, too, and they aren't writing patents out of charity. Every day a researcher spends working on a patent is a day not spent doing research.
If your patent process works well, you pay about $50k/patent just to file it; if not, the costs are probably much higher (or your patent ends up being worthless). To enforce it and perhaps even defend it, the costs easily go into the millions.
I knew about it, as did many other people. But you have to realize that coding theory is a pretty funny and insular field. Related techniques had been used in other fields for many years prior to that discovery. Most people who work in this general area of statistics simply don't think about coding and aren't interested in it. One of the obstacles is that people who build communications systems generally are engineers thinking about fast, low-level processing; their first reaction to anything non-trivial and new is that it's too slow to be implemented in practice.
Turbo coding is ultimately not much of a theoretical breakthrough, but a compromise and algorithmic hack that happens to work fairly well for real-world problems and is expressed in a language that people who work on communications systems understand. But that's nothing to be sneezed at, since it will ultimately mean that we will get higher data rates and other benefits in real-world products.
The problem is determining who is infected. I've run nmap from my home machine to test some servers at work; this might be classified as "infected". Or a mailing list manager running on a home machine might be judged to be a spammer just because it makes a lot of outgoing port 25 connections. Even if you base things based on human complaints, people might still try to cause you trouble by claiming incorrectly that your machine spams. I'm not convinced that turning off spammers and other network abusers can be done correctly.
I do R&D in microelectronics. Most of the projects I work in involve an investment of hundreds of thousands of dollars, if not millions of dollars, of equipment and manpower.
I think you are a bit naive, here. Hundreds of thousands of dollars barely pays for the costs of a patent, let alone any kind of significant R&D project.
When the final product comes out our profits are figured not only on production costs, but those development costs. If we did not have a patent for our devices, a week after we come out with a new product, another company would be able to sell the same product at a lower cost because they did not have to spend the money to do the development work. Hence anything they make over production costs will already be profit.
That's a completely naive analysis of cost structure. Even if the other company were completely copying your product, in addition to production, they would have to spend a lot of money on development and marketing, and reverse engineering is often more costly than just doing the research themselves.
Thus at least in my own specific experience (and yes, in my self interest, since I'd be out of a job) cutting edge technology would not be able to exist as it is today. There is no way we can just make small changes, because every little change we make means we have to retool at least some of the fab line. So when we turn out a new product, it has to be a significant step above what we previously had, to justify the expense of the changeover.
See, here you contradict yourself. On the one hand, you claim that your competitors can crank out copies of your products with no more than production costs, and on the other hand, you say that even small changes require you to "retool your fab".
The logial conclusion? Your company is uncompetitive and you are using patents to try to make up for the fact that your company doesn't know how to run its business and engineering operations. And what does that tell us? That your company should go out of business and be replaced by something more efficient. Too bad that, as you are telling us, your inefficient company has gotten 20 year monopolies that will let them continue to extort money from other, more efficient manufacturers until long after any of your company's R&D operations have shut down.
I suppose I could try to make a new device within the constraints of what we already have the capability of making. But in the competitive world that I live in, if we already have the capability to make it, chances are someone else has already done it.
Again, you are admitting that the patent system, for you, is not a way of encouraging innovation. Because if "someone else has already done it", it means that "it" is easy to do for lots of people and the patent system essentially becomes a lottery for who will win a monopoly for the next 20 years (only large companies with big legal staffs can enter that lottery, however).
I am not playing. This is my livihood we're talking about here. If we were not able to patent our products, I would not be able to go to my boss
You are just looking for the government to give your company a nice, guaranteed handout for the next 20 years because you have already told us that (1) your company is uncompetitive when it comes to manufacturing and (2) the things you "invent" are so simple that there are lots of other companies who could already be manufacturing them.
If we are going to give government handouts to research, let's do it more efficiently than the patent system: invest the money directly in research. That way, at least the technological advances that are made will be manufactured by efficient companies, not by companies like yours, which obviously seem to invest more in their legal staff than in their engineering staff.
And if we are going to give companies temporary monopolies, let's make them a more meaningful lifespan: to protect the kind of research that goes into your products (you yourself told us that your lifecycle is very short), 3-5 years ought to be sufficient.
with companies able to raid, confiscate and freeze the bank accounts of those accused of copyright infringement.
Maybe one can use this against GPL violations. What does the legislation say about when, oh, Phillips or Vivendi might be violating GPL terms? Can we have their assets frozen?
Yes, and how many applications actually use it that way? File systems are being used that way by numerous applications every day. In fact, most databases store blobs in the file system.
FWIW, Subversion allows different backends, however no others have been written yet.
Have the harddisk spin down (e.g., hdparm, noflushd), dim the screen, lower the processor speed (e.g., longrun). In general, it shouldn't take a lot of effort to get similar battery life using Windows and Linux.
If you buy your machine from a vendor that supports and pre-installs Linux (e.g., emperorlinux.com), they probably will take care of the necessary configuration for you.
Bullshit. Your "simple" solution requires AT LEAST as much conceptual overhead and abstraction as using a proper database,
It may well require the same amount of "conceptual overhead", but it has much less coupling, fewer software dependencies, much less total code, and fewer system calls for each transaction.
as an added nonbonus, you're stuck with the '70s era Unix filesystem semantics and security model
Yes: you are "stuck with" a set of time-tested semantics and a proven security model. (Of course, what any of those comments have to do with Berkeley DB, I don't know, given that Berkeley DB actually relies on file system semantics for its security.)
Now, if you don't need atomicity, or transactional guarantees, or any of the other goodies that a proper database provides, I agree that the filesystem can be a viable alternative.
Yes, you keep telling us that you yourself don't know how to do those things with the UNIX file system. What's your point?
Anyone who'd ever built even a moderately complex application on top of a Unix filesystem would blanch at your suggestion that a combination of "lock files" and Unix primitives provides anything like a universal guarantee of atomicity.
No, not "anyone", only "almost anyone". And at some point 95% of the world believed the earth was flat, too. So what? Most people don't know what they are doing and don't use their own brain, they just mindlessly repeat what they have heard. It really doesn't matter to me, and it shouldn't to anybody else, what the majority of people say. Use your own head for a change.
Not in this case, however. svn's use of Berkeley DB is to me, perfectly appropriate.
Subversion's use of Berkeley DB is appropriate not because it is needed on UNIX, but because Subversion wants to be independent of the underlying file system.
However, it is cause for concern. For example, I know that the UNIX file system can easily and efficiently handle files that are gigabytes in size (because lots of people are using UNIX file systems that way), but I have less confidence that Berkeley DB can handle many records well that are that big.
Looking at various stuff that's been made in the US in the past half century, I can think of a few other examples right now.
You seem to have lost the context; we are talking about whether replacing old PC hardware with new PC hardware saves power; it generally doesn't. LCD monitors are probably one of the few examples (for CRTs, you could always just turn them off even prior to EnergyStar).
Tell me, sensei, how to do a multiple file rollback on a raw Unix filesystem? Or how I can ensure transactional integrity without a transaction manager?
With "link", "fsync", lock files, and directories. Read some UNIX source code to see how to build more complex transactional guarantees on top of that.
And, no, I'm not your "sensei". If you want an education, pay someone or at least buy yourself a good UNIX book.
Oh wait -- you can't. The facility doesn't exist.
What's lacking is not some UNIX system call, but experience and knowledge on your part. People like you go for the most complex solution because they just can't figure out how to keep things simple, and that's at the root of a lot of the problems with software today.
But the filesystem(Atleast if you use posix functions to communicate with your filesystem), still lag atomic write, transactions and rollback.
UNIX file systems, of course, have atomic write, transactions, and rollback, they just aren't called that. Read some books on UNIX and look at how this sort of thing is handled in systems that do, in fact, use the UNIX file system as a database. For its particular application areas, the UNIX file system is so good that many relational databases use it to store blobs in (rather than the other way around).
(I don't know whether POSIX mandates the various behaviors that make the UNIX file system work, but that's another issue. We are talking about UNIX and Linux here, not POSIX.)
Slashdot Mirror
So you're saying that if a publicly funded research lab has a strong and vocal left-leaning majority, then people with different political views should just acquiesce? Well, from a practical point of view, you are right of course: there is simply no way to win in such a work environment.
Reasonable people just quit their job before things get out of hand. Many people who hold independent or conservative views simply get out of careers in science altogether because there are few if any work environments where they would feel comfortable. But let's not pretend that this is the way it should be.
The most damning problem in the ActiveState report is that the CLR cannot directly support a number of Python's language features.
C doesn't "directly" support a number of Python's language features and neither does the JVM. Yet, both of them have excellent Python implementations based on them.
But, I think that if anyone can pull this off, Jim can. The concern I have is whether he can keep the language alive. Development on his Jython project seems to have ground to a halt since the release of Jython-2.2a1 last summer.
Well, I used to be a very active Java and Jython user myself, but I just got pissed off by Sun's policies and have no incentive to contribute to Java or Java-related technologies anymore. I suspect many people in the OSS community feel the same way. And I suspect that's also the reason why Hugunin, a long-time open source developer and Java developer, himself is now building a project like IronPython on top of the CLR.
You will note that IronPython is not yet passing enough of Python's regression tests to work on many interesting language problems. Once it gets to that point, then I'll be interested.
It should require no more work to do that with IronPython than it did with Jython.
As an aside, I think in part, however, some of these issues are better addressed by changing the Python language; Python exposes implementation details (e.g., the use of dictionaries in objects) that make efficient implementations unnecessarily hard. I hope Hugunin will actually push for language changes and not strive for full compliance with Python's regression tests. Jython already had some beneficial effects on the Python language in that way.
Almost all those are convienences, except for operator overloading where you are basically showing a lack of working on large projects.
.Net really going to evolve in ways that will not help Microsoft? Get real.
.NET; Mono, as you would know if you bothered to read the article, is both a fully independent set of APIs and libraries and a set of .NET compatibility libraries. You don't have to use the .NET compatibility libraries in Mono at all; in fact, most Mono applications don't and won't.
.Net.
.NET).
Value classes and a better native code interface are crucial performance improvements. Fixed exception handling and generics are important for large projects.
Operator overloating, on the other hand, is not a problem for large projects (or small projects or anybody else): if your project management can't enforce a rule as simple as "no overloaded operators on this project", then you might as well give up before you start.
There are many other open source things that do what you are looking for without resorting to a Java clone - like Parrot or TCL or...
Parrot and Tcl are slow interpreters. Mono contains a JIT that gives near-native performance on a lot of code. Mono and C# can replace C and C++ as general purpose languages, Parrot, Tcl, and Java cannot.
Java's evolution is actually handled by the JCP (independant of Sun), not by a puppet-standards body (It's why Generics was not in 1.4 as it would have been if Sun were master).
The JCP is not independent of Sun, and just because the JCP nominally manages the evolution of Java doesn't make Java "independent" or open. Sun pretty much owns Java: the specifications are proprietary, Java technology is patented with license terms that are not compatible with OSS implementations, and the only existing compliant implementations rely on Sun source code.
Is
First of all, Mono is not
Second, I really don't care about whether Mono helps or hurts Microsoft. Why would that make any difference to me?
Now that's blaming the victim for the crime. There is already a huge base of Java code, which is being ported as fast as possible to
I don't see Sun as a victim. And, yes, I hope that people will port open source Java code to Mono as fast as possible so that that code will finally run on an OSS platform (I don't care one way or another whether it also gets ported to
The Javadoc claims the class never gets instantiated. But why is the existance of that class so poor design? I thought it was fairly conventient.
"System" is being used as a namespace full of static variables and functions. But because that would not be "object oriented", there is no such thing as a static variable or a static function; you have to declare a class and then put static methods and static members into it. But classe are not namespaces in Java (for example, you can import java.io.*, but you can't import System.*). To fix such limitations of such a construct, Java 1.5 adds even more kludges to the language. Object-oriented dogma has led to unnecessary language complexity. Sorry, but I find that stupid, in particular in light of several decades of experience with "class" and "module" concepts in computer science.
If you want design, go to a designer. Unless you are already highly artistic by nature as well as being a coder, your designs will look shoddy.
Yeah, and we all should go to interior decorators to have our houses decorated, professional cleaning companies to have our bathrooms cleaned, and professional shoppers to do the shopping for us.
Back in the real world, real people have to do interior decoration, cleaning, and shopping themselves. And they also have to do design themselves because they can't charge it to someone else.
Fortunately, contrary to what you claim, basic design isn't hard: color harmony, typography, and layout follow basic rules and you can use a cookbook if you really can't figure it out yourself.
Real designers do things like create original artwork, have an instinct about how colours, shapes and navigation can reinforce branding and company strategy...all those intangibles.
Yes, real designers often create web sites that load slowly, look confusing, and are hard to navigate. And, as a customer, I don't want "reinforced branding strategies", I want information, and if I don't get it quickly and with minimum hassle, any reinforcement will be negative. KISS is a good principle for web site design, and it's not hard to master (except, perhaps, for some overly trained designers).
First I thought, "What the hell is he saying. Of course it goes to an instance of the class system. What does he think all those 'final' and 'static' keywords stand for?" Then I decided to test it. I was amazed that this worked, and without even a warning!
String Integer = new String("Hello");
System.out.print(Integer);
Sorry, but you still don't understand. "out" is just a final static variable that happens to be in the class "System". "System.out" actually holds values of type "java.io.PrintStream". You can even change the code that gets invoked when you call "System.out.print" by using "System.setOut". I doubt java.lang.System ever gets instantiated (its existence just attests to another design stupidity in Java).
With the method overloading, you have the class which the method belongs to, so it is fairly easy to check what it does.
The same is true for operator overloading. "x + y" means nothing other than "x.__plus__(y)".
I gave them very explanatory names, but even with something more cryptic, non static like
x.print(d);
I know that the behaviour of print MUST be defined in the class x and nowhere else.
"x" isn't a class, it's a variable that holds an instance of a class. You need to know both the class of the instance of x and the type of the argument d to determine which piece of code will get invoked. The same would be true if you used operator syntax like, say, "x << d".
On the other hand, with operator overloading, whenever you join a new project you must keep in mind that it is possible that an operator has been overloaded to do something surprising.
That is always the case with overloading or method dispatch; "x.print()" may reboot your computer instead of the expected operation.
Other classes can have print methods, such as
System.out.print("Hello");
but I always see the classname first, so there is no risk of confusion between the methods.
You are only seeing a class name first because "out" happens to be a static variable in class System. In fact, "System.out.print" doesn't even invoke a method on an instance of class System, it invokes a method defined in the class of the instance that the variable System.out happens to hold. You can't even tell at compile time what class that instance belongs to (but it's a sure bet that it isn't an instance of class "System").
With the method overloading, you have the class which the method belongs to, so it is fairly easy to check what it does.
The same is true for operator overloading. "x + y" means nothing other than "x.__plus__(y)".
I gave them very explanatory names, but even with something more cryptic, non static like
x.print(d);
I know that the behaviour of print MUST be defined in the class x and nowhere else.
"x" isn't a class, it's a variable that holds an instance of a class. You need to know both the class of the instance of x and the type of the argument d to determine which piece of code will get invoked. The same would be true if you used operator syntax like, say, "x On the other hand, with operator overloading, whenever you join a new project you must keep in mind that it is possible that an operator has been overloaded to do something surprising.
That is always the case with overloading or method dispatch; "x.print()" may reboot your computer instead of the expected operation.
Other classes can have print methods, such as
System.out.print("Hello");
but I always see the classname first, so there is no risk of confusion between the methods.
You are only seeing a class name first because "out" happens to be a static variable in class System. In fact, "System.out.print" doesn't even invoke a method on an instance of class System, it invokes a method defined in the class of the instance that the variable System.out happens to hold. You can't even tell at compile time what class that instance belongs to (but it's a sure bet that it isn't an instance of class "System").
Sorry, that should have read
Of course, in niche applications, people are using more sophisticated technologies. But C#, Java, Eiffel, C++, VisualBasic, COBOL, Perl, Python, and all that are basically equivalent to languages from the early 1980's or before.
Just because ActiveState screwed up doesn't mean that the CLR runtime is bad. In fact, recent work on Python implementations on top of the CLR beats both Jython and even the native C-based implementation.
Seriously though, .Net is a nice language with some advancements over Java, but not different enough from Java to make its existence worthwhile.
.NET and Mono respectively for the fun of it? Sun forced this duplication: through their proprietary license requirements for Java and through their poor handling of Java's technical evolution. In the end, Java's evolution is primarily driven by what makes money for Sun, and that's why Sun has neglected client-side Java and Java numerics, for example. And the reason why they could get away with that is because they have retained legal control of Java.
Maybe not if your idea of programming is limited to hacking J2EE server-side components and a few flaky GUI apps.
For the rest of us, C#'s better native interface, value classes, operator overloading, fixed generics, and fixed exception handling alone are worth it as a language alone.
Add to that that there is a high-quality open source implementation (Mono) and a complete stack of non-proprietary open-source libraries (Gtk#, etc.), and people have really strong reasons for preferring Mono to Java.
But as it is I see the tremendous duplication of effort across the world to do the same things in Java and C#, and it just makes me sad.
Well, do you think that Microsoft and the OSS community are spending time on
So, if this "duplication of effort" makes you "sad", complain to McNealy and Gosling and Schwartz and all of the other Sun managers: it's their responsibility, it's their greed, and it's their fault that it has come to this.
Autoboxing yes, but I don't believe that they have operator overloading in mind. I've heard Gosling say that it adds a lot of complexity to interpreting a program while adding relatively little expressive power.
The "complexity" comes with overloading, which Java already has. Once you have added overloading to a language, you might as well add operator overloading.
This is just one of the many stupid things Gosling keeps saying; people should just stop taking him seriously.
I realize that this is an unpopular opinion here on Slashdot, but C# is actually a pretty cool language and the .NET runtime is a promising platform.
Yes, I agree.
Microsoft didn't just dream this up overnight... they had a lot of smart people working a long time creating this beast. It would certainly benefit us to learn about these technologies and leverage them, rather than to unilaterally declare them evil, wrong, stupid, etc. and just bury our heads in the sand and pretend they dont exist.
You make it sound like Microsoft came up with some amazing new technology when they created C#, but they didn't. While C# is (in some sense) more advanced than, say, Java or C++, there is nothing significantly new in C#. All the languages in use in industry today represent decades-old technology.
If you want to learn something, don't bother looking to either Sun or Microsoft, look to the computer science literature. If more people did that, software might be a lot better than it is.
Nah, it costs ~$10K to prepare and file for a patent and 95% of that money goes to the lawyers preparing your application.
You have typical corporate blinders on: you think the only costs associated with a patent are those that show up under the heading "patent expenses".
You are forgetting about all the other costs that writing a patent involves, foremost the work that goes into it on the part of the researchers and engineers, clerical work, patent incentive programs, etc. You see, that doesn't come for free either: those people want to get paid, too, and they aren't writing patents out of charity. Every day a researcher spends working on a patent is a day not spent doing research.
If your patent process works well, you pay about $50k/patent just to file it; if not, the costs are probably much higher (or your patent ends up being worthless). To enforce it and perhaps even defend it, the costs easily go into the millions.
Where is the novelty in this patent? That idea has been around almost as long as rockets and satellites have been part of science fiction.
I knew about it, as did many other people. But you have to realize that coding theory is a pretty funny and insular field. Related techniques had been used in other fields for many years prior to that discovery. Most people who work in this general area of statistics simply don't think about coding and aren't interested in it. One of the obstacles is that people who build communications systems generally are engineers thinking about fast, low-level processing; their first reaction to anything non-trivial and new is that it's too slow to be implemented in practice.
Turbo coding is ultimately not much of a theoretical breakthrough, but a compromise and algorithmic hack that happens to work fairly well for real-world problems and is expressed in a language that people who work on communications systems understand. But that's nothing to be sneezed at, since it will ultimately mean that we will get higher data rates and other benefits in real-world products.
The problem is determining who is infected. I've run nmap from my home machine to test some servers at work; this might be classified as "infected". Or a mailing list manager running on a home machine might be judged to be a spammer just because it makes a lot of outgoing port 25 connections. Even if you base things based on human complaints, people might still try to cause you trouble by claiming incorrectly that your machine spams. I'm not convinced that turning off spammers and other network abusers can be done correctly.
I do R&D in microelectronics. Most of the projects I work in involve an investment of hundreds of thousands of dollars, if not millions of dollars, of equipment and manpower.
I think you are a bit naive, here. Hundreds of thousands of dollars barely pays for the costs of a patent, let alone any kind of significant R&D project.
When the final product comes out our profits are figured not only on production costs, but those development costs. If we did not have a patent for our devices, a week after we come out with a new product, another company would be able to sell the same product at a lower cost because they did not have to spend the money to do the development work. Hence anything they make over production costs will already be profit.
That's a completely naive analysis of cost structure. Even if the other company were completely copying your product, in addition to production, they would have to spend a lot of money on development and marketing, and reverse engineering is often more costly than just doing the research themselves.
Thus at least in my own specific experience (and yes, in my self interest, since I'd be out of a job) cutting edge technology would not be able to exist as it is today. There is no way we can just make small changes, because every little change we make means we have to retool at least some of the fab line. So when we turn out a new product, it has to be a significant step above what we previously had, to justify the expense of the changeover.
See, here you contradict yourself. On the one hand, you claim that your competitors can crank out copies of your products with no more than production costs, and on the other hand, you say that even small changes require you to "retool your fab".
The logial conclusion? Your company is uncompetitive and you are using patents to try to make up for the fact that your company doesn't know how to run its business and engineering operations. And what does that tell us? That your company should go out of business and be replaced by something more efficient. Too bad that, as you are telling us, your inefficient company has gotten 20 year monopolies that will let them continue to extort money from other, more efficient manufacturers until long after any of your company's R&D operations have shut down.
I suppose I could try to make a new device within the constraints of what we already have the capability of making. But in the competitive world that I live in, if we already have the capability to make it, chances are someone else has already done it.
Again, you are admitting that the patent system, for you, is not a way of encouraging innovation. Because if "someone else has already done it", it means that "it" is easy to do for lots of people and the patent system essentially becomes a lottery for who will win a monopoly for the next 20 years (only large companies with big legal staffs can enter that lottery, however).
I am not playing. This is my livihood we're talking about here. If we were not able to patent our products, I would not be able to go to my boss
You are just looking for the government to give your company a nice, guaranteed handout for the next 20 years because you have already told us that (1) your company is uncompetitive when it comes to manufacturing and (2) the things you "invent" are so simple that there are lots of other companies who could already be manufacturing them.
If we are going to give government handouts to research, let's do it more efficiently than the patent system: invest the money directly in research. That way, at least the technological advances that are made will be manufactured by efficient companies, not by companies like yours, which obviously seem to invest more in their legal staff than in their engineering staff.
And if we are going to give companies temporary monopolies, let's make them a more meaningful lifespan: to protect the kind of research that goes into your products (you yourself told us that your lifecycle is very short), 3-5 years ought to be sufficient.
with companies able to raid, confiscate and freeze the bank accounts of those accused of copyright infringement.
Maybe one can use this against GPL violations. What does the legislation say about when, oh, Phillips or Vivendi might be violating GPL terms? Can we have their assets frozen?
4G/256T is big enough for most applications...
Yes, and how many applications actually use it that way? File systems are being used that way by numerous applications every day. In fact, most databases store blobs in the file system.
FWIW, Subversion allows different backends, however no others have been written yet.
Someone should write a file system backend...
Have the harddisk spin down (e.g., hdparm, noflushd), dim the screen, lower the processor speed (e.g., longrun). In general, it shouldn't take a lot of effort to get similar battery life using Windows and Linux.
If you buy your machine from a vendor that supports and pre-installs Linux (e.g., emperorlinux.com), they probably will take care of the necessary configuration for you.
Bullshit. Your "simple" solution requires AT LEAST as much conceptual overhead and abstraction as using a proper database,
It may well require the same amount of "conceptual overhead", but it has much less coupling, fewer software dependencies, much less total code, and fewer system calls for each transaction.
as an added nonbonus, you're stuck with the '70s era Unix filesystem semantics and security model
Yes: you are "stuck with" a set of time-tested semantics and a proven security model. (Of course, what any of those comments have to do with Berkeley DB, I don't know, given that Berkeley DB actually relies on file system semantics for its security.)
Now, if you don't need atomicity, or transactional guarantees, or any of the other goodies that a proper database provides, I agree that the filesystem can be a viable alternative.
Yes, you keep telling us that you yourself don't know how to do those things with the UNIX file system. What's your point?
Anyone who'd ever built even a moderately complex application on top of a Unix filesystem would blanch at your suggestion that a combination of "lock files" and Unix primitives provides anything like a universal guarantee of atomicity.
No, not "anyone", only "almost anyone". And at some point 95% of the world believed the earth was flat, too. So what? Most people don't know what they are doing and don't use their own brain, they just mindlessly repeat what they have heard. It really doesn't matter to me, and it shouldn't to anybody else, what the majority of people say. Use your own head for a change.
Not in this case, however. svn's use of Berkeley DB is to me, perfectly appropriate.
Subversion's use of Berkeley DB is appropriate not because it is needed on UNIX, but because Subversion wants to be independent of the underlying file system.
However, it is cause for concern. For example, I know that the UNIX file system can easily and efficiently handle files that are gigabytes in size (because lots of people are using UNIX file systems that way), but I have less confidence that Berkeley DB can handle many records well that are that big.
Looking at various stuff that's been made in the US in the past half century, I can think of a few other examples right now.
You seem to have lost the context; we are talking about whether replacing old PC hardware with new PC hardware saves power; it generally doesn't. LCD monitors are probably one of the few examples (for CRTs, you could always just turn them off even prior to EnergyStar).
Tell me, sensei, how to do a multiple file rollback on a raw Unix filesystem? Or how I can ensure transactional integrity without a transaction manager?
With "link", "fsync", lock files, and directories. Read some UNIX source code to see how to build more complex transactional guarantees on top of that.
And, no, I'm not your "sensei". If you want an education, pay someone or at least buy yourself a good UNIX book.
Oh wait -- you can't. The facility doesn't exist.
What's lacking is not some UNIX system call, but experience and knowledge on your part. People like you go for the most complex solution because they just can't figure out how to keep things simple, and that's at the root of a lot of the problems with software today.
But the filesystem(Atleast if you use posix functions to communicate with your filesystem), still lag atomic write, transactions and rollback.
UNIX file systems, of course, have atomic write, transactions, and rollback, they just aren't called that. Read some books on UNIX and look at how this sort of thing is handled in systems that do, in fact, use the UNIX file system as a database. For its particular application areas, the UNIX file system is so good that many relational databases use it to store blobs in (rather than the other way around).
(I don't know whether POSIX mandates the various behaviors that make the UNIX file system work, but that's another issue. We are talking about UNIX and Linux here, not POSIX.)