I would be very suspicious about such contribution, because most of the remoting code was written by Lluis (for all the high-level channels), Dietmar (for all the low-level remoting bits), Patrik (which filled a lot of the mid-level details).
All I can think of are stubs, which are not really useful.
Those were either Novell/Ximian/Intel employees, and in no case we did disassemble.
For the other pieces like Soap/Remoting, the code was so broken that it could not have possibly been copied/decompiled given how useless it was until we fixed it in various iterations.
I very much doubt your statement, but if it happens to be true, we have records for each contribution going to the day zero of the project and we can track it down.
Well, you are missing the point about anonymous methods. They are just a lot simpler to write and hook up than the equivalent for Java. You need to remember less, you need to type less, and they are effectively closures with variable and state captures like Scheme would do. Anonymous classes in Java are effectively a pre-processor hack: they cant capture or reference local variables nor parameters, they can only reference instance variables of the containing class.
Can everything that anonymous methods do in C# be done with alternative methods in Java? Absolutely. But then again, sendmail's config file format is turing complete, but that does not mean it is pleasant to write applications on top of it. The same applies;-)
Thanks for the pointer on.jar, the rest of the Java criticism still applies.
That being said, Mono and the CLR are language neutral, and we will run all of your Java code in Mono. We are an equal opportunity language runtime. But given the choice, I tend to go with writing my code in C#.
Yes, "Java has a hell more production sites than Mono". This is whats wrong with this argument: if "having more production sites" is the metric to choose a technology over something new then we would still be running code in assembler and Cobol. After all, there were more production systems written in those than in C, C++ or Java when these languages came out.
The problem with patents is that they will cover the concepts, not the implementation.
So the reality is that any modern implementation of anything remotely interesting will infringe in a bogus patent. You write a hundred lines of code and you are infringing someone.
In my opinion, we can fight bad patents or we can move into a safer industry, like selling panties.
But in particular, if you are talking about ASP.NET the question you must ask yourself are:
* Do I use any concepts that exist in the.NET Framework in my code? If so, should I remove the feature?
* Did the concepts in ASP.NET (or any other technology) exist prior to the.NET Framework?
Remember that you must be thinking "concept" and not "implementation", because a patent is much broader than that.
I believe there is very little new under the sun, and that prior art can be found for all the interesting parts of the.NET Framework. If I didnt, I would be selling soap.
You are wrong, Microsoft has not done anything to prevent code from running on Mono.
There is the real problem that we do not implement all the class libraries, specially those that are being phased out like EnterpriseServices and Message Queuing. But then again, those are really marginal tools which were complex to use, so its not really a problem.
The other bit is COM support, which we do not support as there is really no "COM" to talk to in Unix anyways.
* Attributes. * Support for unsafe code. * P/Invoke vs JNI is a fairly big difference. * Operator overloading, which on the.NET Framework is used with good taste.
If comparing C# 2.0 vs Java 1.5:
* Iterators (yield keyword). * Anonymous methods. * Fixed buffers * Generics for value types (Java only has generics for reference types, everything else must be "boxed", the Int vs "int" problem).
Now, from a pure usability standpoint, I like the tiny things like:
* `mono program.exe' runs your program, no need to pass a class name, or a path or setup the cp to run.
* The layout of my files is not constrained to one-file, one-class and the file system hierarchy does not have to match the namespaces I have chosen.
It is "viral" in that if you get that code and learn from it, you can not use it to improve any open source software.
I would very much like to see how Sun has implemented certain optimizations for Java and bring those over to Mono (or to other open source Java VMs, VMs in general, JIT engines, compilers or scripting languages).
The problem is that the license explicitly forbids the use of it for this purpose `direct or indirect commecial (including strategic) gain or advantage'.
Still falls short of usable for the free software/ open source community.
With a country that is going back to the middle ages, this seems only like the tip of the iceberg.
With Bush in office, I expect the next couple of years to be packed with amusement from your witch hunts to your basic alchemy courses taught in schools and maybe some sacrifices made to the gods if the stock market goes up.
Notice that stack-based operations are nothing but a linear representation of a tree.
It is in effect the output that you would get from serializing a tree, so you turn internal compiler representation, like for example the following tree:
(assign var (add 1 2))
into a series of stack operations:
push 1 push 2 add var_address store
You can certainly "interpret" those bytecodes, and for an interpreter it is debatable if there is a performance improvement or not.
But for any self respecting JIT, the above is only an MIR (Medium-Level IR) that must be processed into something else.
The tree is reconstructed from the stack operations (every JIT does that) and then you run your standard optimizations, with register allocation to the target architecture being the last step of a long chain of operations.
The meme of `register byte code will map nicely to hardware' is also rubbish.
For one, the type of the registers in parrot do not map to the underlying hardware types (ints and floats is all cpus can do), and second of all not every CPU has all the registers parrot has.
So if you generate code that uses 32 registers, you would still need to map to 6 registers on Intel.
To make things worse, register allocation is one of the hardest problems in a compiler, and the one that probably has the most impact on the performance of generated code.
So now every compiler author is forced to write a register allocator, only to find out that parrot will throw away all that information and redo its own register allocation.
That is why Medium Level IRs do not use registers, they are too high level to have any real effect.
As for lower-level IRs, most of them assume infinite registers anyways as a simple way of "labeling data".
---
Parrot comes with a system that will let compiler developers not worry about register allocation: you emit some kind of infinite register, and a tool produces the IR registers (which will later be discarded anyways).
A few comments:.NET did exist when Parrot was announced, and more importantly the work to turn.NET into an ECMA standard had started way before this..NET is designed for compiled languages as much as the x86 is designed for compiled languages (in fact the x86 is strongly typed and knows about two types: ints and floats, nothing else).
So anyways, for those who can see further than the end of their noses,.NET provides a lot of sugar for strongly typed OO languages, but it requires a strong effort to be as naive to think that dynamic languages are not supported.
In any case, IronPython has demostrated that.NET can execute dynamic Python code as fast or faster than the Python interpreter itself.
So those two stated reasons for Parrot are rubbish.
On the other hand, its perfectly fine to say `We wanted to do something different' or `we wanted to do our own thing'. Nothing wrong with that.
Miguel.
Limitations of Generics in Java.
on
Java 1.5 vs C#
·
· Score: 3, Interesting
There are some important limitations of generics in Java, which are properly addressed in C#.
For more details, you might want to read:
http://www.artima.com/intv/generics.html
C# still has a few extra niceties like properties, events, delegates, anonymous methods and iterators.
When GCC started, nobody thought that it could match any commercial compilers, but with a strong community and thousand of contributors it matched the best optimizing compilers of its time, it is a continuous race between compilers in general, and there is no end in sight here.
Mono is repeating this story, we are tuning it, improving it constantly and most users can already appreciate a 30% performance boost from Mono 1.0 to Mono 1.1.1 (in only three months of development). We are also investing heavily in high end optimizations (and as I pointed out in a separate thread, we can afford this because of our AOT-compilation mode).
But even if we always were to be slower than.NET, being dog slow has not stopped Java adoption in the past. Being slow in general has not slowed down interpreters like Python and Perl in the past: what mattered was the functionality.
And to some folks.NET is fantastic, and if they can run it in MacOS, S390, SPARC and Linux all the better.
That is your second flaw: that people only care about performance, they dont (but even then, we do, and we want to make Mono rule;-)
Mono is slower than.NET in certain areas, but in some others it is a lot faster. The areas that get the most testing and use from the team are likely to be more tuned than the Microsoft counterparts (this is a nice benefit of using Mono to develop itself: we actually use it to maintain our own compilers, editors, and day-to day tools).
You are mistaken about the JIT nature of Mono, Mono has an optimizing JIT engine with pluggable optimizations. You can control the level of optimizations using the -O flag to the runtime, and we support Ahead-of-Time compilation as well which means that you can turn on all the obscene optimizations (those who might be too expensive to do at JIT time, and that historically JITs had to implement by doing dynamic recompilation). In our case, we turn on all the expensive optimizations, and run the code natively, without a dynamic translation (like a JIT would do).
Anyways, Mono has a dedicated staff to support and maintain it (16 developers reporting to me, plus other contributors from Novell in other areas of the VM) in addition to the 250 accounts for external contributors that continue to improve Mono.
We are not in a quest to compete with Java, we bring something different to the table (and in fact, we even support Java in Mono;-), but your statements are incorrect.
Novell today has a large install base for groupware applications (Groupwise) which today Evolution 2.0 supports as well as a light and fast older groupware called NetMail.
On the higher level stack there is Extend, a product to build relatively large and complex applications. This last one runs on top of J2EE.
I do not hate Microsoft, but I think that they will eventually open source some interesting pieces of software. The pieces are already in movement.
Microsoft is like any other corporation, they have to do what is best for their shareholders. They have had a pretty good ride but Linux and open source have changed the plane, so they will likely have to transform in the future in a different kind of company.
In either case, working for Microsoft is not the end of the world. I just happen to be a lot happier working for Novell doing open source software and working with many talented developers from the Novell background, the SUSE background and Ximian. An opportunity in a lifetime to reshape this industry.
Just wanted to point out that the inflamatory comments that are being made in my name are someone else's idea of fun. Some guy decided to squatter the login `Miguel de Icaza'.
Slashdot Mirror
Hello,
Ah, those are the pieces that we had to redo,
they were an interesting first approach, but they
could not be used in production.
For the few pieces remain, they are mostly
property getter/setters, namespace declarations
and a few comments.
Miguel.
Thanks for looking into this.
We are auditing the code, and the code that we have
in that area was either completely redone, or what
has not been redone is fairly broken.
I would be surprised if the implementation is
copied.
But if they decompiled to learn how it worked, we
will remove the code anyways.
Miguel.
The official Mono position can be found on our FAQ,
there is nothing to report.
Novell was doing a review of the patent situation,
and the review detemined that our existing policy
on the FAQ was all we could do.
Miguel.
I would be very suspicious about such contribution,
because most of the remoting code was written by
Lluis (for all the high-level channels), Dietmar
(for all the low-level remoting bits), Patrik
(which filled a lot of the mid-level details).
All I can think of are stubs, which are not really
useful.
Those were either Novell/Ximian/Intel employees,
and in no case we did disassemble.
For the other pieces like Soap/Remoting, the code
was so broken that it could not have possibly
been copied/decompiled given how useless it was
until we fixed it in various iterations.
I very much doubt your statement, but if it
happens to be true, we have records for each
contribution going to the day zero of the
project and we can track it down.
Miguel.
Hello,
;-)
.jar, the rest of
Well, you are missing the point about anonymous
methods. They are just a lot simpler to write and
hook up than the equivalent for Java. You need to
remember less, you need to type less, and they are
effectively closures with variable and state
captures like Scheme would do. Anonymous classes
in Java are effectively a pre-processor hack:
they cant capture or reference local variables
nor parameters, they can only reference instance
variables of the containing class.
Can everything that anonymous methods do in
C# be done with alternative methods in Java?
Absolutely. But then again, sendmail's config
file format is turing complete, but that does not
mean it is pleasant to write applications on top
of it. The same applies
Thanks for the pointer on
the Java criticism still applies.
That being said, Mono and the CLR are language
neutral, and we will run all of your Java code
in Mono. We are an equal opportunity language
runtime. But given the choice, I tend to go with
writing my code in C#.
The infrastructure itself is not, the existing
API is.
The new API is part of Indigo.
Hey,
Small correction: C# and the CLI have both
been approved as ISO standards: ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI) and ISO/IEC 23272 (CLI TR).
Hello,
Yes, "Java has a hell more production sites
than Mono". This is whats wrong with this
argument: if "having more production sites" is the
metric to choose a technology over something new
then we would still be running code in assembler
and Cobol. After all, there were more production
systems written in those than in C, C++ or Java
when these languages came out.
Love,
Miguel.
The problem with patents is that they will cover
.NET
.NET Framework?
.NET Framework. If I
the concepts, not the implementation.
So the reality is that any modern implementation of
anything remotely interesting will infringe in
a bogus patent. You write a hundred lines of code
and you are infringing someone.
In my opinion, we can fight bad patents or we can
move into a safer industry, like selling panties.
But in particular, if you are talking about ASP.NET
the question you must ask yourself are:
* Do I use any concepts that exist in the
Framework in my code? If so, should I remove the
feature?
* Did the concepts in ASP.NET (or any other
technology) exist prior to the
Remember that you must be thinking "concept" and
not "implementation", because a patent is much
broader than that.
I believe there is very little new under the sun,
and that prior art can be found for all the
interesting parts of the
didnt, I would be selling soap.
Miguel.
Hello,
You are wrong, Microsoft has not done anything
to prevent code from running on Mono.
There is the real problem that we do not
implement all the class libraries, specially those
that are being phased out like EnterpriseServices
and Message Queuing. But then again, those are
really marginal tools which were complex to use,
so its not really a problem.
The other bit is COM support, which we do not
support as there is really no "COM" to talk to
in Unix anyways.
Miguel.
If comparing C# 1.0 vs Java 1.4:
.NET Framework is used with good taste.
* Attributes.
* Support for unsafe code.
* P/Invoke vs JNI is a fairly big difference.
* Operator overloading, which on the
If comparing C# 2.0 vs Java 1.5:
* Iterators (yield keyword).
* Anonymous methods.
* Fixed buffers
* Generics for value types (Java only has generics
for reference types, everything else must be
"boxed", the Int vs "int" problem).
Now, from a pure usability standpoint, I like
the tiny things like:
* `mono program.exe' runs your program, no need to
pass a class name, or a path or setup the cp to
run.
* The layout of my files is not constrained to
one-file, one-class and the file system hierarchy
does not have to match the namespaces I have
chosen.
Miguel.
Gtk# on Windows uses the UXTheme API, which will
make Gtk+ look like every other app on the system.
The feel in Gtk+/Win32 is already emulating the
host OS, so you get both look and feel.
And that is why that license stinks.
It is "viral" in that if you get that code and
learn from it, you can not use it to improve
any open source software.
I would very much like to see how Sun has
implemented certain optimizations for Java and
bring those over to Mono (or to other open source
Java VMs, VMs in general, JIT engines, compilers
or scripting languages).
The problem is that the license explicitly
forbids the use of it for this purpose `direct
or indirect commecial (including strategic) gain
or advantage'.
Still falls short of usable for the free software/
open source community.
Miguel.
With a country that is going back to the middle
ages, this seems only like the tip of the
iceberg.
With Bush in office, I expect the next couple of
years to be packed with amusement from your witch
hunts to your basic alchemy courses taught in
schools and maybe some sacrifices made to the
gods if the stock market goes up.
miguel.
Notice that stack-based operations are nothing
but a linear representation of a tree.
It is in effect the output that you would get from
serializing a tree, so you turn internal compiler
representation, like for example the following
tree:
(assign var (add 1 2))
into a series of stack operations:
push 1
push 2
add
var_address
store
You can certainly "interpret" those bytecodes,
and for an interpreter it is debatable if there
is a performance improvement or not.
But for any self respecting JIT, the above is
only an MIR (Medium-Level IR) that must be
processed into something else.
The tree is reconstructed from the stack
operations (every JIT does that) and then you run
your standard optimizations, with register
allocation to the target architecture being the
last step of a long chain of operations.
The meme of `register byte code will map nicely
to hardware' is also rubbish.
For one, the type of the registers in parrot do
not map to the underlying hardware types (ints
and floats is all cpus can do), and second of all
not every CPU has all the registers parrot has.
So if you generate code that uses 32 registers,
you would still need to map to 6 registers on
Intel.
To make things worse, register allocation is
one of the hardest problems in a compiler, and
the one that probably has the most impact on the
performance of generated code.
So now every compiler author is forced to write
a register allocator, only to find out that
parrot will throw away all that information and
redo its own register allocation.
That is why Medium Level IRs do not use registers,
they are too high level to have any real effect.
As for lower-level IRs, most of them assume
infinite registers anyways as a simple way of
"labeling data".
---
Parrot comes with a system that will let
compiler developers not worry about register
allocation: you emit some kind of infinite
register, and a tool produces the IR registers
(which will later be discarded anyways).
Miguel.
A few comments: .NET did exist when Parrot was announced, and more .NET into an ECMA .NET is designed for compiled languages as much
.NET provides a lot of
.NET can execute dynamic Python code as fast or
importantly the work to turn
standard had started way before this.
as the x86 is designed for compiled languages
(in fact the x86 is strongly typed and knows about
two types: ints and floats, nothing else).
So anyways, for those who can see further than
the end of their noses,
sugar for strongly typed OO languages, but it
requires a strong effort to be as naive to think
that dynamic languages are not supported.
In any case, IronPython has demostrated that
faster than the Python interpreter itself.
So those two stated reasons for Parrot are rubbish.
On the other hand, its perfectly fine to say
`We wanted to do something different' or `we
wanted to do our own thing'. Nothing wrong with
that.
Miguel.
There are some important limitations of generics in
Java, which are properly addressed in C#.
For more details, you might want to read:
http://www.artima.com/intv/generics.html
C# still has a few extra niceties like properties,
events, delegates, anonymous methods and iterators.
Miguel.
Your argument has a few flaws, let me explain.
.NET, being dog slow has not stopped Java
.NET is fantastic, and if they
;-)
When GCC started, nobody thought that it could
match any commercial compilers, but with a strong
community and thousand of contributors it matched
the best optimizing compilers of its time, it is
a continuous race between compilers in general,
and there is no end in sight here.
Mono is repeating this story, we are tuning it,
improving it constantly and most users can
already appreciate a 30% performance boost from
Mono 1.0 to Mono 1.1.1 (in only three months
of development). We are also investing heavily
in high end optimizations (and as I pointed out
in a separate thread, we can afford this because
of our AOT-compilation mode).
But even if we always were to be slower than
adoption in the past. Being slow in general
has not slowed down interpreters like Python and
Perl in the past: what mattered was the
functionality.
And to some folks
can run it in MacOS, S390, SPARC and Linux all
the better.
That is your second flaw: that people only care
about performance, they dont (but even then,
we do, and we want to make Mono rule
Love,
Miguel
Mono is slower than .NET in certain areas, but in
;-), but your
some others it is a lot faster. The areas that
get the most testing and use from the team are
likely to be more tuned than the Microsoft
counterparts (this is a nice benefit of using
Mono to develop itself: we actually use it to
maintain our own compilers, editors, and day-to
day tools).
You are mistaken about the JIT nature of Mono,
Mono has an optimizing JIT engine with pluggable
optimizations. You can control the level of
optimizations using the -O flag to the runtime,
and we support Ahead-of-Time compilation as well
which means that you can turn on all the obscene
optimizations (those who might be too expensive
to do at JIT time, and that historically JITs
had to implement by doing dynamic recompilation).
In our case, we turn on all the expensive
optimizations, and run the code natively, without
a dynamic translation (like a JIT would do).
Anyways, Mono has a dedicated staff to support
and maintain it (16 developers reporting to me,
plus other contributors from Novell in other
areas of the VM) in addition to the 250 accounts
for external contributors that continue to
improve Mono.
We are not in a quest to compete with Java, we
bring something different to the table (and in
fact, we even support Java in Mono
statements are incorrect.
Miguel.
Novell today has a large install base for groupware
applications (Groupwise) which today Evolution 2.0
supports as well as a light and fast older groupware
called NetMail.
On the higher level stack there is Extend, a
product to build relatively large and complex
applications. This last one runs on top of
J2EE.
Miguel
I do not hate Microsoft, but I think that they will
eventually open source some interesting pieces of
software. The pieces are already in movement.
Microsoft is like any other corporation, they have
to do what is best for their shareholders. They
have had a pretty good ride but Linux and open
source have changed the plane, so they will
likely have to transform in the future in a different
kind of company.
In either case, working for Microsoft is not the
end of the world. I just happen to be a lot
happier working for Novell doing open source
software and working with many talented developers
from the Novell background, the SUSE background
and Ximian. An opportunity in a lifetime to
reshape this industry.
Miguel.
Hey guys,
Just wanted to point out that the inflamatory
comments that are being made in my name are someone
else's idea of fun. Some guy decided to squatter
the login `Miguel de Icaza'.
Miguel.
Mono 1.0.1 has a new Windows installer that gets
you Gtk# working by default, it is no longer a
separate compilation.
Thanks to Paco and Gonzalo for making this
happen.
Did you bother filing a bug report in
bugzilla.ximian.com?
Filing bug reports on Slashdot (without the
information needed, mind you) wont get them
fixed.
Filing them on Bugzilla will.