We all know that Java isn't the most elegant language, but for many other reasons it still is an attractive platform. Arises the question: Is there a nice language for Java Virtual Machine?
Yes, I'm aware of JRuby and Jython, but the whole idea of mixing two languages just seems a little silly to me. Nevertheless, I would like to hear about your experience with these two languages.
Then there is Groovy. It looks kinda nice, but I can't really understand what exactly it improves over Java. OK, so dynamic typing, closures and for some reason they rewrote few libraries.. that's it? Has anyone seriously used this? Your thoughts?
Why is that there are more and superficially better languages for .NET? Am I misunderstanding something, isn't JVM equal to CLI? I'm trying to decide between Java with Groovy and Mono with Boo.
Java sucks.
http://clojure.org/
Agreed with >>2
Clojure is pretty nice. It has a lot of reader macros which makes learning it harder than most lisps (about as hard as other languages).
The JVM is roughly the same as the IL+CLI, but is generally faster and better tested simply because it's older and more widely deployed. The Java library pool is (obviously) much larger than the .NET library pool, and Clojure provides access to it.
>>1
MS added a bunch of alternative syntaxes for C#. CLI is microsoft's imitation of the JVM.
Use SISC, Kawa or ABCL. Maybe Scala. Clojure is badly designed IMHO.
Scala is crap.
ABCL is slow, and there are better CLs.
SISC and Kawa are pretty good, but it's hard to access Java from SISC and Kawa isn't feature complete.
What exactly don't you like about Clojure?
I mean, I know what I don't like about it, but a lot of the strangeness seems deliberate, and not a function of the author not understanding lisp very well (unlike crappolisps like newlisp), so I'd hesitate to call it badly designed...
ABCL is slow, and there are better CLs
What exactly don't you like about Clojure?
> > ABCL is slow, and there are better CLs
> On the JVM?
Good point.
> empty sequence, nil and false. These are all distinct, with nil used for most things (end of sequence, error/null value).
nil and false are logical false in Clojure, however. The fact that (false? nil) is false is a minor issue in my mind. Clojure is in this situation because Java's in this situation, and it would be hard (SISC-hard) to use some Java libs without this.
However (= (if false "foo" bar") (if nil "foo" "bar")) is at least an improvement over Scheme's situation...
> No way to differentiate concrete types. In a way it's nice that you can use the same operations on a list, a vector, a lazy list etc, but there are important differences between them.
You can use (. [] getClass) and (. () getClass) to differentiate trivially. You can even (. (iterate inc 0) getClass) -- do you need some other kind of differentiation?
Does anybody know of any comparisons or benchmarks between Scala and Clojure? I'd like to write something with JOGL, but there's simply no way I'm going to use Java as the primary language.
I'm currently inclined towards Clojure, since I prefer simple and dynamically-typed languages, but it's still very young. Scala has been around for a while.
Clojure has slime support...
Shut up you Lisp fags, you.
The difference between Java and .Net.
Both do have a virtual machine. But the work differently. Both were made with portability in mind. The .Net CLI is a published standard and has been since release. The .Net CRR is the Windows implementation of the CLI.
Java code is compiled in to bytecode. The JVM's JIT then compiles that to native code on the fly.
.Net code is compiled in to the Intermediate Language (IL). For desktop apps, the IL is completley compiled to a native binary and then run. Optionally, you can just compile to native binary from Visual Studio. In ASP.Net it uses JIT.
The difference here is that to precompile Java to a native binary, you need to use some other compiler or a JVM that does that. I could be wrong, but IBM makes the only JVM that precompiled binaries but it costs money. There are many free Java native binary compilers though.
IL is an ASM like language. Bytecode by itself is not really a language.
Java was created with only compiling Java language in mind. The Java compilers doesn't provide a way of encoding type-unsafe features such as pointers, tagged pointers (pointers that hold type info with the address), unsafe type conversion etc. Also it does not allow compilers to take address of local variables; hence it is not possible to implement byref arguments directly. So that makes using other languages with it difficult and some are impossible.
.Net was created with multiple languages in mind. That is why there are over 30 languages on it right now, include the MS implementation of the Java language called J#.
The CRL also supports versioning and support for user defined metadata. The JVM does not.
The Java aims to be backwards compatible, .Net does not. When you install the latest .Net framework, all previous version get installed too (so if you have .NEt 3.5 installed you will have no problem running .Net 1.1 code). This has lead to some interesting things. Features are added more quickly to .Net and with better performance over Java. Such is the case with generics. When Java encounters a generic it actually removes the type (for backwards compatibility), incuring extra cast instructions on every access. .Net compiles the method and loads it once for reference types. It them maintains a a typed variable table for each instance. Value types each get loaded separately for each instance.
Sun has been trying to implement dynamic languages in to Java. MS has already done so. It is possible to call python code from C#, have that python code emit and compile some JavaScript code that calls a method from a VB.Net library.
Also, you get Visual Studio to work with .Net which is an amazing IDE (with not so neutered free versions available). There is a lot of value to using 1 debugger to debug VB.Net and C# code on the server side while debugging JavaScript on the client side all at the same time.
Java also has terrible naming conventions in its libraries. Something as simple as a button is named JButton. JButton as opposed to what? A button is a button, any distinction should be in the namespace. Java has already switched their standard UI widget toolkit once. Will the next button be JJButton? J2Button?
> I could be wrong, but IBM makes the only JVM that precompiled binaries but it costs money
You're wrong. GCJ makes "native" binaries and dlls.
> Sun has been trying to implement dynamic languages in to Java. MS has already done so.
Sun has been trying to implement dynamic dispatch. There have been dynamic languages on the JVM for a very long time. This very thread talked about a bunch of them.
> Both do have a virtual machine. But the work differently
No, they work about the same. Java's is faster: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&lang2=javaxx
> This has lead to some interesting things. Features are added more quickly to .Net and with better performance over Java
No they haven't. You are confusing the runtime with the virtual machine. The Java libraries that exist are simply massive and positively dwarf libraries written for .NET- even if you count each .NET version as a separate library.
> IL is an ASM like language. Bytecode by itself is not really a language.
Rubbish. IL is a bytecode, just like JVM's bytecode. There exist chips that run JVM bytecode directly. Bytecode isn't necessarily a bad thing, but it means that there aren't any instruction schedules, and that the semantics will be identical to a switch table.
> The CRL also supports versioning and support for user defined metadata. The JVM does not.
Yes it does. It's called META-INF/
> Java also has terrible naming conventions in its libraries.
Says you. You haven't demonstrated yourself to be expert enough in this field for that to be worthwhile however. JButton is called JButton because AWT's button is called Button.
> For desktop apps, the IL is completley compiled to a native binary and then run
No it doesn't. You're confusing us with star trek again.
> doesn't provide a way of encoding type-unsafe features such as pointers, tagged pointers (pointers that hold type info with the address), unsafe type conversion
That'd make security and efficient garbage collection difficult.
>>12
I'm surprised Mono performs that well. The JVM is on the VM cutting-edge.
>You're wrong. GCJ makes "native" binaries and dlls.
You are wrong. It is not a JVM. It is one of the many Java compilers I already mentioned. You didn't really get the distinction I was driving at there. The IBM JVM I refer to works very differently.
>There have been dynamic languages on the JVM for a very long time. ...
Again you don't quite get what I am driving at. Read this article: http://www.infoq.com/news/2007/05/java-dlr
>No, they work about the same. Java's is faster:
So you didn't really understand the concepts I pointed out that the CLR implements that the JVM does not. Because architecturally they are huge differences.
Also, comparing the performance of Mono to a JVM is an awful comparison. Mono at the moment doesn't support the .Net framework from 3 years ago and it doesn't fully implement the framework it targets.
>No they haven't. You are confusing the runtime with the virtual machine.
No I am not. The CLR between framework version can be different (and is in most versions) and the libraries are too. As in the example of generics. The CLR was modified to support them properly. Libraries were added to support them and the internals of many libraries were modified to use them.
>Rubbish. IL is a bytecode, just like JVM's bytecode
.Net languages are implicitly tied into the IL common language runtime and is run as just-in-time (JIT) compiled bytecodes or compiled entirely into native code. Java code runs as Java Virtual Machine (VT) bytecodes that are either interpreted in the VM or JIT compiled, or can be compiled entirely into native code.
See the distinction?
>Yes it does. It's called META-INF/
This is more like what I am talking about there.
http://msdn.microsoft.com/en-us/magazine/bb985026.aspx
>Says you. You haven't demonstrated yourself to be expert enough in this field for that to be worthwhile however. JButton is called JButton because AWT's button is called Button.
I do know that. I am enough of an "expert" to understand namespaces.
>That'd make security and efficient garbage collection difficult
Depends on a lot of things. Some languages (Managed C++, C# and a couple others) can run "unsafe" code which is not managed by the runtime so there isn't a GC etc. But for implementing languages it allows the implementor to implement a managed language on the framework.
>I'm surprised Mono performs that well. The JVM is on the VM cutting-edge.
It seems like in the real world that the JVM hogging all that memory would slow it down after a while. But it really doesn't surprise me that they went for efficient resource use over speed optimizations.
> You are wrong. It (gcj) is not a JVM.
> I could be wrong, but IBM makes the only JVM that precompiled binaries but it costs money.
So you're arguing that you're right because because gcj isn't also a virtual machine?
> Again you don't quite get what I am driving at (the DLR)
I'm aware of the DLR. I'm replying to this:
> Sun has been trying to implement dynamic languages in to Java. MS has already done so. It is possible to call python code from C#, have that python code emit and compile some JavaScript code that calls a method from a VB.Net library.
It's long since been possible to call some Jython code from Java that invokes javascript using Rhino.
The feature that SUN has been toying with implementing is the best method of doing dynamic dispatch. Breaking compatability with Java chips and existing Java virtual machines won't be accepted- the relatively low volume of .NET developers demonstrates this.
> Also, comparing the performance of Mono to a JVM is an awful comparison.
It's a realistic comparison. .NET will only give somewhat-acceptable performance on one particular platform, while there are plenty of great Java implementations. That's (of course), all you can really compare: implementations.
I've seen JVM v. MS.NET benchmarks that go both ways, so comparing the ideal scenario seemed less fair to me.
> No I am not. The CLR between framework version can be different (and is in most versions) and the libraries are too. As in the example of generics. The CLR was modified to support them properly. Libraries were added to support them and the internals of many libraries were modified to use them.
If you replace .NET's entire stack, and call that "versioning", then you're correct, but then you've got a .NET that's only a few years old- it can't call functions compiled for older targets, and older code may not compile on newer versions. It's a lose-lose scenario.
Meanwhile, I've got .class files over a decade old that still can be used with new code.
In this case, the virtual machine is what got modified.
> IL is an ASM like language. Bytecode by itself is not really a language.
> .Net languages are implicitly tied into the IL common language runtime and is run as just-in-time (JIT) compiled bytecodes or compiled entirely into native code. Java code runs as Java Virtual Machine (VT) bytecodes that are either interpreted in the VM or JIT compiled, or can be compiled entirely into native code.
>
> See the distinction?
I see windmills.
> I am enough of an "expert" to understand namespaces.
Clearly not. Namespaces solve a non-problem. Calling them JButton or swing.Button doesn't matter much to most people- and the former is shorter.
> Depends on a lot of things. Some languages (Managed C++, C# and a couple others) can run "unsafe" code which is not managed by the runtime so there isn't a GC etc.
JNI.
> It seems like in the real world that the JVM hogging all that memory would slow it down after a while. But it really doesn't surprise me that they went for efficient resource use over speed optimizations.
You'd think that if you weren't aware of how state-of-the-art virtual machines work.
ID:QE2i++lf doesn't know what they're talking about.
>So you're arguing that you're right because because gcj isn't also a virtual machine?
did you understand the statement
>IBM makes the only JVM that precompiled binaries
>It's long since been possible to call some Jython code from Java that invokes javascript using Rhino.
So I suppose you know better than Sun. Sun's Da Vinci Machine project is worthless to you as you can already do that on Java. Who knew? Not Sun of course.
I suppose that you also know more than the guy who implemented Jython, Jim Hugunin. I wonder if he knows a thing or 2 about Jython and IronPython on the .Net DLR? Oh, he initially created IronPython too. Maybe he coule explain a basic core concept with simple to read diagrams.
http://blogs.msdn.com/hugunin/archive/2007/05/02/the-one-true-object-part-1.aspx
Oh good he did.
Python is a first class language in .Net. Jython is tacked on and wrapped up.
I hope you can see the difference. And I hope you can see that Sun has a project to tackle this functionality.
>the relatively low volume of .NET developers demonstrates this.
According to what standard? Java is popular and has been around longer than .Net so it stands to reason there would be more developers. You could always look at this:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Ouch, Java is on a steady downward trend. C# and VB are on an upward trend. I do hate how VB.Net is lumped in with Visual Basic but hey, its a lot better than some baseless speculation on your part.
>I've seen JVM v. MS.NET benchmarks that go both ways, so comparing the ideal scenario seemed less fair to me.
I too have seen that. But it would be fair to compare complete implementations, and current ones.
Holy fuck though, Mono did release their .Net 2.0 version recently. Still not complete but I am going to have to try it out. Maybe Novell did do something good for once.
>but then you've got a .NET that's only a few years old- it can't call functions compiled for older targets, and older code may not compile on newer versions
That is true in some cases but not all. Each version is fairly backwards compatible, but not 100%. But it comes with benefits. When 2.0 added generics, the collection types in the library were more performant than the old way of inheriting from a base collection of object and casting. Much more. In Java, it doesn't matter from a performance standpoint because casting happens either way.
>Clearly not. Namespaces solve a non-problem.
.Net has a button class for win form apps and a button class for asp.net apps. I know the difference becuase they are in a different namespace. There is no logical reason to cal it WebButton or ASPButton when then name should always describe exactly what it is, a button.
>You'd think that if you weren't aware of how state-of-the-art virtual machines work.
I would think the CG should be doing a better job.
> You are wrong. It (gcj) is not a JVM.
libgcj is a JVM. It executes java bytecode.
> I hope you can see the difference. And I hope you can see that Sun has a project to tackle this functionality.
You're an idiot. >>12 already pointed this out.
> But it would be fair to compare complete implementations, and current ones.
You're wrong. If Java and .NET are about the same in the best case, but Java is much better than .NET in the worst case, then comparing the worst case is how you explore that. However, as you've demonstrated, you're an idiot, so I shouldn't expect you to know this.
> Net has a button class for win form apps and a button class for asp.net apps. I know the difference becuase they are in a different namespace. There is no logical reason to cal it WebButton or ASPButton when then name should always describe exactly what it is, a button.
You're a fucking knob if you need namespaces to tell the difference between web applications and desktop applications.
There's no value for an application to have equal access to both, and a significant cost: Web applications are built very differently than desktop applications. Meanwhile, because Swing is built on AWT, implementing new Swing objects requires access to AWT. Implementing a new kind of JButton by using a namespace accessor would make the implementation more complicated.
> I would think the CG should be doing a better job.
CG?
>>19
I think he meant GC, as in garbage collection. And of course he's talking out of his ass again.
> It seems like in the real world that the JVM hogging all that memory would slow it down after a while. But it really doesn't surprise me that they went for efficient resource use over speed optimizations.
Bits don't rot: Using memory doesn't make things go slower "after a while".
>libgcj is a JVM. It executes java bytecode.
Well so it is. But it does JIT just like every other JVM.
>You're an idiot. >>12 already pointed this out.
Your inability to understand what a first class language is, and that Sun's project is to allow the ability (since none exists) to make dynamic languages first class languages in JVM does not make me an idiot. Classically that would be the other way around.
>You're wrong. If Java and .NET are about the same in the best case, but Java is much better than .NET in the worst case, then comparing the worst case is how you explore that.
The idiocy continues. To compare 2 implementations they should be equal. This situation is like comparing Opera 5 Beta to FireFox 3.03 final. Your best case worst case shit is stupid. Its comparing a best case for Java against a worst case for .Net. As stated before, the benchmarks for the best case for both go both ways between Java and .Net. Do you have some 80% finished JVM from 3 years ago to compare Mono to? That would at least be fair. (but even if you did, that would be an exercise in stupidity)
When Novell gets Mono to a more recent version that is 100% feature complete then maybe a mature JVM can be compared to Mono.
>You're a fucking knob if you need namespaces to tell the difference between web applications and desktop applications.
HAHAHAHAHA, you honestly have absolutely no fucking clue about what you are talking about.
>There's no value for an application to have equal access to both
HAHAHAHAA, just right off the top of my head I can think of one very practical scenario where it is a case that an application made for a desktop needs access to web libraries. How about a fucking webserver. Visual Studio comes with a simple websever for debugging written in .Net that uses both desktop and web libraries to execute and sever asp.net pages. The desktop library references are for the control interface. The web ones are to, you know, actually render the fucking pages.
Or what about consuming a webservice. A desktop and a web app will make the calls in the same way. There is no practical value in making a distinction in the library calls. Because its a web service it belongs in the web namepsace.
Dude, you seriously need to give up programming.
>Bits don't rot: Using memory doesn't make things go slower "after a while".
HAHAHA, wow. Lets go over some basics here. Computers have limited memory and processor resources. No computer is unlimited in this respect in any practical way.
Very simply, the more memory you use, the more likely it is that parts of that memory are going to be placed in virtual memory (paged to disk). Accessing virtual memory is many fold slower than accessing the primary memory.
So "after a while" of allocating memory, if there isn't much in the way of free memory (as there wouldn't be if a program is allocating more memory which is something they tend to do) some of that memory is going virtual and therefore slowing down performance.
That is very basic stuff.
Java and .Net use a Garbage Collector to remove unused items from memory. This can be a very advanced topic, especially for you, so I will keep it as simple as possible. When a chunk of memory is no longer used by one of these apps, it is not freed right away for reasons beyond you. It will eventually be freed by the GC. If the GC isn't freeing up unused memory, there is less space in the primary memory. Do you understand the implications of this. They were discussed a little bit ago.
Fuck you guys are stupid. At least the first guy wasn't a total fucking waste of existence.
Never mind. You're right. You're smarter than Sun and Microsoft combined. I bow to your smartness. Despite the fact you've never written a garbage collector, or a vmm allocator for an operating system, you simply ejaculate expertise. I shouldn't argue using facts or reasoning or anything, because you simply decide what is right.
When you said Java can't do dynamic languages, I don't know why we just didn't take your word at it.
When you said Java can't compile to executables, I don't know why I immediately thought of a few different ways to do it.
And when you said the relationship between asp buttons and winforms buttons were the same as the relationship between swing and awt, well I guess I did it wrong. I just have simply implemented JButton as Response.write("<INPUT TYPE=BUTTON");
>Never mind. You're right.
Of course.
>You're smarter than Sun and Microsoft combined.
Never said I was. But thank you for thinking that. I don't think that is true though.
> I shouldn't argue using facts or reasoning or anything, because you simply decide what is right.
So far you have not. I have posted a fuck ton of links (relatively) from experts to back up what I say. You have posted 0 sources, expert or not.
>When you said Java can't do dynamic languages, I don't know why we just didn't take your word at it.
That isn't exactly what I said and you can take the Jython's original authors word for it. I posted a link where he talked about how dynamic languages are not first class languages on the JVM but they are on the CLI. You posted nothing expect something everyone already knows; that you can tack on and wrap up other languages to the JVM. They are not first class. As has been explained by me and a fucking expert on the subject of dynamic languages on both frameworks.
I mean how fucking simple is it that Jython and IronPython were started by the same guy and he wrote articles detailing the differences.
>When you said Java can't compile to executable, I don't know why I immediately thought of a few different ways to do it.
And that too is not what I said at fucking all, any of the times I explained it. I assumed some understanding of virtual machines and their execution environments. I expected to much.
>And when you said the relationship between asp buttons and winforms buttons were the same as the relationship between swing and awt
And of course I didn't say that either. I said their only relationship is that they are buttons and should be named as such. This is a reasonable thing implemented correctly in other libraries. And what will they call the successor to JButton. JEXTREMEButton I hope.
See, your main problem is with reading comprehension. You seem to not understand some of the words and their context. You also seem to be adverse to reading the articles by experts that I have provided.
Your inability to read and understand isn't really my concern though. I do hope you work on that though. Here is a tip. If you don't understand what I say, read the article I posted. If you still don't understand research yourself. If you still don't understand STFU because you look stupid.
> That isn't exactly what I said
> Sun has been trying to implement dynamic languages in to Java. MS has already done so. It is possible to call python code from C#, have that python code emit and compile some JavaScript code that calls a method from a VB.Net library.
> I didn't say that either.
> .Net has a button class for win form apps and a button class for asp.net apps. I know the difference becuase they are in a different namespace
> that too is not what I said at fucking all
> The difference here is that to precompile Java to a native binary, you need to use some other compiler
> You posted nothing expect something everyone already knows; that you can tack on and wrap up other languages to the JVM
> Sun has been trying to implement dynamic languages in to Java. MS has already done so. It is possible to call python code from C#, have that python code emit and compile some JavaScript code that calls a method from a VB.Net library.
It would seem everyone knows it except >>11 who shares your ID.
Interfacing with Java's library without using Java's semantics is hard. The .NET has simpler semantics. I didn't disagree with this. However,
> So that makes using other languages with it difficult and some are impossible
says that you can't wrap - at least some languages- on the JVM.
> I said their only relationship is that they are buttons and should be named as such.
> Never said I was (smarter than SUN's developers)
"I'm smarter than SUN's developers"
When you're done arguing with yourself, let me know.
> See, your main problem is with reading comprehension
You seem very interested in what my main problem is.
You have (by my count) no less than three different people saying you're talking gibberish, and have no point.
You clearly don't know how to communicate. I don't know if it's your main problem, because you're also stupid and incapable of reason, and I think those are quite serious.
> You also seem to be adverse to reading the articles by experts that I have provided.
You're wrong. I just don't think they're experts. And why should I? He said something you said everyone knows- he doesn't disagree with me, does he?
I don't need an expert. You're spouting off gibberish and arguing mostly with yourself. Did you have a point in there someplace that you thought I disagreed with?
> IL is an ASM like language. Bytecode by itself is not really a language.
This is still my favorite gem. Thank you for showing me what kind of idiots they let at a keyboard.
>You're wrong. I just don't think they're experts.
So the guy that started both Jython and IronPython is not an expert on either. Once you understand how stupid that is, and how you do not seem to be capable of grasping these topics you will understand how incorrect your other "points" are.
>This is still my favorite gem. Thank you for showing me what kind of idiots they let at a keyboard.
Did you look down or something.
Bytecode (as in Java bytecode) is an instruction set for a software interpreter (as in the Java Virtual Machine).
Java is compiled in to bytecode.
IL (Actually CIL Common Intermediate Language) is is an object-oriented assembly language. The "common" comes from the fact that the language is common to all .Net languages. The "intermediate" comes from the fact that it is a step between high level code and low level code.
.Net code is compiled in to CIL. CIL is then translated in to bytecode.
An instruction set is not a language. An assembler language will closely mirror a platforms instruction set, but the assembler language is not an instruction set. And instruction set is not the assembler language. Assembly needs to be run through an assembler before it will run as it is not executable. Bytecode does not as it is executable (in Java's case it is executable on the JVM).
Java bytecode is the instruction set of the JVM. CIL is the assembly language of the .Net CLR.
I have no fucking idea how I can be more clear about these basic concepts of computers, Java and .Net. What I said was not wrong. It was demonstrably true.
You and others demonstrate a clear lack of understanding of these basic concepts. So I don't give a fuck how many of you say its gibberish because you lack some basic knowledge of these concepts and topics. So 50 of you ignorant fucks can say I am wrong, doesn't change the reality that I am in fact right.
So seriously, if you have any other pithy and ignorant comments feel free to fuck off.
oh yeah well your gay
> Bytecode (as in Java bytecode) is an instruction set for a software interpreter (as in the Java Virtual Machine).
I disagree. Besides, there exist several cpus that run java bytecodes directly:
http://en.wikipedia.org/wiki/Java_processor
> IL (Actually CIL Common Intermediate Language) is is an object-oriented assembly language.
Microsoft disagrees with you. IL is bytecode.
I have no fucking idea how Microsoft can be more clear:
> All .NET applications turn into IL bytecode via a compiler.
About this:
> So the guy that started both Jython and IronPython is not an expert on either.
Not necessarily, but more relevantly, he's not necessarily an expert on dynamic languages, or the JVM's support for them.
Finally, about this:
> I don't give a fuck how many of you say its gibberish
If everyone calls you crazy, you're crazy. You're supposed to use it as an opportunity to check your fucking attitude and learn something. Instead you think you're the cock of the walk and are arguing whether IL is bytecode or not, and whether Jython is as dynamic as IronPython.
Get a grip.
>I disagree. Besides, there exist several cpus that run java bytecodes directly:
You fucking idiot. Java bytecode is the instruction set for the Java Virtual Machine.
And here is where you truly are just a worthless retard. The fucking 2 sentences in the fucking page you posted fucking supports exactly what I already fucking said. You actually do not understand a fucking word of what you fucking read.
>A Java processor is the implementation of the Java Virtual Machine (JVM) in hardware.
Java processor = JVM. Major difference, 1 is hardware and 1 is software.
>In other words the bytecodes that make up the instruction set of the abstract machine become the instruction set of a concrete machine.
Bytecode make up instruction set, instruction set of software JVM becomes instruction set of the machine.
Java processor is hardware JVM that executes the bytecode as its instruction set.
FUCK!
>Microsoft disagrees with you. IL is bytecode.
Are you intentionally just trying to be a douche, or are you really that fucking stupid. Some random post on a Microsoft message board is not a fucking source. You believe that to be the case, yet disagree with my posts on this board. Maybe if I posted there you would believe it.
But, that post isn't wrong, you are just way too stupid to understand it. The posts reads that one can take CIL (an assembly like language for .Net) and then "compile" that CIL code using a program called Ilasm.exe.
If CIL was bytecode it would not need to be assembled. CIL is not bytecode and does need to be assembled as your "source" describes. It is assembled using Ilasm.exe (your source again), which Microsoft calls the MSIL Assembler.
http://msdn.microsoft.com/en-us/library/496e4ekx(VS.80).aspx
(oh fuck, a real MSDN doc)
So once again you disagreed with me by providing a link to something that states exactly what I said.
>but more relevantly, he's not necessarily an expert on dynamic languages, or the JVM's support for them.
The man in question is Jim Hugunin.
This non-expert is a software programmer who created the Python programming language extension Numeric (ancestor to NumPy), and later created Python implementations for the Java Platform (Jython) and for Microsoft .NET platform (IronPython); he has also co-designed the AspectJ (the widely-used de-facto standard for AOP) extension for the Java programming language. Since 2004 he is working for Microsoft, mainly on IronPython and Dynamic Language Runtime[1].
Yeah you shit eating retard. Those credentials are dubious at best.
>If everyone calls you crazy, you're crazy.
So when everyone said the world was flat, was it flat? You know what we call the people who still think the world is flat (and they do actually still exist)? Retards, idiots, morons etc.
>You're supposed to use it as an opportunity to check your fucking attitude and learn something.
I learned how people can still think the world is flat by your example. I basically gave you concrete evidence the world is round and you came back with, "Look at this sphear. It is the earth and it is flat."
>Instead you think you're the cock of the walk and are arguing whether IL is bytecode or not,
It isn't a fucking argument. CIL is not bytecode. Bytecode is not a computer programming laguage. You are the one arguing that the world is flat.
>and whether Jython is as dynamic as IronPython.
Also not an argument. Jim Hugunin the guy who created both demonstrated the differences.
> CIL is not bytecode.
> If CIL was bytecode it would not need to be assembled.
I think it's obvious that nobody wants to argue semantics with you. If there is a semantic difference between JVM and IL bytecodes, then there isn't a functional one due to people calling them different things.
Most people making .NET compilers work in IL assembly- as you say, just as most people working in JVM compilers work in JVM op assembly. Note the difference is the terms, not in what they do or how they do it.
Calling people shit eating retards while you're arguing whether that is "sky blue" or "light blue" is why nobody likes you and you have no friends.
> > Not necessarily, but more relevantly, he's not necessarily an expert on dynamic languages, or the JVM's support for them.
> Those credentials are dubious at best.
So we agree then. He's a smart guy, but based on the fact he's an implementor, he's not necessarily an expert on dynamic languages.
He said that the DLR is good because the DLR String is the same as IronPython's String.
Did anyone disagree with that?
REAL DIFFERENCES BETWEEN JAVA AND DOT-NET:
Things with technical terms, and a long history of thse use of those terms are called different things in Dot-Net land. This is very evident by asshats that insist that Dot-Net isn't executing bytecode, or that bytecode is somehow bad. Both Java and Dot-Net use very different terms, and the Dot-Net people get very angry if you don't use their terms. Beware.
Dot-Net is an implementation, which means it can be mutated and morphed by a single entity in response to trends and current events. Java is a specification that has many implementations. It is harder to morph that specification, but this also has many benefits: Java tends to be much smaller, simpler, and far easier to implement. As many Dot-Netters point out: There are no other competing implementations of Dot-Net. Unless you value multiple implementations, at which point there is Mono.
Dot-Net has converts. It wins over former Java programmers. Many are happy to see many of Java faults fixed - or at least covered up, and this makes sense- Dot-Net was designed and implemented long after Java was. These converts believe that everyone experiences Java's faults, and believe honestly that everyone feels the same way about those faults.
Finally, Java has history. It has a very large number of average-quality libraries that can be used to shorten most serious development projects. Its implementations have been refined over a long period of time, so for many practical (non-tuned) purposes, Java programs tend to be somewhat faster than Dot-Net-written programs.
>I think it's obvious that nobody wants to argue semantics with you. If there is a semantic difference between JVM and IL bytecodes, then there isn't a functional one due to people calling them different things.
It isn't an issue of semantics. Bytecode is executable on both JVM and CRL. They have no functional difference.
BUT, CIL is not bytecode. CIL is assembled in to bytcode.
Java is assembled in to bytecode.
.Net languages like C#, VB.Net, IronPython and the 40 or so others are compiled in to CIL. The CIL is then compiled in to bytecode.
>just as most people working in JVM compilers work in JVM op assembly. Note the difference is the terms, not in what they do or how they do it.
The Java "virtual machine assembly language" is close to CIL. Except, according to Sun there is no standard way of representing it.
http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html
So yes, its close, but functionally different.
>Calling people shit eating retards while you're arguing whether that is "sky blue" or "light blue" is why nobody likes you and you have no friends.
No, I say that because he contends that Java bytecode is a computer programming language. He then further disproved this by proving it. You seem to understand that bytecode is not a computer programming language.
>This is very evident by asshats that insist that Dot-Net isn't executing bytecode, or that bytecode is somehow bad.
.Net does indeed execute bytecode, and it is called bytecode. Some get confused because of the CIL compilation before bytecode compilation in .Net.
>Dot-Net is an implementation,
It is true. .Net is an implementation of the CLI (not CIL) Common Language Infrastructure standard approved by ISO and EMCA. C# is also a standard approved by these bodies. Func fact; the CLI and C# were published standards before Java submitted them (well resubmitted, they withdrew their initial submission in order to maintain complete control over Java at the time).
But the CLR is a MS specific version of the CLI. It would be nice if they documented and made freely available their specific implementation details. Oh they did, FUCK!
But Java is open source. If only the code for the .Net libraries was available to debug. A major component like the DRL wouldn't be completley open source. Oh, they are, FUCK!
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx
>which means it can be mutated and morphed by a single entity in response to trends and current events.
Are you implying that Sun does not control the Java standard? Because it does.
>It is harder to morph that specification
That is a deliberate move on Sun's part. They triumph backwards compatibility. MS makes the CLI as backwards compatible as possible, but it doesn't if it can make a substantial improvement. See my example of Java vs. CLI implementation of generics.
>Unless you value multiple implementations, at which point there is Mono.
My feeling from the .Net community at large is they like the idea of Mono. There is no practical reason to dislike it for any .Net dev. There were functional reasons but their latest release is starting to catch up.
Also, MS seems to like Novel for the effort. They did give Mono users a license to use Windows Media Codecs in Novels implementation of Silverlight. Yes, its binary only, no source and Moonlight only but it is something. Those particulars are another topic.
>Dot-Net has converts. It wins over former Java programmers.
Could be that C# is like Java. J# is an implementation of the Java language. MS has tools to convert Java bytecode to CIL. etc.
>Many are happy to see many of Java faults fixed - or at least covered up,
Covered up?
>and this makes sense- Dot-Net was designed and implemented long after Java was.
That does make sense.
>These converts believe that everyone experiences Java's faults,
Some people are so Java centric they don't even realize they are faults. They feel that is just the way it has to be done and no better way could exist.
>and believe honestly that everyone feels the same way about those faults.
I don't think anyone believes that. They might believe they should feel the same way.
>Its implementations have been refined over a long period of time, so for many practical (non-tuned) purposes, Java programs tend to be somewhat faster than Dot-Net-written programs.
I see what you are saying there. And it is practical. But there is always the other side of the coin. The whole Pet Shop debacle speaks to that.
> he contends that Java bytecode is a computer programming language.
Citation needed.
> Some get confused because of the CIL compilation before bytecode compilation in .Net.
Nobody gets confused by that. >>12 said IL has bytecode because >>11 suggested it didn't by saying:
> Java code is compiled in to bytecode
then saying .NET was somehow different.
Listing differences by listing how they are the same is top-notch asshattery.
> C# is also a standard approved by these bodies.
That does nobody any good if there are no implementations. As you pointed out: MONO isn't a worthwhile implementation.
> Func fact; the CLI and C# were published standards before Java submitted them
It's dishonest to conflate the definitions of "standard" with "standardized." CLI and C# aren't standard until they are a reference point upon which other things can be evaluated. That is to say that no language can actually be "standardized" until there are multiple implementations.
> They (Sun) triumph backwards compatibility
That's because it's a feature. It's a valuable one. Dot.Net doesn't have it- look at all the sites that got broke just between .NET2.0 -> .NET2.0SP2 - people relying on real .NET applications like absolutenm are simply beside themselves because a MINOR version release broke backwards compatability.
Don't you fucking dare try to downplay the value of backwards compatability. Don't even insinuate that .NET has anything remotely like it. It's insulting to my intelligence, and frankly it's insulting to yours as well.
The real factors are whether having that breakage occasionally - or even perhaps rarely (it's only happened twice to me, and only once on .NET with a minor version change)- is worth it in order to gain things like tight integration with generics.
> Covered up?
Resolved/hidden. Java6's generics aren't bad. They're not great, but they're not bad, and they handle most of the common cases pretty well.
> Some people are so Java centric they don't even realize they are faults. They feel that is just the way it has to be done and no better way could exist.
I think you'll find few people are actually like that. However, you must understand that .NET isn't necessarily better- it may be better at some things, but you need to look at the things it is worse at - and sometimes those things are very important to other people. Java got a lot of things right, and they got them before most desktop developers thought of those things as important.
In reality, .NET and Java aren't all that different to a Windows desktop or Windows server developer. They are very different to a MIDP developer, a Linux developer, an Android developer, a CF developer, and so on. Dot.Net won't ever get into these markets doing things the way they're doing it.
>Citation needed.
Read, follow along and understand this topic.
>Listing differences by listing how they are the same is top-notch asshattery.
Not understanding and following along is stupidity.
Java language is compiled in to Java bytecode.
.Net languages are compiled in to CIL. CIL is then compiled in to either bytecode or a native binary. Its part of the spec.
There exists Java compilers that compile Java to a native binary. There exists Java compilers that compile Java bytecode to a native binary. These are part of some implementations.
.Net -> CIL -> Bytecode or navite
Java -> bytecode or native
Can you see the fucking difference? Do you understand the rammifications of the CIL step.
>That does nobody any good if there are no implementations.
.Net on Windows.
MSes Shared Source Common Language Infrastructure which runs on Windows, FreeBSD and OSX. Its a non commercial reference educational license but it is an implementation.
Mono
DotGNU
>As you pointed out: MONO isn't a worthwhile implementation.
Yet. You exepct the development schedule to go:
Day 1 - Start.
Day 2 - finished 100%.
Doesn't work like that. They aren't done.
> Doesn't work like that. They aren't done.
Until they are, things like .NET are an unattractive development platform.
> MSes Shared Source Common Language Infrastructure which runs on Windows, FreeBSD and OSX. Its a non commercial reference educational license but it is an implementation.
I'm not aware of this. Where can I get it to compare?
I've got access to a large number of .NET applications I'd like to run on FreeBSD.
> Can you see the fucking difference? Do you understand the rammifications of the CIL step.
I understand that you think it's valuable. However, there's a reason most C compilers produce object files directly, instead of producing assembly.
I think that so long as there's a 1:1 relationship between the mnemonics and the bytecode, it's fair to call IL a bytecode.
> Read, follow along and understand this topic.
I see how you were confused. I will try to type slower in the future.
>I'm not aware of this. Where can I get it to compare?
Did you try Google or microsoft.com?
>However, there's a reason most C compilers produce object files directly, instead of producing assembly.
Not sure where you are going there. Object files are binaries containing the instructions of the target device. C compilers don't need to output assembly because the compiler can only take C code and can only make an executable binary for the target device.
The .Net compiler needs to accomplish something else. It needs to deal with multiple languages and multiple devices (as native binary output is possible as part of the spec). So each language compiles to a common language and that language has 1 assembler. The idea is that compiling every language to CLR bytecode is harder than just translating the language to CIL.
For example, early C++ and LISP compilers compiled the code to C and then compiled that with a C compiler. Although unrelated, it was easy enough to get both languages executable because they used a common language. Those early compilers didn't need to implement device specific compilers, they used the C compiler for the device.
.Net high level language compilers don't need a device specific compiler either. If you want .Net on a device, you only need to implement the CIL assembler as part of the CLI implementation. Now all of .Nets 40+ languages will work on that device with only 1 assembler implementation.
>I think that so long as there's a 1:1 relationship between the mnemonics and the bytecode, it's fair to call IL a bytecode.
Except CIL is not executable. It's a text file. Bytecode files are executable binary files. There may be a 1:1 relationship between the mnemonics and the bytcode/instruction set but there are other language constructs in CIL (and macro assembly languages) that are not machine instructions.
> http://www.microsoft.com/downloads/details.aspx?FamilyID=3a1c93fa-7462-47d0-8e56-8dd34c6292f0&displaylang=en
I've only played with this briefly, but already it seems much slower than MONO. I'll keep playing, thanks.
> For example, early LISP compilers compiled the code to C and then compiled that with a C compiler.
No they didn't. There are some CL compilers (ECL/Kyoto/GCL) that translate to C, but they do this for the purpose of linking with C. They're not very fast, and they're not what anyone would call "early". In fact, ECL is quite a bit more complicated than some native-code compiling CL compilers.
> The idea is that compiling every language to CLR bytecode is harder than just translating the language to CIL.
Then .NET's APIs are broken. That would make compiling languages like lisp very difficult where they actually have a compile() function which takes a lisp program to be compiled, and return the compiled function.
However, .NET has APIs for loading IL bytecode directly, so I don't think they're as broken as you suggest.
> Except CIL is not executable. ... there are other language constructs in CIL (and macro assembly languages) that are not machine instructions.
Just as there are in most x86 assemblers. GAS for example lets you include section headers with a single token.
Few people would call someone "completly wrong" for saying that mov is an x86 instruction- and yet while strictly speaking it's one of many mnemonics, nobody gives a shit except you, and it still doesn't prove that IL bytecodes are substantially different than Java bytecodes, or that someone chosing .NET over Java would care.
>No they didn't. There are some CL compilers (ECL/Kyoto/GCL) that translate to C...
It would save a lot of time if you would just stop saying I am wrong when:
http://en.wikipedia.org/wiki/Cfront
>the original compiler for C++ (then known as "C with Classes") from around 1983, which converted C++ to C
>Then .NET's APIs are broken. That would make compiling languages like lisp very difficult where they actually have a compile() function which takes a lisp program to be compiled, and return the compiled function.
I know what you said you think makes sense, but it does not. .Net happens to have self hosting compilers. So implementing a languages self hosting compiler ability in an environment that already does that would not be called "broken."
>However, .NET has APIs for loading IL bytecode directly
And for compiling the higher level languages at runtime. Something you don't seem to know.
>Few people would call someone "completely wrong" for saying that mov is an x86 instruction- and yet while strictly speaking it's one of many mnemonics,
Except all those non instruction set parts of the x86 assembler language. Your PC still won't execute a text file. That text file still contains macro symbols the machine does not understand.
>nobody gives a shit except you,
No, too many of you don't understand the distinction. You don't give a shit because you don't understand.
>and it still doesn't prove that IL bytecodes are substantially different than Java bytecodes,
No one has got to that level. You must still be confused and think that CIL assembler is bytecode. Since you are still confused after ample spoon feeding, it is hopeless. You will never understand these concepts.
>or that someone choosing .NET over Java would care.
They care about the implications of those differences. .Net has dozens of 1st class languages. Java has 1 (the rest are not first class languages). And even the number of other languages is time in comparison.
For low level stuff (low level relative to a VM anyway), Java has no standard way of representing bytecode as a low level language. .Net does.
Dismissing things because you don't understand them is a sign of something, what is that again?
> It would save a lot of time if you would just stop saying I am wrong when I'm wrong.
I'll do that: Just stop being wrong.
Remember when you said this?
> early C++ and LISP compilers compiled the code to C and then compiled that with a C compiler.
(emphesis mine), I was responding to early LISP compilers.
> I know what you said you think makes sense, but it does not.
Then I'll type slower: It's called rhetoric. If .NET compilers first wrote CIL assembly mnemonics into a text file and passed them to an assembler, then it would make languages like LISP difficult to implement. Since .NET has the APIs that make LISP easy to implement, this must not be true. I point this out in the next paragraph.
> No, too many of you don't understand the distinction. You don't give a shit because you don't understand.
We understand just fine. There is a plain-text assembly format for .NET. Few people actually use it when making compilers because there are better APIs. There is a plain-text assembly format for JVM. Few people actually use it when making compilers because there are better APIs.
What part don't we get?
> .Net happens to have self hosting compilers.
I don't think that means what I think you think that means.
> Except all those non instruction set parts of the x86 assembler language. Your PC still won't execute a text file. That text file still contains macro symbols the machine does not understand.
You have a very strange definition of "execute" which is different than ours; Your PC will execute anything you put under its instruction pointer- whether it comes in a text file or not. Your PC doesn't execute IL bytecode because there are no chips that do so. Your PC might execute Java bytecode directly, because there are chips that do so.
You haven't demonstrated that x86 asm files are any different than IL asm files in any way that they aren't also different from ppc asm files.
>If .NET compilers first wrote CIL assembly mnemonics into a text file and passed them to an assembler, then it would make languages like LISP difficult to implement.
No.
First there is no "If .Net compilers...", what you described is how .Net high level language compilers work.
>Since .NET has the APIs that make LISP easy to implement, this must not be true.
What you just said is compiling a high level language like lisp to a machine (virtual in this case) assembly language would make the language difficult to implement.
That's makes no sense. By your argument we can conclude every high level computer programming language is difficult to implement.
But you say that is not true because lisp is easy to implement. You then go on to say that it is easy to implement because of magic.
>Since .NET has the APIs that make LISP easy to implement, this must not be true.
APIs that must be written with the compilers own API implementation according to the specs. This just happens to make one feature you point out easy to implement.
>There is a plain-text assembly format for .NET. Few people actually use it when making compilers because there are better APIs.
What magic is this? .Net understands all languages through API calls?
System.Runtime.CompilerServices don't have a "magic" method that compiles any given string of arbitrary characters to bytecode.
You keep saying there is some magic translation from high level languge to bytecode through some existing API that understands everything.
>There is a plain-text assembly format for JVM.
Format implies some sort of formal specification defining the format. You have already forgotten the link to the page on Sun's own website that tells you exactly that there is no standard formal assembly language for the JVM. So not only is that statement false, it was already sourced and covered.
>Your PC will execute anything you put under its instruction pointer- whether it comes in a text file or not.
You just said that the text file of assembly instructions is directly executable by your machines processor. That is just stupid. The binary of the ASCII codes that make up a text file are not the same binary used for instructions.
Also, and again, those assembly language files contain symbols that are not instructions for the processor.
>You haven't demonstrated that x86 asm files are any different than IL asm files in any way that they aren't also different from ppc asm files.
You are having huge problems following along. I didn't make a distinction there. I brought up x86 asm because it uses a well known macro assembler language that contains symbols that are not machine instructions. If the asm contains symbols that are not executable, then the asm is not executable. Once assembled and those symbols are interpreted by the assembler, it is executable by the machine.
CIL contains symbols that are not instructions for the .Net runtime. CIL files are not executable binaries.
Java assembler may or may not include symbols, who the fuck knows. It's up to you I guess. Either way, the binary for a file that has created an arbitrary asm like language for bytcode is not executable by the JVM.
I can't believe I just had to explain that by repeating concepts already discussed and spoon feeding them together.
> First there is no "If .Net compilers...", what you described is how .Net high level language compilers work.
IronPython clearly doesn't work this way. Proceed to tell me that IronPython doesn't compile, that Lisp doesn't compile, and that if the result isn't a dot-exe file, compilation didn't take place.
> That's makes no sense [compiling a high level language like lisp to a machine (virtual in this case) assembly language would make the language difficult to implement.]
You cannot fathom how writing the opcodes to a textfile, performing some API to operate on the textfile, and negotiating the compiled result into the current address space is more difficult than simply writing to the current address space directly?
> >There is a plain-text assembly format for .NET. Few people actually use it when making compilers because there are better APIs.
> What magic is this? .Net understands all languages through API calls?
Why are you arguing about something you clearly do not understand very well?
Interactive .NET compilers almost always use Reflection.Emit and AssemblyBuilder to construct the assembly in memory, and simply run it. They don't usually mess with the asssembly-mnemonics any more than JVM-targetting compilers do.
> You keep saying there is some magic translation from high level languge to bytecode through some existing API that understands everything.
I said nothing of the sort. You clearly do not understand this very well.
Compilers lex and parse as they like, then call GetILGenerator() for the method. They then emit the operations they want to perform. They can then call the method directly. This is clearly better than the officially prescribed method JVM-targetting compilers perform, but not significantly different, and as I still maintain: the fact that there is an assembly mnemonics and a IL assembler is practically meaningless.
> >Your PC will execute anything you put under its instruction pointer- whether it comes in a text file or not.
> You just said that the text file of assembly instructions is directly executable by your machines processor. That is just stupid. The binary of the ASCII codes that make up a text file are not the same binary used for instructions.
I said nothing of the sort. You put the following:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*in a text file (see http://www.eicar.org/download/eicar.com.txt if your browser, or you, are brain-damaged) in a text file, rename it to dot-com, and your computer will run it. It will even do something meaningful.
These character have a 1:1 relationship with their mnemonics. For example "X" is pop %eax. This is what makes direct input buffer overflows possible.
> You are having huge problems following along.
I am. You should be clearer.
What exactly is your point again? IL bytecodes are significantly better than JVM bytecodes because .NET ships with an assembler for them?
I disagree that it is significant.
> CIL contains symbols that are not instructions for the .Net runtime.
x86 assembly files contain symbols that are not instructions for the x86 cpu.
> CIL files are not executable binaries
So what? JPEG files are not executable binaries. Do you have a point in there?
>IronPython clearly doesn't work this way...
IronPython and all the other DLR lanugages are compiled to CIL and then to bytecode just like every other high level .Net lanugage.
>You cannot fathom how writing the opcodes to a textfile, performing some API to operate on the textfile, and negotiating the compiled result into the current address space is more difficult than simply writing to the current address space directly?
You continue to think you know what you are talking about but you do not. One does not write opcodes to a text file. They would write the assembly language mnemonics to a text file.
>Interactive .NET compilers almost always use Reflection.Emit and AssemblyBuilder to construct the assembly in memory, and simply run it. They don't usually mess with the asssembly-mnemonics any more than JVM-targetting compilers do.
Reflection.Emit only works for a language already running on .Net. You cannot use it to implement your newly created language.
VB.Net has its own CIL compiler. C# has its own CLR compiler. The other languages do to. The compliation APIs use those compilers. Those APIs were not used to implement a lanuage.
>Compilers lex and parse as they like, then call GetILGenerator() for the method.
So this magical compiler for a language I just created can be parsed by .Net and generate the CIL code magically. WOW!
>and as I still maintain: the fact that there is an assembly mnemonics and a IL assembler is practically meaningless.
VB.Net, C#, J# and 40+ others running first class on .Net. Java and that's it running first class on Java. Java has been around for longer than .Net and has far fewer languages.
You are contending that any given machine (real or virtual) should have 1 first class high level language to program on it (and a couple 3rd world ones).
The single base CIL language makes implementing languages on .Net more practicle than on Java.
>in a text file, rename it to dot-com, and your computer will run it. It will even do something meaningful.
hahaha wow thats not how that works. If I name it .txt it opens in Notepad. That doesn't mean that my .txt file is the Notepad program.
>What exactly is your point again? IL bytecodes are significantly better than JVM bytecodes because .NET ships with an assembler for them?
Standard low level code modification. Many languages.
>So what? JPEG files are not executable binaries. Do you have a point in there?
Just as an .asm file needs to be assembled to be interpreted, a jpeg file needs a program to interpret it. That jpeg program is not a text file of assmebler as you are contending.
> Reflection.Emit only works for a language already running on .Net. You cannot use it to implement your newly created language.
Of course you can. In fact, it's the best way to make interactive languages on .Net.
> You continue to think you know what you are talking about but you do not. One does not write opcodes to a text file. They would write the assembly language mnemonics to a text file.
You're splitting hairs, but you're still wrong. Interactive compilers do not write the mnemonics to a text file. They generate the assembly in-memory and run it directly.
> So this magical compiler for a language I just created can be parsed by .Net and generate the CIL code magically. WOW!
Perhaps you've never written a compiler for .Net; you've certainly not written an interactive one. There's nothing magical about it, and you can learn a lot by doing so. Forth compilers are especially simple, and can be written by a third or fourth year CS student in an afternoon, so I'd recommend trying that.
.Net doesn't "parse" anything. Compilers like C#'s compiler consist of non-compiling parts such as the lexer, the parser, and any AST-generating components that are in there. The "compiling" part simply serializes the AST into some machine (or virtual machine) bytestream.
In Lisp, you don't need a lexer or a parser because the data structure you write in is the AST. That's why the definition of compile has to be carefully chosen to exclude the non-compiling parts.
Writing a .Net compiler can be done entirely threaded (using calls only) using Reflection.Emit. It's also very easy to do.
> You are contending that any given machine (real or virtual) should have 1 first class high level language to program on it (and a couple 3rd world ones).
I contend nothing of the sort. Citation needed.
I do howerver think your notion of first-classness is misplaced. Java's semantics are tied closely to it's virtual machine- Java doesn't have a GOTO so the virtual machine doesn't have a GOTO- and that means tail-recursion optimization is harder.
.NET's semantics aren't modeled on the virtual machine, but on a hypothetical CPU that could also process Java's semantics. As a result, it tends to not be as well-optimized, but it does make implementing many semantics easier.
Of course, it doesn't make all semantics easier, just fortunately those semantics tend to be hard to implement on real hardware as well so few people mind.
> hahaha wow thats not how that works. If I name it .txt it opens in Notepad. That doesn't mean that my .txt file is the Notepad program.
That exactly how it works. You load that .txt into memory, and point %eip at it, it will run.
> Standard low level code modification. Many languages.
These aren't complete sentences. Your point is that IL bytecodes are significantly better than JVM bytecodes because of STandard low level code modification?
That's gibberish.
And as many people have pointed out, there are many languages on the JVM as well.
>Of course you can. In fact, it's the best way to make interactive languages on .Net
I should have said "you shouldn't use reflection.emit for a new language."
I thought you were talking about passing some arbitrary language code to reflection.emit and getting CIL. Instead you want to interpret some new language with C# and pass that output to Reflection.Emit.
Here is any MSDN article about doing that.
http://msdn.microsoft.com/en-us/magazine/cc136756.aspx
That method has a lot of pitfalls and the conclusion at the end of the article is, use the DLR.
I have looked extensivley at both methods for a project I did. Initially I though of just using VB.Net or C# from some scripting. But after exploring the DLR and talking to some of the devs (it is open source) I went the DRL route and glad I did. The environment I setup will be able to run dozens of lanugages as they are released without any modification, and the performance was acceptable.
>You're splitting hairs, but you're still wrong. Interactive compilers do not write the mnemonics to a text file. They generate the assembly in-memory and run it directly.
By default, .Net compilers compiler to CIL (write the mnemonics to a text file) then assembler that.
But what I was really talking about is a person would write mnemonics. A person normally would not write an entire program in opcodes.
>I do howerver think your notion of first-classness is misplaced.
Jython is not Python running on the JVM. It's Python syntax executing as Java would. It is not first class because it has restrictions. An Object (as in base object type too) in Jython is not the same as a Java Oject. It's all wrapped an marshalled and imposes restrictions.
Iron Python has no such restrictions.
>As a result, it tends to not be as well-optimized, but it does make implementing many semantics easier.
Java's strange half assed backwards compatibility means it is not open to significant optimizations of new features it implements. Java runs about as well now as it ever will.
>That exactly how it works. You load that .txt into memory, and point %eip at it, it will run.
No. The binary that makes up the text file is different than the binary that makes up the assembelled program. An x86 CPU can't assemble programs on its own.
>Your point is that IL bytecodes are significantly better than JVM bytecodes because of STandard low level code modification?
IL bytecode does not exist. There is the CIL object oriented assembly language for the CLI, and there is bytecode which represents the assembled instructions of CIL for CLI. We have gone over this a dozen times.
As Sun stated, there is no standard way to represent bytecode in a low level language. One person might have use mov, the other might use mvr for the same fucking thing. Anyone can use whatever they want. So others would need to learn each mnemonic for each implementation for the same fucking thing. That prospect is unreasonable at best.
>And as many people have pointed out, there are many languages on the JVM as well.
And as I have pointed out, implementing the syntax does not mean the language works like its native implementation. It can only approximate in on the JVM.
You're right, of course. JVM's GOTO however is limited in that it cannot leave the current method:
> The target address must be that of an opcode of an instruction within the method that contains this goto instruction.
making it suitable for implementing Java's IF/ELSE, or Java's WHILE/FOR blocks, or the GOTO statement that BASIC systems have, but not the GOTO in PERL, or to implement tail-call elimination.
> I should have said "you shouldn't use reflection.emit for a new language."
You should've said a lot of things. Especially considering how interested in useless pendanticy you are.
> That method has a lot of pitfalls and the conclusion at the end of the article is, use the DLR.
The DLR includes a code generating interface that happens to use Reflection.Emit. It makes it easy to implement languages with direct dispatch, but it makes it very difficult to implement threaded interpreters or dynamic dispatch operations.
For an example: Look at what would be necessary to implement CLOS or Forth using the DLR and you'll see using Reflection.emit is much easier.
> Jython is not Python running on the JVM. It's Python syntax executing as Java would. It is not first class because it has restrictions. An Object (as in base object type too) in Jython is not the same as a Java Oject. It's all wrapped an marshalled and imposes restrictions.
That's an implementation detail to work around some Java library implementation decisions, and isn't a reflection of the JVM. Clojure (for example) doesn't have these restrictions either.
> Java's strange half assed backwards compatibility means it is not open to significant optimizations of new features it implements. Java runs about as well now as it ever will.
That's a feature. DotNet's strange half assed backwards compatibility means sometimes your code breaks because Microsoft changes things.
> No. The binary that makes up the text file is different than the binary that makes up the assembelled program. An x86 CPU can't assemble programs on its own.
Nobody said it did.
> IL bytecode does not exist. There is the CIL object oriented assembly language for the CLI, and there is bytecode which represents the assembled instructions of CIL for CLI. We have gone over this a dozen times.
Minor semantics. There is a 1:1 relationship between the bytecode the DotNet runtime executes and the assembly mnemonics it choses to represent with output dumps.
It's sounding more and more like your whole point is that the DotNet programmers have a text-based representation of their bytecodes.
> As Sun stated, there is no standard way to represent bytecode in a low level language. One person might have use mov, the other might use mvr for the same fucking thing. Anyone can use whatever they want. So others would need to learn each mnemonic for each implementation for the same fucking thing. That prospect is unreasonable at best.
It's meaningless. This doesn't cause any problems because people interact with the operations directly, instead of the textual mnemonics. Just like on DotNet, nobody uses the textual mnemonics, or the offline assembler. It's just stupid.
> And as I have pointed out, implementing the syntax does not mean the language works like its native implementation. It can only approximate in on the JVM.
You have failed to demonstrate any meaningful difference. I'll stick to the JVM: It's faster, and my code that I wrote over ten years ago will still run in another ten years, and I will be laughing, knowing, that you will never be able to say the same.