Am I the only one that thinks type inference is a bad thing?
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
C# and VB.NET have always had common goals. C# originated from C++ and moved away over the years, VB.NET originated from Classic VB and moved away over the years. Now they are both heading towards a common intersection. I guess one of the two languages will then be superficial and serve no additional benefit over the other. Maybe they'll unify the two languages and call it C#VB/CLI or something like that.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
C++/CLI in Action (*E-Book is out, Print version April 6th*) -
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
//Will eventually be legal, if not already.
not already, and never will be. at least hopefully. C# has data types, unlike classic VB. var get changed to a data type at _compile time_, var aint a data type, just a placeholder-kinda thing to make it easier for programmers. imagien a for loop with a short counter. now you need more items. no problem, it will change it all by itself.
:badger:
-
C# and VB.NET have always had common goals. C# originated from C++ and moved away over the years, VB.NET originated from Classic VB and moved away over the years. Now they are both heading towards a common intersection. I guess one of the two languages will then be superficial and serve no additional benefit over the other. Maybe they'll unify the two languages and call it C#VB/CLI or something like that.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
C++/CLI in Action (*E-Book is out, Print version April 6th*)That was Microsoft's plan all along, to bring in all VB programmers under the guise of C so that there won't be a split between programmers anymore. This way, any company can hire any programmer to do the work. It's one way to reduce the salary of the high-end programmers.
"Dissent is the highest form of patriotism." - Thomas Jefferson Web - Blog - RSS - Math - LinkedIn - BM
-
That was Microsoft's plan all along, to bring in all VB programmers under the guise of C so that there won't be a split between programmers anymore. This way, any company can hire any programmer to do the work. It's one way to reduce the salary of the high-end programmers.
"Dissent is the highest form of patriotism." - Thomas Jefferson Web - Blog - RSS - Math - LinkedIn - BM
Some of us will still continue to be paid more than others because we actually know what we are doing, regardless of the progrmaming language in use at the time ... :rolleyes:
-
Some of us will still continue to be paid more than others because we actually know what we are doing, regardless of the progrmaming language in use at the time ... :rolleyes:
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
c = a; //Will eventually be legal, if not already.
That is not legal. And, according to one of Microsoft's DPEs that I spoke to the whole idea is that it never will be.
varis strongly typed, and it can only be used inside a single method. You cannot pass around avardelclared variable except by casting it appropriately.
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
As mentioned by others, you didn't read that quite right. The
vardata type uses type inference, but it is still strongly typed. You can't change the type of the variable, whether its type was assigned explicitly by the programmer or inferred by the compiler.
if(!curlies){ return; }
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
I am not going to repeat what others have already said. Just to add that practiclly all modern statically typed languages support type inference (and no, Java doesn't count as a modern language) - even C++ is going to get it[^] in the next version of the standard. However, I agree that the choice of the keyword (var) is unfortunate. -- modified at 12:07 Friday 6th April, 2007
-
C# and VB.NET have always had common goals. C# originated from C++ and moved away over the years, VB.NET originated from Classic VB and moved away over the years. Now they are both heading towards a common intersection. I guess one of the two languages will then be superficial and serve no additional benefit over the other. Maybe they'll unify the two languages and call it C#VB/CLI or something like that.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
C++/CLI in Action (*E-Book is out, Print version April 6th*)If C# ever gets "if..then..endif" I am out of here ;) Seriously though, all .NET languages are superficial, they are pretty much the same at the end of the day, it is all about how you like to see the code, the syntax you want to use. We really only have one language under .NET and many faces. As for syntax though, the face of a language, C# is evolving into a very powerful face and I imagine this will continue. While there are features I do not care for in C# (like the nullible type specifier), the power that C# 3.0 brings along with linq is amazing coming from almost two decades of C/C++ work. It is more the evolving on .NET though than a specific langauge, the framework keeps getting more and more powerful. Our building blocks are becoming deep and rich which bubbles up in the langauges. I find some posts on CP kind of funny, they are concerned if they should learn C# or VB.NET as if that is the real issue under .NET. Learning either should only take a serious developer a few days or a couple of weeks at best, but it is the .NET framework that is the huge learning curve. Quite a vast framework to say the least :)
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Want to test Joost (video on demand) - I have invites!
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
No, C# isn't suddenly going to become JavaScript. The point of
varis to replace this:Dictionary<String, MyBigObjectClassName> dict = new Dictionary<String, MyBigObjectClassName>();
with this:
var dict = new Dictionary<String, MyBigObjectClassName>();
Or in C++, replace:
std::vector<std::pair<std::string, int>>::const_iterator it = someVector.begin();
with:
auto it = someVector.begin();
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Ford, what's this fish doing in my ear?
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
In vb.net you have the options to turn on Option strict and Option explicit making the example above illegal.
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Explicit casting should always be there.
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
c = a; //Will eventually be legal, if not already.
It's already legal in VB (well, sorta). But that's not what type inference is about. Think of it in terms of getting rid of some of the unfortunate side-effects that came from trying to combine C++ syntax with an object reference-centered runtime. Remember, K&R C wasn't anywhere near as strict about type-checking as modern C++ (or C#) is. This is about letting competent programmers get their work done with less redundant typing...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
-
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
With var, c will still be a string and a will still be an integer, it just saves having to type so much when dealing with really long templated types. It also allows for using variables in templated methods that can't be directly infered from the templated type.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Ennis Ray Lynch, Jr. wrote:
c = a; //Will eventually be legal, if not already.
It's already legal in VB (well, sorta). But that's not what type inference is about. Think of it in terms of getting rid of some of the unfortunate side-effects that came from trying to combine C++ syntax with an object reference-centered runtime. Remember, K&R C wasn't anywhere near as strict about type-checking as modern C++ (or C#) is. This is about letting competent programmers get their work done with less redundant typing...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I think that is they key there. Of course there are quite a number of people able to open visual studio and type that I would not consider in the category of competent programmers. Language candy, while nice, makes maintenance a nightmare.
Shog9 wrote:
This is about letting competent programmers get their work done with less redundant typing...
File Not Found
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Type inference != "type free" c and a are still strongly typed - only the type is inferred from initialization. So
c=ais not legal. And that's a good thing yes sire, especially since introduction of generics.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
In your example,
cis a reference to astringobject, whileaa reference to a (boxed) integer. Sincecis declared as a reference to anobject(and all types derive from object), you don't have a problem. But try castingcto astringand you'll see...Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Replace
varwithobjectand you can pretty much do that already. Excellent for those who think strongly typed languages are for bed-wetting types. Terrible for those who need to debug their programs. I appreciate the concept of a non-typed language but unfortunately we're still using bits to represent our data. Because of this I want to be sure that my fixed point and floating point values remain fixed point and floating point values. I also want to know when a numerical value gets converted to a string because sometimes I really, really don't need the overhead of that conversion. I spend(spent) way too much time with VBScript and Javascript to appreciate weakly-typed languages and their subtle bugs. Much easier having specific types than littering your code with cast operators to force your data into a given type. It makes me sad that applications are now aimed at the lowest common denominator, and sadder still that our development tools are following suit.cheers, Chris Maunder
CodeProject.com : C++ MVP