Back when I was concerned about whether BRL had decent performance, I did a simple benchmark on a 586 Debian box with Apache/php3 vs Apache/Jserv/BRL. PHP could beat BRL if BRL used Sun's JRE, but BRL beat PHP using IBM's JRE. When I switched from Apache/JServ to a Jetty server, BRL totally blew PHP away. I tried again when PHP4 made it into Debian, and surprisingly saw no significant difference.
BRL's architecture is much like JSP, except BRL may be faster on the first request as it compiles a simpler language with no intermediate Java source. I would expect JSP to perform as well against PHP as BRL did, if not better.
No, I'm referring to Diamond v. Diehr, which reiterated the points made in Benson and previous rulings. I'm aware that the Federal Circuit thumbed its nose at the Supreme Court rulings.
The only distinguishing point in Diehr was that having software (or other non-patentable material) as part of a system does not make the system as a whole non-patentable. You just need novelty in the non-software portion of the system. Also note that a whole section of the opinion was devoted to make sure people didn't try to use "an exercise in drafting" to make a software patent into a non-software patent.
I share the US Supreme Court's opinion that software is not statuatory material for a patent, that all pure-software patents are invalid, and that patents on systems that include software must have novel invention outside the software portion of the system. The justices and I agree that patenting software is equivalent to patenting mathematical algorithms, which is explicitly not allowed.
They'll have long, drawn-out settlement negotiations, allowing more time to sell stock, so that the money's in individual hands, not in the company. When IBM sees there's not much to squeeze out, SCO will likely be able to broker a deal in which they admit no wrongdoing. They can say something like, "Rather than go up against the legal resources of IBM, we felt it was in the company's best interest to settle, even though we did nothing wrong."
MySQL had an edge over PostgreSQL in 1997 when MySQL worked and PostgreSQL was buggy. Bugs got fixed, but MySQL was easier to install, so it continued to gain momentum. I think it's mainly momentum from prior years that keeps MySQL in the spotlight today.
The web site for Eaton Vance got a new look today. Some ASP pages were replaced with PHP. I wish they had used BRL, but they liked that there were published cookbooks for PHP.
Who do you think keeps Franz and Digitool in business? Hobbyists? I don't think so; they'd be using one of the free implementations.
Your "no one in business computing considers using Lisp" comment shows you don't know what you're talking about.
I myself use Scheme in my employment, and it's helped a lot.
I'm writing this from work. We have lots of production projects, and none of them use LDAP yet. At my company, SQL is considered the right level of abstraction; using "raw" SQL is not considered a problem. Also, people want a variety of reports off the data. If you look at the database as merely an "object persistence layer" you won't slice and dice reports nicely. Embrace SQL. It has value.
I don't think I'm misunderstanding. I understand you have a mechanism that destroys the object a variable is bound to when that variable goes out of scope. That's only useful if you aren't putting the object in a data structure or otherwise planning on using the object outside of the block where that variable is in scope. Basically, it's only useful in trivial cases. I'm not saying it's worthless; I can see it has some advantage over explicitly freeing all the objects. It's just not anything near as powerful as garbage collection. To be fair, Bjarne Stroustrup doesn't present it that way; only aster_ken did.
OK, now I understand. Basically he's saying that if you follow a certain discipline, allocated memory will be freed when the function returns. But the same could be said of explicitly freeing at the end of the function, and having goto's at places where you would otherwise return early. The second example bumps it up exactly one level. However, for objects that get passed around between more than two functions, you still need to keep track of what must be freed.
Regarding Scheme performance, check out how bigloo and Stalin are doing in the Bagley language shootout.
There's a bug in your program. Map always returns a list, which is a true value; not what you intended. I think if you had used a macro things would have been clearer. Pardon the lack of indentation; I can't seem to strongarm Slashdot into including it.
(define-syntax all (syntax-rules () ((all pred? arg...) (and (pred? arg)...))))
(define (lispy? str) (string-index str "lisp"))
(define (lisp-fanatic? username body sig) (all lispy? username body sig))
quote: "the CLR integrates all prog. languages"
on
Does C# Measure Up?
·
· Score: 1
The common language runtime comes into play by allowing individual components of specific applications within a company to communicate. Through its standard set of types--self-describing type information (meta data) and common execution environment--the common language runtime integrates all programming languages and allows objects created in one language to be read with equal weight by code written in a different language.
I would be suprised to learn that IL even has the concept of *single* inheritance.
Want to be surprised? Google for clr object system and check out the powerpoint presentation on research.microsoft.com that includes a couple of IL examples. Single inheritance is right there.
Making OO into "low-level" runtime operations is important if you want objects from different languages to interoperate. Try getting multiple-inheritance objects from Eiffel to work in C++, or C++ objects to work in S# (Smalltalk).
If MSFT were really interested in supporting multiple languages, even just multiple OO languages, they would have built-in multiple inheritance support; C# and VB.NET just wouldn't use it. As it is, there's only built-in single inheritance (plus interfaces) support, exactly like with the Java framework. Not surprising. The Java framework is not trying to support multiple languages. The dotnet framework isn't trying either, except in marketing materials.
If you want to define "cross-language" as "languages that fit into this one paradigm", then yes, it's cross-language. You can make any statement true by redefining its terms.
But, just for fun, let's stick to the OO paradigm. Let me share some interesting paragraphs from an Eiffel Page on the subject.
The virtual machine provides a number of mechanisms useful to the implementers of all languages: signal handling, exception handling, security, memory management, garbage collection, debugging support. The last point is particularly interesting for object-oriented languages; although a bit apprehensive at first about the efficiency of the GC process, we were interested to discover that it uses many of the same techniques that we have applied to ISE Eiffel over the years; in particular it moves objects around, as needed to compact memory, and gives excellent performance results.
Not all applications will want to rely on these services. This is where the notion of "managed code" comes in. Code is managed if it relies on the runtime's services, unmanaged otherwise. Managed and unmanaged code can coexist; as noted above, C++ will only let you enjoy the benefits of full managed code if you limit your use of the language to a subset that roughly corresponds to a C#/Java style of programming (no multiple inheritance except from interfaces, no "friends").
You can bring in features like multiple inheritance if you're willing to let the dotnet framework give you nothing. Why implement in the dotnet framework in the first place?
I'm not arguing (1), that the CLR is really only built for C#. I really don't know. It might also have been built for VB.NET. Nor do I particularly care about its support of multi-inheritance or templates.
What I am saying is that one unique feature of Scheme, namely first-class continuations, cannot be done on the CLR without a huge performance hit. Thus the original poster's "subset of C#" description is not far off. You get an alternate syntax, but not alternate concepts.
Where the JVM comes in relates to this comment by you:
Furthermore, the idea that the CLR "does not support multiple languages" is the most ridiculously malinformed statement I have ever heard about.NET, and trust me, I've heard plenty. One of the major objectives, if not the most important, is to bring to prime-time quality Microsoft's idea of supporting many languages on the same framework.
Sun never intended the JVM for anything but Java. People implemented compilers for other languages to target the JVM anyway, with certain restrictions due to the JVM abstraction. Seeing how those exact same restrictions come up when you try to target the CLR belies "Microsoft's idea of supporting many languages on the same framework" as mere marketing hype. Yes, there are many more similarities than differences between the JVM and the CLR. Both are OO virtual machines, and neither was designed with many languages in mind. Prime-time quality? I'll believe it when I see it.
In any case, I still have no idea what any of these paradigm and framework issues have to do with the CLR.
Yes, I noticed.
It's like arguing that Intel architecture really supports only C, and not any other languages.
The Intel architecture lets you do certain low-level things like copy stack frames around. First-class continuations rely on such low-level tricks to be efficient. You can create a higher-level implementation of continuations using the CLR, but it will be terribly slow, and there's no guarantee that language A's high-level implementation will be able to invoke continuations from language B's high-level implementation.
More generally, I'm saying that the CLR provides little, if any, additional language independence compared to the JVM.
I looked at Stroustrup's two examples. It looks like his first example does not involve freeing any memory at all. Am I right? His second example seems to use auto_ptr to assure that an object is freed when the function where it's allocated returns. Is that all it's doing? I would expect the situations where people get memory leaks to be more complex than auto_ptr could handle.
Anyway, he never mentions garbage collection; just easier "explicit" management. (I put "explicit" in quotes, because malloc/free has to manage free blocks, so it's not as manual a process as you might think. For some applications, Boehm's collector is actually faster.)
Languages that are conceptually different from C# have to make compromises to run on the CLR. They aren't quite the same language after that. That's why they get names like Scheme#, etc. The parent post is not as ill-informed as yours is.
The parent post is only ill-informed about Lisp macros. Those are done at compile time, and there's nothing about the CLR that would preclude them. However, the parent post was dead on about Scheme continuations. CLR changes to better support continuations have been "coming soon" for the past couple of years.
Re:SCO is just doing what they need to do
on
SCO Volleys to Red Hat
·
· Score: 4, Insightful
They believe they had code stolen from them.
No, they don't believe that. If they believed that, they'd come forward with proof. All they believe is that they can get some money in the bank before their company folds.
Diamond v. Diehr does support my claim, most specifically in section III., where they reiterate previous decisions that ruled software not patentable. It's true that the exact words "Software is still not statuatory; we haven't changed our minds" do not appear in Diamond v. Diehr, the way they uphold previous decisions obviously implies it.
Most telling is a sentence in section III of the decision. Again and again in their opinion, they explain that the inclusion of nonstatuatory subject matter does not make an otherwise statuatory (i.e. patentable) process as a whole nonstatuatory. But once instead of "nonstatuatory material" they give some examples:
Our earlier opinions lend support to our present conclusion that a claim drawn to subject matter otherwise statutory does not become nonstatutory simply because it uses a mathematical formula, computer program or digital computer.
This sentence is meaningless if computer programs are statuatory. Either computer programs are nonstatuatory, or the court gets a kick out of putting non-sequiturs in its opinions.
Note also that the dissent (who thought the patent invalid), dissented on the basis of whether the non-software part of the invention was novel. The court as a whole agreed that the patentability of the invention hinged on non-software novelty.
Thank you for including that quote about the Alappat decision paving the way for software patents. More people should understand that. Many mistakenly think that Diehr paved the way; it did not.
Slashdot Mirror
Back when I was concerned about whether BRL had decent performance, I did a simple benchmark on a 586 Debian box with Apache/php3 vs Apache/Jserv/BRL. PHP could beat BRL if BRL used Sun's JRE, but BRL beat PHP using IBM's JRE. When I switched from Apache/JServ to a Jetty server, BRL totally blew PHP away. I tried again when PHP4 made it into Debian, and surprisingly saw no significant difference.
BRL's architecture is much like JSP, except BRL may be faster on the first request as it compiles a simpler language with no intermediate Java source. I would expect JSP to perform as well against PHP as BRL did, if not better.
No, I'm referring to Diamond v. Diehr, which reiterated the points made in Benson and previous rulings. I'm aware that the Federal Circuit thumbed its nose at the Supreme Court rulings.
The only distinguishing point in Diehr was that having software (or other non-patentable material) as part of a system does not make the system as a whole non-patentable. You just need novelty in the non-software portion of the system. Also note that a whole section of the opinion was devoted to make sure people didn't try to use "an exercise in drafting" to make a software patent into a non-software patent.
I share the US Supreme Court's opinion that software is not statuatory material for a patent, that all pure-software patents are invalid, and that patents on systems that include software must have novel invention outside the software portion of the system. The justices and I agree that patenting software is equivalent to patenting mathematical algorithms, which is explicitly not allowed.
When and how do you anticipate that things will change such that SCO starts caring whether their statements look like lies?
Funny that you take the "fire-breathing" comment to mean IBM is now looked upon as a paladin. I simply took it that IBM is an awesome foe.
They'll have long, drawn-out settlement negotiations, allowing more time to sell stock, so that the money's in individual hands, not in the company. When IBM sees there's not much to squeeze out, SCO will likely be able to broker a deal in which they admit no wrongdoing. They can say something like, "Rather than go up against the legal resources of IBM, we felt it was in the company's best interest to settle, even though we did nothing wrong."
The GPL will only get a full vetting when it goes to court. SCO will never let this case see a courtroom.
MySQL had an edge over PostgreSQL in 1997 when MySQL worked and PostgreSQL was buggy. Bugs got fixed, but MySQL was easier to install, so it continued to gain momentum. I think it's mainly momentum from prior years that keeps MySQL in the spotlight today.
The web site for Eaton Vance got a new look today. Some ASP pages were replaced with PHP. I wish they had used BRL, but they liked that there were published cookbooks for PHP.
Who do you think keeps Franz and Digitool in business? Hobbyists? I don't think so; they'd be using one of the free implementations. Your "no one in business computing considers using Lisp" comment shows you don't know what you're talking about.
I myself use Scheme in my employment, and it's helped a lot.
I'm writing this from work. We have lots of production projects, and none of them use LDAP yet. At my company, SQL is considered the right level of abstraction; using "raw" SQL is not considered a problem. Also, people want a variety of reports off the data. If you look at the database as merely an "object persistence layer" you won't slice and dice reports nicely. Embrace SQL. It has value.
I don't think I'm misunderstanding. I understand you have a mechanism that destroys the object a variable is bound to when that variable goes out of scope. That's only useful if you aren't putting the object in a data structure or otherwise planning on using the object outside of the block where that variable is in scope. Basically, it's only useful in trivial cases. I'm not saying it's worthless; I can see it has some advantage over explicitly freeing all the objects. It's just not anything near as powerful as garbage collection. To be fair, Bjarne Stroustrup doesn't present it that way; only aster_ken did.
OK, now I understand. Basically he's saying that if you follow a certain discipline, allocated memory will be freed when the function returns. But the same could be said of explicitly freeing at the end of the function, and having goto's at places where you would otherwise return early. The second example bumps it up exactly one level. However, for objects that get passed around between more than two functions, you still need to keep track of what must be freed.
Regarding Scheme performance, check out how bigloo and Stalin are doing in the Bagley language shootout.
Straight from Microsoft's own propaganda:
Want to be surprised? Google for clr object system and check out the powerpoint presentation on research.microsoft.com that includes a couple of IL examples. Single inheritance is right there.
Making OO into "low-level" runtime operations is important if you want objects from different languages to interoperate. Try getting multiple-inheritance objects from Eiffel to work in C++, or C++ objects to work in S# (Smalltalk).
If MSFT were really interested in supporting multiple languages, even just multiple OO languages, they would have built-in multiple inheritance support; C# and VB.NET just wouldn't use it. As it is, there's only built-in single inheritance (plus interfaces) support, exactly like with the Java framework. Not surprising. The Java framework is not trying to support multiple languages. The dotnet framework isn't trying either, except in marketing materials.
If you want to define "cross-language" as "languages that fit into this one paradigm", then yes, it's cross-language. You can make any statement true by redefining its terms.
But, just for fun, let's stick to the OO paradigm. Let me share some interesting paragraphs from an Eiffel Page on the subject.
You can bring in features like multiple inheritance if you're willing to let the dotnet framework give you nothing. Why implement in the dotnet framework in the first place?
I'm not arguing (1), that the CLR is really only built for C#. I really don't know. It might also have been built for VB.NET. Nor do I particularly care about its support of multi-inheritance or templates.
What I am saying is that one unique feature of Scheme, namely first-class continuations, cannot be done on the CLR without a huge performance hit. Thus the original poster's "subset of C#" description is not far off. You get an alternate syntax, but not alternate concepts.
Where the JVM comes in relates to this comment by you:
Sun never intended the JVM for anything but Java. People implemented compilers for other languages to target the JVM anyway, with certain restrictions due to the JVM abstraction. Seeing how those exact same restrictions come up when you try to target the CLR belies "Microsoft's idea of supporting many languages on the same framework" as mere marketing hype. Yes, there are many more similarities than differences between the JVM and the CLR. Both are OO virtual machines, and neither was designed with many languages in mind. Prime-time quality? I'll believe it when I see it.
Yes, I noticed.
The Intel architecture lets you do certain low-level things like copy stack frames around. First-class continuations rely on such low-level tricks to be efficient. You can create a higher-level implementation of continuations using the CLR, but it will be terribly slow, and there's no guarantee that language A's high-level implementation will be able to invoke continuations from language B's high-level implementation.
More generally, I'm saying that the CLR provides little, if any, additional language independence compared to the JVM.
The GPL does not require attribution in their documentation or on their site.
I looked at Stroustrup's two examples. It looks like his first example does not involve freeing any memory at all. Am I right? His second example seems to use auto_ptr to assure that an object is freed when the function where it's allocated returns. Is that all it's doing? I would expect the situations where people get memory leaks to be more complex than auto_ptr could handle.
Anyway, he never mentions garbage collection; just easier "explicit" management. (I put "explicit" in quotes, because malloc/free has to manage free blocks, so it's not as manual a process as you might think. For some applications, Boehm's collector is actually faster.)
Languages that are conceptually different from C# have to make compromises to run on the CLR. They aren't quite the same language after that. That's why they get names like Scheme#, etc. The parent post is not as ill-informed as yours is.
The parent post is only ill-informed about Lisp macros. Those are done at compile time, and there's nothing about the CLR that would preclude them. However, the parent post was dead on about Scheme continuations. CLR changes to better support continuations have been "coming soon" for the past couple of years.
No, they don't believe that. If they believed that, they'd come forward with proof. All they believe is that they can get some money in the bank before their company folds.
Yes, you can patent the algorithm, but that patent is not valid.
Diamond v. Diehr does support my claim, most specifically in section III., where they reiterate previous decisions that ruled software not patentable. It's true that the exact words "Software is still not statuatory; we haven't changed our minds" do not appear in Diamond v. Diehr, the way they uphold previous decisions obviously implies it.
Most telling is a sentence in section III of the decision. Again and again in their opinion, they explain that the inclusion of nonstatuatory subject matter does not make an otherwise statuatory (i.e. patentable) process as a whole nonstatuatory. But once instead of "nonstatuatory material" they give some examples:
This sentence is meaningless if computer programs are statuatory. Either computer programs are nonstatuatory, or the court gets a kick out of putting non-sequiturs in its opinions.
Note also that the dissent (who thought the patent invalid), dissented on the basis of whether the non-software part of the invention was novel. The court as a whole agreed that the patentability of the invention hinged on non-software novelty.
Thank you for including that quote about the Alappat decision paving the way for software patents. More people should understand that. Many mistakenly think that Diehr paved the way; it did not.