I am pretty sure i am asking a silly question but why do say C# needs to be interpreted at runtime. Why cant it straight away be compiled into pure asm like C,C++ etc?
What are the advantages of inhaving interpreted code?
What are the advantages of inhaving interpreted code?
The advantages or interpretors are:
1)Interpretors are much easy to program than compilers
(the interpreter itself i mean)
2)Interpretors might have more relaxed syntax. For example there is no need for you to define a variable or an variable type at program start; as the interpreter is able to decide its type and size from the context.
3)Interpretors might become machine independant (CPU and OS independant)
So your source code might get executed exactly the same on multiple CPU's and OS's without any need for changes whatsoever.
Obviousely Compilers have to recompile for each CPU/OS combination
However Interpretors also have disadvantages:
1) Slow up to Extreemly slow (check Java)
2) They might get decompiled into plain recompilable code quite easy, so stealing source code is at hand
3)You need to have the interpreter/or its runtime equivalent present / installed on the machine for your app to run (generally big/huge if language is advanced like VBor Java or VFox ...)
Compiled code will require just the CPU and OS to be present.... hmmm and support DLLs for MFC :grin:
1)Interpretors are much easy to program than compilers
(the interpreter itself i mean)
2)Interpretors might have more relaxed syntax. For example there is no need for you to define a variable or an variable type at program start; as the interpreter is able to decide its type and size from the context.
3)Interpretors might become machine independant (CPU and OS independant)
So your source code might get executed exactly the same on multiple CPU's and OS's without any need for changes whatsoever.
Obviousely Compilers have to recompile for each CPU/OS combination
However Interpretors also have disadvantages:
1) Slow up to Extreemly slow (check Java)
2) They might get decompiled into plain recompilable code quite easy, so stealing source code is at hand
3)You need to have the interpreter/or its runtime equivalent present / installed on the machine for your app to run (generally big/huge if language is advanced like VBor Java or VFox ...)
Compiled code will require just the CPU and OS to be present.... hmmm and support DLLs for MFC :grin:
1)Interpretors are much easy to program than compilers
(the interpreter itself i mean)
I dont think big companies like ms will shift to interpretors just cause its easier for their programmers to write one.
(the interpreter itself i mean)
2)Interpretors might have more relaxed syntax. For example there is no need for you to define a variable or an variable type at program start; as the interpreter is able to decide its type and size from the context.
In case of C# and Java you have to define the variable typle and initialize it too before using it as its built in the language.
3)Interpretors might become machine independant (CPU and OS independant)
So your source code might get executed exactly the same on multiple CPU's and OS's without any need for changes whatsoever.
So your source code might get executed exactly the same on multiple CPU's and OS's without any need for changes whatsoever.
In the case of Java having an interpretor seems to be fine cause it runs on mulitple platforms but .Net is designed to be run only on Windows.
So actually i still havent come to know of a single reason as to why interpreted languages are needed especially in the case of .Net or even Visual Basic 6 etc which are not meant for diff platforms but windows only , other than say Reflection. I wont mention garbage collection cause there is already a library which can provide garbage collection for C/C++
So my question still remains as i asked it :confused: Any answers?
You have already established your own answers into your own mind :grin:
Actually there is no reason for any other HLL language than ASM, :tongue:
but still they exist
Actually there is no reason for any other HLL language than ASM, :tongue:
but still they exist
Neither Java or .NET are interpreted languages, they are JIT compiled.
The speed of the first itteration of any loop is slow, but subsequent itterations should be faster as they will be in a native code format cached. A similar effect can be seen on transmeta's crusoe processors who's code morphingTM technology is essentially a JIT compiler.
.Net is not soley designed to run on x86 windows, MS is (or was) intent on providing .NET for wince, and there are apparently people looking at a .NET for linux project. I don't believe it has the blessing of MS, and I'm not sure how far it will get.
The real advantage of interpretted code (properly interpreted) is for teaching. The linear execution of code means you effectively have a super high level language being run on a native machine. There have been interpreted versions of C written for the purpose of teaching, and as it is interpretted, there is no re-compile if you change the code.
Beyond the teaching scope of an interpretted language, I personally don't see the point of true interpretted languages. The loss of speed with no real gain makes them worse than any other choice. The only reason VB exists is because it's easy to learn, and people never move on to "propper" languages.
Mirno
The speed of the first itteration of any loop is slow, but subsequent itterations should be faster as they will be in a native code format cached. A similar effect can be seen on transmeta's crusoe processors who's code morphingTM technology is essentially a JIT compiler.
.Net is not soley designed to run on x86 windows, MS is (or was) intent on providing .NET for wince, and there are apparently people looking at a .NET for linux project. I don't believe it has the blessing of MS, and I'm not sure how far it will get.
The real advantage of interpretted code (properly interpreted) is for teaching. The linear execution of code means you effectively have a super high level language being run on a native machine. There have been interpreted versions of C written for the purpose of teaching, and as it is interpretted, there is no re-compile if you change the code.
Beyond the teaching scope of an interpretted language, I personally don't see the point of true interpretted languages. The loss of speed with no real gain makes them worse than any other choice. The only reason VB exists is because it's easy to learn, and people never move on to "propper" languages.
Mirno
The real advantage of interpretted code (properly interpreted) is for teaching. The linear execution of code means you effectively have a super high level language being run on a native machine. There have been interpreted versions of C written for the purpose of teaching, and as it is interpretted, there is no re-compile if you change the code.
Mono moves forward with good force - .Net is hardly a MS only thing. Try to look at the bigger picture of evolving computer languages and the rapid jump technology is preparing to make -- the two must have an abstraction layer between them. I'm not saying x86-32 is going anywhere, but in 10 years it might be totally interpretted. :)
If that does not make a believer of you, take a look at the Zephyr project - this has been in the works a long time. Abstracting the evolution of programming languages and hardware away from each other is what HLLs are all about. Every attempt is made to minimize the costs of such an abstraction, but as processors become faster the slow down due to the abstraction becomes less. Add in the complexity of the software being written and code management costs -- we are quick to favor HLLs.
IMHO, there are far too many assumptions on the long term benefits of such a system of software development. It often seems self serving and rarely produces the benefits it claims (not totally unlike myself! ;)).
. The only reason VB exists is because it's easy to learn, and people never move on to "propper" languages.
Mirno
Thats very unclever. VB gives you the advantage in business writing applications in little time and low cost.
In times where software companys growing faster than flowers in spring you need to take advantage of the tools you can get.
Look how many VB programs are running in offices and then compare their number with assembler programs running.
Its like 10 to 0,5.
Then take a look at the count of VB programmers then count the numbers of ASM programmers.
Its like 1000 to 1.
VB exists cause it gives everyone (not just geniuses like you) the possibility to write your own applications without having to deal
with all the backoffice of a computers hard/software and without sitting in some IBM or MS Center. Schools are teaching VB to kids already.
MS didnt got rich by publishing ASM.net, they know what people want.
MS publishes interpreted software and delivers its OS with all Dll `s and OCX`s ready to run those.
Still what counts in business is cash, with assembler you wont earn alot and you will be on a lonely ride.
Software companies writing their codes in .Net and Java - cause in times where cpu`s have 3 ghz and 1gb Ram more nobody cares
about how faster a loop can be in asm or how small an .exe can be in asm.
regards
Ranma
This message was written entirely in my Messageboard Editor v4.0
no, with the .NET family he's absolutely right.
now with c#, the only reason for existance vb.net has, is to satisfy those who are unwilling or unable to learn a better .NET language.
now with c#, the only reason for existance vb.net has, is to satisfy those who are unwilling or unable to learn a better .NET language.
There seems to be a bit of confusion. I know .Net can be made to run on any os which has a .net framework for it but currently as of now (and it seems in the future too) it will be a mostly windows thingy. Its still not like a Java 'write once run it anywhere' kinda thingy.
Mono guys are doing well but they wont be ever able to catch with the way ms will provide enhancements to .Net like generics, the new enhancements to WinForms, etc coming up in VS Whidbey.
Sorry for writing 'interpreted' instead of JIT there which probably led you to misunderstanding my question. What i meant was that why is code interpreted from say even ILasm to x86 asm at runtime? Even if it is done only once by the JIT.
What are the advantages of having exes contain ILasm of Java Byte code in them instead of x86 asm, other than the fact it can run on any cpu architecture and have reflection? What kind of extra abstraction does it offer?
And also why are these JIT languages so slow?
Mono guys are doing well but they wont be ever able to catch with the way ms will provide enhancements to .Net like generics, the new enhancements to WinForms, etc coming up in VS Whidbey.
Sorry for writing 'interpreted' instead of JIT there which probably led you to misunderstanding my question. What i meant was that why is code interpreted from say even ILasm to x86 asm at runtime? Even if it is done only once by the JIT.
What are the advantages of having exes contain ILasm of Java Byte code in them instead of x86 asm, other than the fact it can run on any cpu architecture and have reflection? What kind of extra abstraction does it offer?
And also why are these JIT languages so slow?
The Java you run is different from the kind of server-side java. Servers will run trusted code, that doesn't need some of the kind of separation from the system that home applets do. I for one won't trust an applet downloaded over the internet, so I want it run inside a full virtual machine with protection from all kinds of nasty code.
Java can run fast, but because of the nature of where it is run, the executing JVM is set for maximum security rather than maximum speed.
Ranma, I'm not saying everyone should learn ASM, far from it. In fact I'd push people away from it if they really didn't want to learn it. There are a whole lot of better languages between VB and assembly, ranging from pascal, to perl, to c/c++/c#. People stick with VB because they get results fast and think "I'm a l33t ha><or", they never move on to a "proper" language because they are lazy and/or are not pushed on. No matter what you are doing, there are better languages for everything out there, with the exception of MS Office macros - and the only reason for that is Microsoft hasn't made one.
Mirno
Java can run fast, but because of the nature of where it is run, the executing JVM is set for maximum security rather than maximum speed.
Ranma, I'm not saying everyone should learn ASM, far from it. In fact I'd push people away from it if they really didn't want to learn it. There are a whole lot of better languages between VB and assembly, ranging from pascal, to perl, to c/c++/c#. People stick with VB because they get results fast and think "I'm a l33t ha><or", they never move on to a "proper" language because they are lazy and/or are not pushed on. No matter what you are doing, there are better languages for everything out there, with the exception of MS Office macros - and the only reason for that is Microsoft hasn't made one.
Mirno
And also why are these JIT languages so slow?
Think about this, you need a program to run another. Would you prefer such a program or one that has lesser dependency? Obviously the latter is faster because you run the machine code, the language that your cpu understands. Personally I have no real likes for interpreted languages and are using only because I have to.
What are the advantages of having exes contain ILasm of Java Byte code in them instead of x86 asm, other than the fact it can run on any cpu architecture and have reflection? What kind of extra abstraction does it offer?
Nothing much in my opinion. Yet another reason why I am unwilling to install .NET framework and to learn c# and things associated with .NET. In my humble opinion, I think Microsoft wasted their time creating this.
Beyond the teaching scope of an interpretted language, I personally don't see the point of true interpretted languages. The loss of speed with no real gain makes them worse than any other choice. The only reason VB exists is because it's easy to learn, and people never move on to "propper" languages.
This I have to agree with. I have seen enough people claiming they are "elite" because they code in VB (oh yes, of all languages).
Ranma_at,
I could not help by saying that the only reason why there are more VB coders than ASM coders and why there are more VB programs than programs coded in asm is because VB is *much much* easier than Assembler. Therefore it is not a fair comparison.
MS didnt got rich by publishing ASM.net, they know what people want.
MS publishes interpreted software and delivers its OS with all Dll `s and OCX`s ready to run those.
MS publishes interpreted software and delivers its OS with all Dll `s and OCX`s ready to run those.
Definitely(and obviously) Microsoft does not know what I want.
Still what counts in business is cash, with assembler you wont earn alot and you will be on a lonely ride.
Software companies writing their codes in .Net and Java - cause in times where cpu`s have 3 ghz and 1gb Ram more nobody cares
about how faster a loop can be in asm or how small an .exe can be in asm.
Software companies writing their codes in .Net and Java - cause in times where cpu`s have 3 ghz and 1gb Ram more nobody cares
about how faster a loop can be in asm or how small an .exe can be in asm.
Whores without brains. With that idea in their head, the application would never be faster thought one can have the faster computer than before. And also it is another reason why I never want to be a professional programmer. I rather do programming as a hobby than make a living out of it.
Actually there is no reason for any other HLL language than ASM, :tongue:
I totally agree with this. The HLL creates schemas and abstraction layers that are useful for the purposes and minds of their creators but when the time comes along, the superseded concepts and new particular requirements added continuously a series of constraints and design compromises.
The commercial languages become heavy machines and the market rules govern over the common sense.
Look for example the implementation details of OOP (encapsulation+inheritance+polymorphism) in VB :grin:
I think all of us,we agree that coding in asm demands relatively much more time. So,in business life,we have to consider
the timing factor. I think that this topic looks like the challenge of HLL vs asm.
For a professional coder,time can be more important,so better to deal with HLLs like C/C++ or VB. On the other hand, a person coding for hobby can have much more time to use asm which gives the opportunity to create small apps running very fast. Finally,we can think here about an optimisation : to unify the power of asm with the elasticity of HLLs such as creating asm based DLLs for VB applications - C/C++ apps supported with high speed loops coded in asm.
If we talk about programming, different situations requires it's own coding styles, so maybe there is no reason to stick only with one language.
the timing factor. I think that this topic looks like the challenge of HLL vs asm.
For a professional coder,time can be more important,so better to deal with HLLs like C/C++ or VB. On the other hand, a person coding for hobby can have much more time to use asm which gives the opportunity to create small apps running very fast. Finally,we can think here about an optimisation : to unify the power of asm with the elasticity of HLLs such as creating asm based DLLs for VB applications - C/C++ apps supported with high speed loops coded in asm.
If we talk about programming, different situations requires it's own coding styles, so maybe there is no reason to stick only with one language.
I see the topic is drifting to asm vs HLL than what it was intented for.
I just wanted to know what are the advantages (not disadvantages) of having a JIT compiled language. Or put it simply what features would C# lack if it was compiled straight to x86 asm code. :)
I just wanted to know what are the advantages (not disadvantages) of having a JIT compiled language. Or put it simply what features would C# lack if it was compiled straight to x86 asm code. :)
Off the top of my head...
They seem to fall into the category of Development Features:
Simpler, and consequently, faster compilers.
Only code that gets executed gets "completely" compiled. In the case of MSIL, the recompiling occurs on a per-module basis.
They seem to fall into the category of Development Features:
Simpler, and consequently, faster compilers.
Only code that gets executed gets "completely" compiled. In the case of MSIL, the recompiling occurs on a per-module basis.
By Mirno.Beyond the teaching scope of an interpretted language, I personally don't see the point of true interpretted languages.
Then I guess scripting languages like those used for .BAT files and Unix shell scripts are worthless. Or the Javascript code used in a lot of HTML pages.Think about this, you need a program to run another.
That is the OS running your app ;).
Here the interpreted lenguage I think in java need a VM a Virtual machine I think this provide a layer for protection and execution between the real host of the programm and the programm, the VM have their own strunction set, this is why can run in any OS that have a implementation of the isntruction set, remember the called byte codes? that sound like opcodes ;), the instruction set is diferent sure, and is executed by a machine that is not there (VM), is simulated by a program on the target machine or I need say target OS.
That is why is slow whatch at other diferent simulators or interpreters, like bochs, run slow, but provide a layer for execution and simulation of I/O, the VM provide other things like security and a equal set of instructions for all the plataforms.
Nice day or night.
I see the topic is drifting to asm vs HLL than what it was intented for.
I just wanted to know what are the advantages (not disadvantages) of having a JIT compiled language. Or put it simply what features would C# lack if it was compiled straight to x86 asm code. :)
control
once MS has ported everything they have to their JIT compiler/bytecode framework, they can put it on any chip it supports. MS alread has huge leverage on intel and AMD to make them see things differently when needed, this is just one more step to reduce cost of porting and to make sure not to get stuck with a platform not to their liking (in any broad imaginable sense upto Bill Gates not liking the CEO at Intel for all anyone cares)
.NET does not only benefit MS -- no more than Java only benefits Sun. It surely simplifies the complexities of a very large software company -- just like IBM's use of Java, and development of tools for it!
clippy, you have to think bigger than a single program running. It is like asking why we need XML, or why we need anything beyond ASM, or why we need to program anything at all beyond creating the hardware. These very high level abstractions allow larger companies to leverage their investment in software development. Without this leverage software development might not be a profitable enterprise except at the small scale. The hardware evolution is out-pacing software resulting in stress on the symbiotic relationship between them.
Why do we need MS Office? Lotus 1-2-3 (I used the first spreadsheet VisiCalc, too) and WordPrefect were very good programs and had a large user base. I speak from 23 years of software use: the uniformed GUI elements killed anything that didn't look and work the same across the board. It is more efficient to know one key combination or menu function or toolbar icon, and have it work in all programs the same. It is about flattening the learning curve for the user and there by increasing the user base. Corporations needed data and needed cheap people to input the data.
...and computer programing is increasing the user base. Corporations need lots of programming and cheap programmers to code it. Ever see an HTML sweatshop? Rows of small workstations plugged into minimum wage script monkeys - kind of like the rows of TV's at the electronic store.
People are exposed to computer programming from many directions, and different languages appeal to different uses/users. Wouldn't it be really cool for them to have a common base? I think so, and so do many other people! The problem is that we can not agree on what that base should be: x86, DotNET, Java, English, etc... (Note: I don't really think it should be x86 or English - we already have a common base - these attempts are just poor reflections.)
clippy, you have to think bigger than a single program running. It is like asking why we need XML, or why we need anything beyond ASM, or why we need to program anything at all beyond creating the hardware. These very high level abstractions allow larger companies to leverage their investment in software development. Without this leverage software development might not be a profitable enterprise except at the small scale. The hardware evolution is out-pacing software resulting in stress on the symbiotic relationship between them.
Why do we need MS Office? Lotus 1-2-3 (I used the first spreadsheet VisiCalc, too) and WordPrefect were very good programs and had a large user base. I speak from 23 years of software use: the uniformed GUI elements killed anything that didn't look and work the same across the board. It is more efficient to know one key combination or menu function or toolbar icon, and have it work in all programs the same. It is about flattening the learning curve for the user and there by increasing the user base. Corporations needed data and needed cheap people to input the data.
...and computer programing is increasing the user base. Corporations need lots of programming and cheap programmers to code it. Ever see an HTML sweatshop? Rows of small workstations plugged into minimum wage script monkeys - kind of like the rows of TV's at the electronic store.
People are exposed to computer programming from many directions, and different languages appeal to different uses/users. Wouldn't it be really cool for them to have a common base? I think so, and so do many other people! The problem is that we can not agree on what that base should be: x86, DotNET, Java, English, etc... (Note: I don't really think it should be x86 or English - we already have a common base - these attempts are just poor reflections.)
The major difference between compiled and interpreted languages is "early" or "late" binding. There are other issues of binding differences that differentiate various interpreted languages. Early binding has the speed advantage when running, whereas the interpreted language is faster to develop in.
At one point in time VFP was going to be included in .net. MS VFox and Independent Fox developers requested Microsoft remove VFP from .net to preserve functionality that would be lost if included in the CLR.
Rather than rewrite what has already been written...
http://fox.wikis.com/wc.dll?Wiki~ShouldVFPBeInTheCLR~VFP
About 1/3 of the way down the page MarkusEgger gives some examples, and explains the differences.
Best,
Scott
At one point in time VFP was going to be included in .net. MS VFox and Independent Fox developers requested Microsoft remove VFP from .net to preserve functionality that would be lost if included in the CLR.
Rather than rewrite what has already been written...
http://fox.wikis.com/wc.dll?Wiki~ShouldVFPBeInTheCLR~VFP
About 1/3 of the way down the page MarkusEgger gives some examples, and explains the differences.
Best,
Scott
Some things about the ILasm/.NET JITed code:
Once the code has been JITed once to native ASM, it is saved in the assembly cache, so the JIT does not happen again. There is a tool provided with the .NET SDK that allows a developer to do the JIT when their application is installed on the user's machine so they do not experience the performance hit the first time the user runs the application.
The JITed code can create optimized ASM based on the user's CPU at run time. If I have an AMD the framework might generate different ASM than if I had dual P4s. This would be very difficult to do in straight ASM.
Once the code has been JITed once to native ASM, it is saved in the assembly cache, so the JIT does not happen again. There is a tool provided with the .NET SDK that allows a developer to do the JIT when their application is installed on the user's machine so they do not experience the performance hit the first time the user runs the application.
The JITed code can create optimized ASM based on the user's CPU at run time. If I have an AMD the framework might generate different ASM than if I had dual P4s. This would be very difficult to do in straight ASM.