Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: back to .Net? lesser of two evils? Date: Thu, 03 Nov 2011 00:01:33 -0700 Organization: albasani.net Lines: 157 Message-ID: References: <4eb0a862$0$294$14726298@news.sunsite.dk> <4eb1bef4$0$286$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.albasani.net J8VwKD/zD73B3tjSnTNS1AEQ4FPCw0VHNd/Gnh5JnwmdMCLH3jVDyenV86Ag6gJat1UIXI3g0pHSP3Cl6mzLnxe44dEzvTgY6tvHfeb65kCPpAgJv/zTq3Q5KJyoGBqm NNTP-Posting-Date: Thu, 3 Nov 2011 07:01:54 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="+34f/bXaKyvYiyqLlBcyYii4mvrObI2ChUqnrruHt+iqwIUwnhIv/qppa/U9OGLxNIZtLZjrXPGLtVsclQhItX93PhPBiT6yLDGj5hddMvqfg1HjQcK80VfIiAXGqU0o"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <4eb1bef4$0$286$14726298@news.sunsite.dk> Cancel-Lock: sha1:3RPch30ScouNAKn5jXv8xaetjtg= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9429 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...).