Re: back to .Net? lesser of two evils?
On 11/2/2011 3:06 PM, Arne Vajh??j wrote:
On 11/2/2011 10:58 AM, BGB wrote:
On 11/2/2011 12:17 AM, Cindy wrote:
On 02/11/2011 1:35 AM, BGB wrote:
On 11/1/2011 7:18 PM, Arne Vajh??j wrote:
On 10/28/2011 4:29 PM, jebblue wrote:
With Oracle on one side suing Google over Android
and on the other cooing about how many phones
run Java; I'm wondering if it might be worth it
to put my ideological views about Microsoft aside
and consider going back to .Net.
Why should the question whether Google infringed on
Oracle copyright or patents affect your choice of
programming language?
maybe because it asserts that Java is not a free/open technology,
and is
essentially a proprietary product owned by Oracle?...
granted, .NET has the same basic issue (it is owned by MS, ...).
.NET is much worse. Anyone can write a conforming Java implementation
that people can use and anyone else can code for it, without permission
from Oracle. With OpenJDK, there is a complete open source conforming
implementation, in particular. The one restriction I'm aware of is that
you can't actually call it "Java" unless it passes certain tests or else
you're looking at a trademark infringement lawsuit, whereas you could,
say, write a Lisp interpreter and call it C if you wanted to.
yeah. however, one can't really make subsets or add extensions, which is
lame.
You can not make a subset and call it Java. But you can call
it something else.
SUN/Oracle has not sued Google over Android being a subset
or MS over J# being a subset.
fair enough, but generally one thinks of "Java" as the generic name, but
technically this is the brand-name, and there is no good name for
"basically the core Java language but an incomplete/subset implementation".
apparently, some people have used "coffee", but this hasn't really
caught on.
Mono also can't run C++/CLI code last I checked, which sort of screws
over my personal motivation to use it.
It should be able to run pure code. Obviously not mixed code.
yes, but banning mixed code sort of breaks C++/CLI's ability to...
actually work...
even if one compiles the code itself as pure CIL, then Mono rejects it
due to things like "can't load MSVCR80.DLL" or similar.
however, about the only real reason I would have to use it would be
because "C++/CLI is nifty, since I can straddle the border between C#
and plain C and C++ code".
I am technically left better off just using my own VM and language,
since I can at least make most of this stuff work ok without
compromising my ability to run cross-platform (and don't really all that
much need a standardized VM and language for what I am doing).
granted, my language is mostly filling a similar role to Python or Lua
or similar, just without my personal dislike of Python and Lua...
I had an "ARM scare" a while back (I was worried that my reliance on
code-generation and ASM would compromise my ability to easily port my
stuff to ARM), however I was able to address this "adequately" for now
(partly by adding ARM and Thumb support to my assembler, and adding some
amount of "emergency plain-C fallback logic" for cases where I wasn't
going to bother porting the ASM code-generation logic).
I suspect another issue is that, at the VM level, .NET is a good deal
more complicated than the JVM. one can load/run JBC mostly by writing a
reasonably straightforward class-loader and an interpreter for the
bytecode.
similar does not work as easily for MSIL / CIL, as in many respects it
is more complicated, and assumes the use of type-inference by a JIT,
meaning a plain interpreter would also need to use dynamic type-checking
while also faking static-type semantics.
I believe Mono has a portable CIL interpreter.
I think it does.
I am not saying it can't be done, just a naive/"plain" interpreter wont
perform very well (and will be more complicated than its JBC equivalent).
one can write a "less naive interpreter", which could perform better,
but this is a bit more complicated...
basically, the "standard form" of a bytecode interpreter is something like:
while(doStuff)
{
op=*ctx->ip++;
switch(op)
{
execute-opcodes...
}
}
but, such an interpreter will not perform well, given the way types are
handled in CIL (CIL does not declare types with the opcodes, whereas JBC
does).
one would need instead:
while(stillBytecode)
{
op=*ctx->ip++;
switch(op)
{
build-threaded-code...
}
}
....
//execute code (threaded interpreter)
cur=startOp;
while(cur)
cur=cur->fcn(ctx, cur);
however, the creation of such an interpreter is more effort...
granted, yes, with compiler or VM technology in general, one has to be
willing to tolerate a certain level of complexity (and, with both JBC
and CIL, the interpreter is likely to perform a lot better, as with
switch-based interpreter loops, very often the "switch()" header will
come to be the dominant factor in the total execution time, whereas with
the threaded-loop, with each function pointer representing the exact
behavior to be performed, the interpreter will generally run a fair
amount faster).
the main difference it makes for CIL though, is that it allows largely
avoiding the use of run-time type checking, which is one of those things
which can eat lots of time in an interpreter (causing code to easily run
100x or more slower than native...).