Java vs VB .NET



  • I'm doing an article for my High school portfolio and I need some input. Can some of you all list the pro's and con's of java over vb .net and vise versa?
    I favor java, but the Visual Stuido is nice (NetBeans is nearly as good and free).

    Thanks for your input.

    Jerome



  • Synergise your solution domain to a maximised win-win scenario by using an optimal combination. J#.NET for the win!



  • Just search google for "Java VB.NET flame war".



  • @malfist said:

    I'm doing an article for my High school portfolio and I need some input. Can some of you all list the pro's and con's of java over vb .net and vise versa?
    I favor java, but the Visual Stuido is nice (NetBeans is nearly as good and free).

    Thanks for your input.

    Jerome

    Java Pros:

    Has a syntax that is very similar to the most popular programming languages. It is therefore easier to read by professional programmers.

    Programs are supposed to be able to run on multiple platforms

    Java  Cons:

    Requires an interpreter to run.

     

     

    VB.Net Pros: 

    Looks like it is easy to program in since all syntax uses "words".

    The .NET api is easy to use and provides a simple interface to making windows applications. 

    VB.Net Cons:

    Looks like it is easy to program in since all syntax uses "words".

    Strange syntax make for interesting looking code.

    Professional programmers who have not had the "luxury" of dealing with VB will want to punch the monitor when they look at your code.

    You will be stuck with Microsoft. 

    You will get VB.NET programmers who were brought up on VB6. These "programmers" most likely won't want to learn any other languages, won't know how to program in an object oriented way, and will re-use everything they learned in VB6, even though Microsoft even wants them to forget it all.

    Using VB will make baby Jesus cry. You don't want that now, do you? 

     

     

     There are plenty more... Basically, I just wanted to say don't use VB.NET. If anything, use C#... although Java's perfectly fine too... Well, in any case, always use the language best suited for the problem you are solving. Just note that VB is hardly if ever the answer anymore.
     



  • @GoatCheez said:

    Java  Cons:

    Requires an interpreter to run.

    VB.NET, like C#, requires the CLR which is along the same lines as the JVM. 

    Not really a good thing about VB, but since it's VB.NET, you have access to the .NET libraries, which is a pretty good thing.

    -cw



  • @CodeWhisperer said:

    @GoatCheez said:

    Java  Cons:

    Requires an interpreter to run.

    VB.NET, like C#, requires the CLR which is along the same lines as the JVM. 

    Not really a good thing about VB, but since it's VB.NET, you have access to the .NET libraries, which is a pretty good thing.

    -cw

    Yeah, looks like I forgot to mention that. lol... I was too concerned with highlighting reasons not to use VB that I skipped any general .NET items... I guess I could also put into pros that VB.NET is xplat though since a properly coded strict .net app should run when using mono...



  • Java:

    You get to argue with everyone

    VB.NET:

    You get to argue with everyone but most responses will start with "the real wtf is..."



  • I'd rather do a Java vs .NET or Java vs C# but it's your call.

     

    The differences in the languages (code) themselves :

    VB.NET uses 'VB' syntax while java uses c syntax. I prefere c syntax which is terser and easier to read but it's a question of taste.

     VB.NET has operator overloading, Java hasn't.

    In VB.NET and contrary to Java methods are non virtual by default (like c++). I won't go into details, go look it up on google if you want.

    VB.NET is case insensitive but visual studio automatically correct the case if you typed something incorrectly. Imho it's a good thing : one less thing to worry about, prevents subtle bugs and dirty tricks such as using lower case for the private member and an upper case for the public accessor.

    Option strict : with VB.NET you can decide weither or not the compiler enforces strict type conversion. It's not possible with Java. With the option strict on you must explicitely cast variable from one type to the other (eg.: aString = (String) myObjectWhichIKnowIsAString//the explicit casting to a string is required). With option strict off VB.NET do the casting for you (eg.: aString = myObjectWhichIKnowIsAString//no need for (String), it's done for me). So in short it allows you to decide if you want the compiler to enforce early binding or if you want VB.NET to perform late binding for you. Note that whatever you set the option to, you still have strong typing, it's just the casting which is different. There is an hot debate on which one is best, the nice thing is that in VB you can CHOOSE which way you want on a per file basis, not so much with java :).

    Personaly I think that the need to explictly cast things is good because it allows you to notice bugs you wouldn't otherwise see. But implicit casting is nice to have is some circonstances sucha as when you perform a lot of casting you know is safe (you don't have to litter your code with useless casting operators).

     Option explicit : similary you can decide weither or not variable declaration is required before using them.

     

     

    As to portability : note that mono now has full VB.NET supports so you can write for other platforms with VB aswell.

    Of course the major differences between the two is that VB uses the .NET framework while java uses...java. Therefore the class library is different, the tools are different, one is open source the other closed,... That sounds stupid but if you're writing an article about it you need to make it clear.

    Another thing I think would be important to add is that there is a difference between VB and VB.NET.They are actually two different beast altogether! VB has a reputation to be a crappy and dirty language when you can only make crappy spagueti code. THerefore VB.NET inherited that bad reputation from it's ancestor. 

    The most important thing I think is that even if there a lot of smallish differences between the two, in the end they are very similar languages. Their core is the same (object oriented with interfaces and whatnot). So if you know one of the two languages AND UNDERSTAND THE CONCEPTS BEHIND THAT LANGUAGE then you won't have too many problem picking up the other.



  • IMO the most important difference is plattform independance. Java runs perfectly on Linux, Macs etc., and all versions are released concurrently.

    For .net, there is Mono and DotGNU, but these are not on par with MS .net.

    On the other hand, .net programs look perfectly native on Windows, while Java GUI programs rather don't. 



  • @Monkeyget said:

    Option strict : with VB.NET you can decide weither or not the compiler enforces strict type conversion. It's not possible with Java. With the option strict on you must explicitely cast variable from one type to the other (eg.: aString = (String) myObjectWhichIKnowIsAString//the explicit casting to a string is required). With option strict off VB.NET do the casting for you (eg.: aString = myObjectWhichIKnowIsAString//no need for (String), it's done for me). So in short it allows you to decide if you want the compiler to enforce early binding or if you want VB.NET to perform late binding for you. Note that whatever you set the option to, you still have strong typing, it's just the casting which is different. There is an hot debate on which one is best, the nice thing is that in VB you can CHOOSE which way you want on a per file basis, not so much with java :).

    Personaly I think that the need to explictly cast things is good because it allows you to notice bugs you wouldn't otherwise see. But implicit casting is nice to have is some circonstances sucha as when you perform a lot of casting you know is safe (you don't have to litter your code with useless casting operators).

     Option explicit : similary you can decide weither or not variable declaration is required before using them.

    This is a problem that is quite common for me. Say I get some external data that i wish to parse into an object , and I want a generic method that does pre-processing of the data, and then casts it into the appropriate type. In java, I could declare the parsing-method as a generic method, which casts into the generic type before returning. This is somewhat similar to implicit casting.

     

    Example: 

    public <T> T process(byte[] data) {
        Object o = parseIntoObject(data);
        return (T) o;
        }

     

    You can use it like this:

        byte[] data = getData(...);
        String s = process(data);

    Maybe this is obvious to you guys, I don't know. Just think it's a nice trick that I would like to share...
     



  • I've not really looked into it yet, but as of dotnet2, VB.NET (along with C#) has generics too.

     Oh, and Option explicit and Option strict are the two most evil things in VB.NET thanks to the pointless attempts to be vaguely compatible with the thankfully nearly dead VB6.
     



  • Here's my article, feel free to tell me what is wrong with it and where I need to correct. Any extra ideas on how to improve it would be nice.

     

    <FONT face="Times New Roman" size=5>Java and Visual Basic (.NET)</FONT>

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p><FONT size=3> </FONT></o:p>

    <FONT size=3><FONT face="Times New Roman">            There are many differences between Java and Visual Basic .NET. Most of them lay in how software is created, run, and maintained. Most of what people cite as the best programming language is a personal opinion, usually based on what language is easiest for them to use instead of the best tool for the job. In this piece, I shall compare the pros and cons of each language and the most common clichés about each of them.</FONT></FONT>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT face="Times New Roman">Ease of Use and Program Creation<o:p></o:p></FONT>

    <o:p><FONT face="Times New Roman"> </FONT></o:p>

    <FONT size=3><FONT face="Times New Roman">            Visual Basic is considered the easiest language to learn. That is the main reason most experienced programmers dislike Visual Basic. In Visual Basic it is so easy to create a program, and therefore (because of the lack of understanding) to mutilate a program into a dangerously malfunctioning monster. Edsger Wybe Dijkstra once said, “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” Another saying that has been attributed to him is that, “Teaching BASIC should be a criminal offense.” Visual Basic attracts many users who may be very intelligent; do not know how to produce an efficient, easily maintained program. Visual Basic does far too much for you, and you end up not learning how to really program and work as a group because you don’t need to, or so it seems. Today Java is the language taught to beginners even though some oppose it. The reason for this is that Java is a High Level Language (meaning you program with words) and that it is Object Oriented. Today, VB .NET is Object Oriented too but VB6, where most of the VB .NET programmers come from does not use objects, it is more Event Oriented (meaning it responds when you do something (an event)). Object Oriented Programming is the next step in programming. OOP (Object Oriented Programming) is the art of creating programs that are composed of Objects that can be broken down and used again in another program easily. Java is not very hard to learn, but is harder than VB .NET.</FONT></FONT>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT face="Times New Roman">Running the Program<o:p></o:p></FONT>

    <o:p><FONT face="Times New Roman"> </FONT></o:p>

    <FONT size=3><FONT face="Times New Roman">            Java has the advantage over VB .NET here. Java was specifically designed to function on all operating systems, networks, and all computers that run. Visual Basic was not, and probably never will be. Visual Basic is a proprietary and owned by Microsoft. Windows, its Operating System is all they will ever make it run on; it would benefit its competition to allow other Operating Systems to use it too. Java runs on Solaris, Linux, UNIX, Windows, Mac, and any other language that has the Java Virtual Machine installed on it. Java runs anywhere, anytime. Visual Basic is limited to Microsoft Windows. Java is a thoroughly stable language while the inner workings of the Visual Basic .NET’s API (things that you program with) has strange errors and does not always react the way it is supposed to, resulting in program crashes or erroneous results.</FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">            VB .NET has some advantage here too. Visual Basic, because it was designed for only Windows its GUI (Graphical User Interface, the thing that the users see and interact with) looks fine, it is what you expect. Java has its own look and feel, which is different from Windows, which can sometimes make it look ‘unnatural’. Java looks the same in all Operating Systems although if a programmer chooses he or she can make it look specific to an OS (Operating System). Java was also originally designed for server work, for stuff that does not require a GUI and Java 1.0 did not come with any graphical tools. Visual Basic has always come with these, hence ‘Visual’. Later Java did supply an AWT (Abstract Window Toolkit) to add GUI components to their language but it was heavy and slow. Later Java released Swing which is much better and faster than the original AWT but it is still in production, and being updated although it is stable.</FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">            Some people like to claim that because Java is an interpreted language it is slower to run than C/C++ and Visual Basic. Benchmarks show that language choice between these languages are based more upon the programmers ability than that of the languages speed, Java is just as fast as the other languages.</FONT></FONT>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT face="Times New Roman">Maintainability<o:p></o:p></FONT>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT size=3><FONT face="Times New Roman">            Java seems to take the cake for this one. However, it is not really Visual Basic’s fault. The reason Java is more maintainable is simple due to the massive influx of inept programmers that are attracted to VB’s ease of use. Inept programmers may make programs that work some of the time but they tend to have strange and unreadable code that doesn’t quiet work the way it is supposed to. Inept programmers do not comment their code as often as they should, if at all. Comments allow other programmers to understand what the code is doing, and to know what to do with it. With VB .NET’s new sophistication, if you ignore the inept programmers the maintainability is near equal to Java. </FONT></FONT>

    <FONT face="Times New Roman" size=3>When Java updates something, they don’t destroy the old Java. When Java updates, things do not ‘break’, when Visual Basic updates, they change things around and to update your code you have to update everything, else it becomes ‘broken’ and will not work. Java’s standard API (tools that you program with) is tested much more thoroughly than VB’s is. One user of the Java forums (provided by java.sun.com) made this comment:</FONT>

    <FONT size=3><FONT face="Times New Roman">            “Java is a very boring programming language. That is because when you create a program and test it to make sure it works and put it to use, you forget about it. In Java you don’t need to go back and change things every time a new version is released. Where I work we once changed servers, and discovered Java programs we had forgot about, they ran successfully every time, they worked after updates, and when we moved servers, they worked then too.”<o:p></o:p></FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">            You will not hear that being said about Visual Basic, because during updates, things break.</FONT></FONT>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT size=3><FONT face="Times New Roman">            Java is a great programming language, and so is Visual Basic .NET. If you are programming for more than one operating system, use Java, it by far surpasses any other language in that category. If you are programming for Linux and what to keep closed source (prevent other’s from copying you), use Java. If you don’t mind having open source for Linux or windows use C/C++ (because the user will have to compile the source code). If you want the best for Windows, you should probably use Visual Basic .NET. Java is great at what it does, and it continues to expand on what it is trying to do. Visual Basic .NET is great at what it does too, but it has a smaller focus. Each programming language is very good tool, if used properly, and they are both getting better. Visual Basic .NET is a large step above Visual Basic Six; some say it is Microsoft’s response to Java. Use the tool that is best for the job. Each of these languages have pros and cons, you decide which is best for your situation.</FONT></FONT>


     

    <o:p><FONT face="Times New Roman" size=3> </FONT></o:p>

    <FONT face="Times New Roman" size=3>Sources:</FONT>

    <FONT face="Times New Roman" size=3>http://ei.cs.vt.edu/book/chap1/java_hist.html</FONT>

    <FONT face="Times New Roman" size=3>http://www.java.com/en/javahistory/timeline.jsp</FONT>

    <FONT face="Times New Roman" size=3>http://www.johnsmiley.com/visualbasic/vbhistory.htm</FONT>

    <FONT face="Times New Roman" size=3>http://www.startvbdotnet.com/dotnet/vb.aspx</FONT>

    <FONT face="Times New Roman" size=3>http://en.wikipedia.org/wiki/Java_(programming_language</FONT><FONT face="Times New Roman" size=3>)</FONT>

    <FONT face="Times New Roman" size=3>Lutz Prechelt. Technical opinion: comparing Java vs. C/C++ efficiency differences to interpersonal differences. ACM, Vol 42,#10, 1999</FONT>

     



  • @malfist said:

    <FONT size=3><FONT face="Times New Roman">“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” Another saying that has been attributed to him is that, “Teaching BASIC should be a criminal offense.” </FONT></FONT>

    You should remove these quotes.  They are from this.  Notice that your second quote is misquoted (he was talking about COBOL, not BASIC).  He was basically saying that all of the popular languages of 1975 were flawed, he wasn't picking on BASIC in particular.  Also note that 1975 basic is very different from present day VB.NET or even VB6.  In those days GOTOs (as in "GOTO Considered Harmful") with line numbers were the norm.

    Also you should footnote all of your references to your sources, or at least the ones you quote directly.



  • @burnmp3s said:

    you should footnote all of your references to your sources, or at least the ones you quote directly.

    I was just going to post that myself. I don't know what academic level you're currently enrolled in, and perhaps you haven't had any instructions in writing reports, but you should (1) avoid a personal, talkative language mode and instead affect a dispassionate impersonal one; and (2) you must always qualify every statement you make, either by providing a source in the text directly following the quote or paraphrase, or make is clear it is your own conclusion, and how you've come to it. If I were your examiner (and if we're talking about an academic (== college or university) paper) I'd refuse it in its current state and send it back to you for language revision, proper references, and qualifying your statements.



  • Hmm I'd certainly disagree with a lot of that.

    "<font size="3"><font face="Times New Roman">Visual Basic does far too much for you, and you end up not learning how to really program and work as a group because you don’t need to, or so it seems."</font></font>

    That's VB6. VB.NET (the version that's been around for 5 years) does as much/little for you as C#, and about the same as Java. Of course, all 3 do more for you than C.

    I don't know the exact focus or intent of your article, but a lot of the Vb stuff seems to revolve around "VB sucks because the users of it suck". You also strangely state that "<font size="3"><font face="Times New Roman">Visual Basic .NET’s API  has strange errors and does not always react the way it is supposed to, resulting in program crashes or erroneous results" None of that is</font></font> really fair or true. Ignoring the VB6 to VB.NET migration (because they're really seperate but similar languages), changes are generally bugfixes and new stuff, which is the same in any language/framework. .NET also has a major plus over Java in this area - being designed to let you run several versions of the framework concurrently. If you have one app that only works in Java 1.4 and another that only runs with 1.5, you're stuffed. With .NET you can tell the EXE what version(s) of the framework to use. Maybe one random guy on a Java forum had a good experience, but I've had more compatability issues with Java than .NET.

    The whole section on maintainability I'd disagree with. Unless you're talking Perl or brainfuck, most code is exactly as maintainable as the developer allows. Language makes zero difference.

    You say that VB6 wasn't OO - and while it was weak in this area it was still OO, you just didn't have a lot of the more advanced features like inheritance. Neither is OO "the next step in programming". OO concepts are as old as the hills, and most common languages are OO. In fact, I think you need to generally make it more clear that VB.NET is a clear break from the old VB6, hence the common sentiment that MS should have called it Visual Fred instead, in order to stop people making comparisons and confusing it with it's retired disaster of an ancestor.

    As for the cross platform stuff, yes Java is the clear winner there, but things like mono and rotor still deserve a mention.

    You also seem very desktop-centric (considering your statement that Java started off as a server language), which ignores large areas of focus for the two languages - web development.



  • @RayS said:

    .NET also has a major plus over Java in this area - being designed to let you run several versions of the framework concurrently. If you have one app that only works in Java 1.4 and another that only runs with 1.5, you're stuffed. With .NET you can tell the EXE what version(s) of the framework to use. Maybe one random guy on a Java forum had a good experience, but I've had more compatability issues with Java than .NET.

    It's perfectly possible to have more than one version of Java installed. In fact, this is a common scenario in the Oracle world - oracle installer products install their own Java 1.3 while there is also a more current version of Java installed on the same machine.

    I have not experienced any unexpected compatibility issues with Java yet, but of course if a class or method is marked "deprecated", it might vanish in some version. 



  • Oops you're right. Ignore that, then.



  • @malfist said:

    I'm doing an article for my High school portfolio and I need some input. Can some of you all list the pro's and con's of java over vb .net and vise versa?
    I favor java, but the Visual Stuido is nice (NetBeans is nearly as good and free).

    Thanks for your input.

    Jerome

    VB is beer, Java is coffee.

    Java can keep one rational, clear headed and efficient for the most part, but it can also lead to paranoia and irritability. It can, in extreme cases lead to people speaking with extreme verbosity while really not saying much at all.

    VB is a reasonably relaxing way to program and can be a lot of fun. It can, however, artificially inflate ones sense of confidence, especially in ones ability to program a computer with a real language. It also leads to loss of balance, causing one to fall over regularly, and prolonged use inevitably shrinks the brain.

    Any more questions?



  • (grrr... having problems making multiple quotation sections... oh well, I'm sure all y'all will figure it out)

    @malfist said:

    <FONT size=3><FONT face="Times New Roman">Visual Basic is considered the easiest language to learn. That is the main reason most experienced programmers dislike Visual Basic. In Visual Basic it is so easy to create a program....</FONT></FONT>

    <FONT face="Times New Roman" size=3>

    </FONT>

    <FONT face="Times New Roman" size=3>I don't hate VB because it's easy to learn.  In fact, I hate VB because I consider it hard to learn due to its many inconsistencies.  I groan over how hard it is to find simple mistakes (e.g., mispelled variables) that are trivially found by C/Java/other compilers.  (Yes, I know about option explicit.  It's a PITA to put it in afterwards, however, when stuck with someone else's program.)</FONT>

    <FONT face="Times New Roman" size=3>I think what gave VB a reputation as "easy to learn" was not the language in general, but the relative ease with which one can create Windows GUI programs.  (At least, so I've been told.  Hardly any of the programs that I've ever created in any language, including VB, have been GUIs.)</FONT>

    <FONT size=3><FONT face="Times New Roman"><FONT face=Arial size=2>@malfist said:

    </FONT></FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">VB6, where most of the VB .NET programmers come from does not use objects, it is more Event Oriented (meaning it responds when you do something (an event)). </FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">

    </FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">VB has its own objects, and many VB programs will use COM objects.  I'm not going to claim it's a "good" OO language, but they're there.</FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">VB is event-oriented only to the extent that it is used to create GUIs.  Actually, this has nothing to do with language.  GUI programming by its nature, is generally event-oriented.  Also, whether a particular program is event-oriented or not has nothing to do with whether it is object-oriented or not.</FONT></FONT>

    <FONT size=3><FONT face="Times New Roman"></FONT></FONT>

    <FONT size=3><FONT face="Times New Roman"><FONT face=Arial size=2>@malfist said:

    </FONT></FONT></FONT>

    <FONT size=3><FONT face="Times New Roman"></FONT></FONT><FONT size=3><FONT face="Times New Roman">Some people like to claim that because Java is an interpreted language it is slower to run than C/C++ and Visual Basic. </FONT></FONT>

    <FONT size=3><FONT face="Times New Roman">

    </FONT></FONT>

    <FONT face="Times New Roman" size=3>VB is arguably more of an interpreted language than Java.  If I'm running a VB program inside Visual Studio, I can change the code on the fly, to some extent, while the program is running.  Only difference is that VB programs are trivially compiled into an exe.  Whether it runs any faster as an exe than in Visual Studio is a topic for another day (my extremely limited sample size says "no faster").</FONT>



  • @AssimilatedByBorg said:

    <font face="Times New Roman" size="3">VB is arguably more of an interpreted language than Java.  If I'm running a VB program inside Visual Studio, I can change the code on the fly, to some extent, while the program is running.  Only difference is that VB programs are trivially compiled into an exe.  Whether it runs any faster as an exe than in Visual Studio is a topic for another day (my extremely limited sample size says "no faster").</font>

    Depends on what version you're talking about. Older versions of VB were mostly interpreted (VB5 or 6 I think gave the option to compile directly) but VB.NET is very much *not* interpreted. It's initially compiled to bytecode, which is JITted at (or before) execution time to 100% native code. I'm not sure what changes they've made in 2005 to bring back the much loved/hated edit & continute, but it doesn't take away from the fact that .NET code is not interpreted in the field. since VB.classic is now hopefully dead in all but legacy applications, "Visual Basic is not interpreted" resolves as true IMO.

    Of course, while Java is traditionally interpreted, some (most?) modern java environment can compile to native instead of interpreting.




  • @RayS said:

    @AssimilatedByBorg said:

    <FONT face="Times New Roman" size=3>VB is arguably more of an interpreted language than Java.  If I'm running a VB program inside Visual Studio, I can change the code on the fly, to some extent, while the program is running.  Only difference is that VB programs are trivially compiled into an exe.  Whether it runs any faster as an exe than in Visual Studio is a topic for another day (my extremely limited sample size says "no faster").</FONT>

    Depends on what version you're talking about. Older versions of VB were mostly interpreted (VB5 or 6 I think gave the option to compile directly) but VB.NET is very much *not* interpreted. It's initially compiled to bytecode, which is JITted at (or before) execution time to 100% native code. I'm not sure what changes they've made in 2005 to bring back the much loved/hated edit & continute, but it doesn't take away from the fact that .NET code is not interpreted in the field. since VB.classic is now hopefully dead in all but legacy applications, "Visual Basic is not interpreted" resolves as true IMO.

    Of course, while Java is traditionally interpreted, some (most?) modern java environment can compile to native instead of interpreting.


    Good point; I'm currently dealing with VB6, so that's the space my mind is in.  That particular part of my post is a little off-topic, since I refer mostly to VB6 than VB.Net.

    As a personal pet peeve, I hate Java being described as "interpreted".  In my mind, JIT aside, it's compiled to the Java Virtual Machine "assembly", which is then translated to the native machine at run-time.  In the "compiled vs. interpreted" continuum, Java's much closer to compiled, for all practical purposes from the programmer's perspective.  IMHO only.... and your definitions of "interpret" and "translate" may differ from mine.... I've long grown sick of people saying, "why would you use Java... it's interpreted!" rather than apply any intelligent analysis.



  • @AssimilatedByBorg said:

    As a personal pet peeve, I hate Java being described as "interpreted".  In my mind, JIT aside, it's compiled to the Java Virtual Machine "assembly", which is then translated to the native machine at run-time.  In the "compiled vs. interpreted" continuum, Java's much closer to compiled, for all practical purposes from the programmer's perspective.  IMHO only.... and your definitions of "interpret" and "translate" may differ from mine.... I've long grown sick of people saying, "why would you use Java... it's interpreted!" rather than apply any intelligent analysis.

    In both Java and .NET platforms, the source code is compiled to intermediate code (bytecode), which is handed over to a virtual machine (whether it be the JVM or the CLR) for execution. For all intents and purposes, I don't see a large difference in how the two platforms handle execution of code. I suppose the extent of compiling the bytecode into native code at runtime by JITing may be different by the two virtual machines, but whatever isn't being compiled by JIT is more or less being interpreted by the VM. I'm not sure how compiling to bytecode on Java would be "closer to compiled" as opposed to compiling to MSIL on .NET.

    If people say "Java is interpreted," I think there's some truth to it, as unless the bytecode is being converted into native machine code, it is interpreted. However, I also feel that those comments come from people who either live in the past when the JVM didn't have JIT (pre-1.2 days before HotSpot), or are just unaware of how VM and JIT work in general.

    That said, my little concern about the paper is that the comparison of Java and VB .NET sounded like a mixture of a comparison of platforms and languages. Whenever Java was being mentioned, it appeared that the Java platform was being mentioned without discussion of the language. Conversely, when discussing VB .NET, there seemed to be an emphasis on "it's easier to program, so it attracts bad talent" and less on the .NET platform that it stands on.



  • @coobird said:

    In both Java and .NET platforms, the source code is compiled to intermediate code (bytecode), which is handed over to a virtual machine (whether it be the JVM or the CLR) for execution. For all intents and purposes, I don't see a large difference in how the two platforms handle execution of code. I suppose the extent of compiling the bytecode into native code at runtime by JITing may be different by the two virtual machines, but whatever isn't being compiled by JIT is more or less being interpreted by the VM. I'm not sure how compiling to bytecode on Java would be "closer to compiled" as opposed to compiling to MSIL on .NET.If people say "Java is interpreted," I think there's some truth to it, as unless the bytecode is being converted into native machine code, it is interpreted.

    The argument is is as usually only a failure to properly define what is really debated, and in this case peoples' ideas about what the "actual platform is" differ. Some see the platform as the virtual machine, and then Java and .NET are compiled languages, and some see the platform as the OS, and then they are interpreted languages. Programmers should read more philosophy of language and many irrelevant argumentations would be pre-empted (and philosophers should study some programming and they could take care of programming their own gadgets).



  • @Mikademus said:

    @coobird said:

    In both Java and .NET platforms, the source code is compiled to intermediate code (bytecode), which is handed over to a virtual machine (whether it be the JVM or the CLR) for execution. For all intents and purposes, I don't see a large difference in how the two platforms handle execution of code. I suppose the extent of compiling the bytecode into native code at runtime by JITing may be different by the two virtual machines, but whatever isn't being compiled by JIT is more or less being interpreted by the VM. I'm not sure how compiling to bytecode on Java would be "closer to compiled" as opposed to compiling to MSIL on .NET.If people say "Java is interpreted," I think there's some truth to it, as unless the bytecode is being converted into native machine code, it is interpreted.

    The argument is is as usually only a failure to properly define what is really debated, and in this case peoples' ideas about what the "actual platform is" differ. Some see the platform as the virtual machine, and then Java and .NET are compiled languages, and some see the platform as the OS, and then they are interpreted languages. Programmers should read more philosophy of language and many irrelevant argumentations would be pre-empted (and philosophers should study some programming and they could take care of programming their own gadgets).

    Don't forget that "native" machine code is not always a direct representation of the instructions that are actually run on your CPU.  To take an extreme example, the Transmeta Crusoe processor translates x86 instructions into its own VLIW instructions on the fly.

    The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability.  If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.



  • @burnmp3s said:

    @Mikademus said:
    @coobird said:

    In both Java and .NET platforms, the source code is compiled to intermediate code (bytecode), which is handed over to a virtual machine (whether it be the JVM or the CLR) for execution. For all intents and purposes, I don't see a large difference in how the two platforms handle execution of code. I suppose the extent of compiling the bytecode into native code at runtime by JITing may be different by the two virtual machines, but whatever isn't being compiled by JIT is more or less being interpreted by the VM. I'm not sure how compiling to bytecode on Java would be "closer to compiled" as opposed to compiling to MSIL on .NET.If people say "Java is interpreted," I think there's some truth to it, as unless the bytecode is being converted into native machine code, it is interpreted.

    The argument is is as usually only a failure to properly define what is really debated, and in this case peoples' ideas about what the "actual platform is" differ. Some see the platform as the virtual machine, and then Java and .NET are compiled languages, and some see the platform as the OS, and then they are interpreted languages. Programmers should read more philosophy of language and many irrelevant argumentations would be pre-empted (and philosophers should study some programming and they could take care of programming their own gadgets).

    Don't forget that "native" machine code is not always a direct representation of the instructions that are actually run on your CPU.  To take an extreme example, the Transmeta Crusoe processor translates x86 instructions into its own VLIW instructions on the fly.

    The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability.  If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.

     

    They would if they were going to sell the software to thousands of people and they wanted to make it as hard as possible to modify or access the source code. 



  • @burnmp3s said:

    Don't forget that "native" machine code is not always a direct representation of the instructions that are actually run on your CPU.  To take an extreme example, the Transmeta Crusoe processor translates x86 instructions into its own VLIW instructions on the fly.

    The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability.  If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.

    Well if you're going to go down to that level, everything is interpreted, since no major recent x86 CPU (neither Intel nor AMD) runs native x86!


  • @tster said:

    @burnmp3s said:

    The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability.  If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.

    They would if they were going to sell the software to thousands of people and they wanted to make it as hard as possible to modify or access the source code. 

    Yes security is a concern too, but in my opinion it's not nearly as important as the other two factors.

    First of all, remember that interpreted != scripting.  Sure if you send out your Python scripts to people, you are giving them the source code.  Java on the other hand is also interpreted, but bytecode is much more similar to native machine code than it is to the source code.

    Also, simply compiling to native machine code is not a very good security measure to prevent modifications.  With relatively little effort, software cracking groups have removed copy protection schemes from nearly every game and application released in the last 10+ years.
     


Log in to reply