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
using early or late binding for COM objects is but an implementation choice/difference, it does not define a difference between interpreted or compiled. VB can chose between early/late from version 4 if I remember correctly. :)
After all the only difference is wether the program will use IDispatch or a vtable pointer, which "under its skin" can both be implemented if the compiler/interpreter is up to it.
As for visual foxpro, MS has been trying to ween people off that for years in favour of access, MSDE and sql server IMO :/
Hiro,
Early or late binding doesn't always refer to COM. In this discussion: Do we know at compile time exactly what we are dealing with?
Early binding
In asm when dealing with a table I would fix the number of fields, field names, their data types, the length of the field, etc. I would also fix the user interface/screen so everything is displayed in fixed locations. If I change the structure of the table, revisions to the code must be made and a recompile done.
C# in my opinion, falls in between in functionality, in order to make it behave similar to FoxPro, more code needs to be written.
Late binding
In FoxPro I can change the table at run-time in the run-time. The structure can change, the data types change, the lengths of the fields or even the order. Further my user interface can get the data it needs to display itself because it is data driven.
I can build a late binding assembly program by adding interpreter capabilities to my asm program. I can't change the FoxPro runtime to eliminate the interpreter that is built in even though I can ignore it or defeat its use.
Originally posted by Hiroshimator
"As for visual foxpro, MS has been trying to ween people off that for years in favour of access, MSDE and sql server IMO :/ "
Why oh why does the mere mention of FoxPro cause such a problem? Regardless of the language, or peoples opinions of it, a/any language may be apropriate for demonstrating differences without invitation to diss it.
Lets look at some facts.
1) VFP is not dead yet, though some have tried for 10 years to kill it. If MS wanted it dead it would be gone in seconds, no ifs, ands, or buts. Look at Visual InterDev or J++ http://support.microsoft.com/default.aspx?scid=fh;;LifeDevToolFam
2) VFP Version 9 is under development by MS as we write.
3) VFP is a mature language with a good historical track record. Ample third party developer tools that are also mature, including frameworks exist. This is not the case with VS.net. VS.net has a whole flurry of activity at this point, but none of it is mature.
Apples, Oranges, and Tangerines.
4) MSDE (a limited version of SQL Server) and SQL Server are a back end only (separate program gets the data from the store and passes it to some other program which may not be the user interface).
5) Access and VFP provide a data handling front end (user interface) and a local data store. FoxPro can also run on the server as a COM server (though limited).
6) ASM, C, C#, VB, and .net don't have built in data handling in the front end, though they may be used to build front ends, or back ends (data store).
Select the best language for the task to be done.
7) Comparing one of these programs to any other for suitability for a specific application requires that the "Application Specification" be available, and the evaluation be done in the context of that spec.
8) Microsoft doesn't make money on developer tools, they make money on Operating Systems, SQL Server, and Office.
Best,
Scott
Early or late binding doesn't always refer to COM. In this discussion: Do we know at compile time exactly what we are dealing with?
Early binding
In asm when dealing with a table I would fix the number of fields, field names, their data types, the length of the field, etc. I would also fix the user interface/screen so everything is displayed in fixed locations. If I change the structure of the table, revisions to the code must be made and a recompile done.
C# in my opinion, falls in between in functionality, in order to make it behave similar to FoxPro, more code needs to be written.
Late binding
In FoxPro I can change the table at run-time in the run-time. The structure can change, the data types change, the lengths of the fields or even the order. Further my user interface can get the data it needs to display itself because it is data driven.
I can build a late binding assembly program by adding interpreter capabilities to my asm program. I can't change the FoxPro runtime to eliminate the interpreter that is built in even though I can ignore it or defeat its use.
Originally posted by Hiroshimator
"As for visual foxpro, MS has been trying to ween people off that for years in favour of access, MSDE and sql server IMO :/ "
Why oh why does the mere mention of FoxPro cause such a problem? Regardless of the language, or peoples opinions of it, a/any language may be apropriate for demonstrating differences without invitation to diss it.
Lets look at some facts.
1) VFP is not dead yet, though some have tried for 10 years to kill it. If MS wanted it dead it would be gone in seconds, no ifs, ands, or buts. Look at Visual InterDev or J++ http://support.microsoft.com/default.aspx?scid=fh;;LifeDevToolFam
2) VFP Version 9 is under development by MS as we write.
3) VFP is a mature language with a good historical track record. Ample third party developer tools that are also mature, including frameworks exist. This is not the case with VS.net. VS.net has a whole flurry of activity at this point, but none of it is mature.
Apples, Oranges, and Tangerines.
4) MSDE (a limited version of SQL Server) and SQL Server are a back end only (separate program gets the data from the store and passes it to some other program which may not be the user interface).
5) Access and VFP provide a data handling front end (user interface) and a local data store. FoxPro can also run on the server as a COM server (though limited).
6) ASM, C, C#, VB, and .net don't have built in data handling in the front end, though they may be used to build front ends, or back ends (data store).
Select the best language for the task to be done.
7) Comparing one of these programs to any other for suitability for a specific application requires that the "Application Specification" be available, and the evaluation be done in the context of that spec.
8) Microsoft doesn't make money on developer tools, they make money on Operating Systems, SQL Server, and Office.
Best,
Scott
Hiroshimator,
The difference between VB.NET and C#.NET is syntax and verbosity. There is very little that VB can do that C# can't, and vice versa. Also, the differences are decreasing with each iteration. There is a big difference between Classic VB and VB.NET. Classic VB is a more limited language than VB.NET, IMO.
Charles
The difference between VB.NET and C#.NET is syntax and verbosity. There is very little that VB can do that C# can't, and vice versa. Also, the differences are decreasing with each iteration. There is a big difference between Classic VB and VB.NET. Classic VB is a more limited language than VB.NET, IMO.
Charles
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.
Hiro, I hate to say this, but you are being too general here. Way to generalized. I know C#, I can do it, and indeed, do lots with it. But there is a reason why I _prefer_ VB.NET over C#: Ease of use.
Yes, you heard me. VB is simply a more productive language. I can do lots with C#, I am not ignorant and I am well learned in the syntax. Even so, I can get things done faster in VB.NET than C#. Not the least of which is the fact that the IDE feature support is better (intellisense in particular) than C#, and that alone makes me much more productive in C#.
I was writing a series of WebControls in C# and spent quite some time hammering away. There was so much typing and having to look things up because of the lack of Intellisense (yes, I have to look things up because I don't have the entire class library memorized as doesn't anyone else, I presume). So I switched to VB.NET on that project and produced at least 10 times more results in the same amount of time as the C# project. I'd consider that improvement.
Again, with the way the upcoming release is going I'd say C# looks to be the better win but, while I don't spend a lot of my time debugging, I have a defensive-programming nature about me, I do find myself having to restart the project (solution takes about 45 seconds to recompile because it is a very large project) with simple little tweaks that don't effect the flow of the logic much.
In 2.0, VB.NET will be able to edit while debugging while C# still doesn't get that feature. Many have started religious holy wars over the issue about how I need to grow up and learn a real language. What those same people refuse to understand is that if I don't have to recompile the project because I want to change a number or the default value of a value or some silly thing likea parameter in a function call being in the wrong place, I have to wait at least a minute before I can see the change take effect. Sometimes, the circle is so repetitive, it takes hours to get things right when I can spend minutes if I don't have to keep restarting the project over and over. We have several projects that are apart of a solution. But the web app is very large and is the reason for the long compile. As well, once it compiles we have to navigate, it has to re-JIT, and then hit the database and so on. I wouldn't have to keep repeating the process if I could edit-n-continue... or if I was perfect and never made a mistake, or if business requirements never changed and required source-code modifications. But this isn't the philosophical world, it's reality.
In this respect, once again, VB.NET is more product than C# and otherwise, will have all the feature that C# 2.0 will have when they release it (VB.NET 2.0 as well)... currenly, that's not the case.
Of course, VB.NET may not be a "real" language,but it is real enough that between my wife's income and my income, we are pulling in $139,950 USD per year. Of course, nothing is stopping me from using C# in that company other than the fact that I feel like I get things accomplished faster and with less effort that in C#. It makes a difference. I've never missed a deadline (yet). But the guys that are using C# have slipped up a few times (and I don't say it is because of the language, as much as the learning curve if you are not already familiar with the syntax). The Java programmers have no problem moving to C# as they can't understand VB.NET immediately.
Now, C# is not interpreted. It is Jit'd and can be natively compiled without the JIT. VB6 can be interpreted or compiled. Those who believe C# is interpreted are misinformed.
Thanks,
_Shawn
well thx for the clarification :)
_Shawn,
Interesting post :alright: . When you do programming as a hobby you can use any language you want and argue that its better than the rest but when you do it professionally you use the tool that makes you the most productive. After reading your post I am starting to wonder why more people don't use vb.net instead of c# especiallly for the large projects that take close to a minute of more to compile. I don't know anything about .net, c# or vb.net but I hear you can do almost anything in vb.net that you can do with c# so if vb.net is better tool for a project then why not use it. I consider it a real language as long as it gets the job done.
Interesting post :alright: . When you do programming as a hobby you can use any language you want and argue that its better than the rest but when you do it professionally you use the tool that makes you the most productive. After reading your post I am starting to wonder why more people don't use vb.net instead of c# especiallly for the large projects that take close to a minute of more to compile. I don't know anything about .net, c# or vb.net but I hear you can do almost anything in vb.net that you can do with c# so if vb.net is better tool for a project then why not use it. I consider it a real language as long as it gets the job done.
Odyssey,
There is one reason to use C# over VB.NET, make that 2 reasons, for all others, it is only a matter of taste.
First of all, if you are writing controls that have raise events, C# has a better event model implementation that VB.NET currently doesn't support. Although you you can still get the same results if you do it in VB.NET, C# just has an improved syntax and feature for that area.
As well, C# supports operator overloading and VB.NET does not. As such, if you create an object in C# that overloads it will not be functional in VB.NET. I have a good example of this:
My Planet-Source-Code submission
I needed to work with Binary data types and minipulate them as such becuase of a 65c02 processor similator I wrote in C#. I just find it easier to have a data type rather than rewriting all the binary manipulations when they were needed. As such, I overloaded all the operators so they would behave and feel just like any other C# valuetype and can be used with all of them. But It can't be used in VB.NET because of the operator overloaded.
In this case, C# is more productive than VB.NET.
Those are thus far the only two differences I've encountered between C# and VB.NET. I think the COM support is better in VB.NET as well, but I won't go there in this post.
Thanks,
_Shawn
There is one reason to use C# over VB.NET, make that 2 reasons, for all others, it is only a matter of taste.
First of all, if you are writing controls that have raise events, C# has a better event model implementation that VB.NET currently doesn't support. Although you you can still get the same results if you do it in VB.NET, C# just has an improved syntax and feature for that area.
As well, C# supports operator overloading and VB.NET does not. As such, if you create an object in C# that overloads it will not be functional in VB.NET. I have a good example of this:
My Planet-Source-Code submission
I needed to work with Binary data types and minipulate them as such becuase of a 65c02 processor similator I wrote in C#. I just find it easier to have a data type rather than rewriting all the binary manipulations when they were needed. As such, I overloaded all the operators so they would behave and feel just like any other C# valuetype and can be used with all of them. But It can't be used in VB.NET because of the operator overloaded.
In this case, C# is more productive than VB.NET.
Those are thus far the only two differences I've encountered between C# and VB.NET. I think the COM support is better in VB.NET as well, but I won't go there in this post.
Thanks,
_Shawn
Hi _Shawn,
Interesting. I am going to check out your simulator/emulator. I have a couple of Apple 2gs 65816 emulators that I am playing with now, on occasion. IIRC BASIC never did operator overloading (other than + for concatenating strings), so adding that to VB .NET will be something I will find fascinating. VB classic was not object oriented, it was object based at best. VB .NET is object oriented, so I'd expect operator overloading to be a natural extension. Now wrt controls and their raise events, I haven't noticed any troubles with VB .NET yet. I do find C# to be the easiest C derived language for me to use, though.
Live and learn :alright: .
Thanks for the heads up
Charles
Interesting. I am going to check out your simulator/emulator. I have a couple of Apple 2gs 65816 emulators that I am playing with now, on occasion. IIRC BASIC never did operator overloading (other than + for concatenating strings), so adding that to VB .NET will be something I will find fascinating. VB classic was not object oriented, it was object based at best. VB .NET is object oriented, so I'd expect operator overloading to be a natural extension. Now wrt controls and their raise events, I haven't noticed any troubles with VB .NET yet. I do find C# to be the easiest C derived language for me to use, though.
Live and learn :alright: .
Thanks for the heads up
Charles
cdquarles,
VB.NET does not supoprt operator overloading and it won't take advantage of it if you create a class in C# that overloads an operator. My Binary example above works in MC++ and C# but not in VB. You just can't do anything with it in VB.NET. Of course you can, but not with the operators and not implicitly. For example:
C#
VB.NET
The syntax is ugly, as such, I don't recommend it.
PS: I haven't completed the simulator. It got to be so repetitive entering the opecodes, their instruction name, and the clock cycles... I'll get back to it, I had a surgery about 3 weeks ago I'm still recovering from (not related to the repetition).
Thanks,
Shawn
VB.NET does not supoprt operator overloading and it won't take advantage of it if you create a class in C# that overloads an operator. My Binary example above works in MC++ and C# but not in VB. You just can't do anything with it in VB.NET. Of course you can, but not with the operators and not implicitly. For example:
C#
Binary8 bin = 0xFF;
bin -= "1011";
VB.NET
Dim Bin As New Binary8
Bin.Value = &FF
Bin.op_Subtract(11)
The syntax is ugly, as such, I don't recommend it.
PS: I haven't completed the simulator. It got to be so repetitive entering the opecodes, their instruction name, and the clock cycles... I'll get back to it, I had a surgery about 3 weeks ago I'm still recovering from (not related to the repetition).
Thanks,
Shawn
Hi _Shawn,
I had wondered what happened to you. I am glad to hear that you are recovering nicely from your surgery.
I understand that VB .NET does handle operator overloading now, but it is a natural extension in the object oriented paradigm; so I do think that it will be added to VB .NET. I think that it was mentioned in the Microsoft groups or on its site.
Wrt the ugly syntax, I don't mind if the job gets done. I am, after all, one whose first computer language was FORTRAN IV/66 on a mainframe using punch cards ;) .
Charles
I had wondered what happened to you. I am glad to hear that you are recovering nicely from your surgery.
I understand that VB .NET does handle operator overloading now, but it is a natural extension in the object oriented paradigm; so I do think that it will be added to VB .NET. I think that it was mentioned in the Microsoft groups or on its site.
Wrt the ugly syntax, I don't mind if the job gets done. I am, after all, one whose first computer language was FORTRAN IV/66 on a mainframe using punch cards ;) .
Charles