![Microsoft Microsoft](http://a.fsdn.com/sd/topics/microsoft_64100.png)
Anders Hejlsberg on C# 3.0 386
spongman writes "Channel9 has a video of Anders Hejlsberg demoing C# 3.0. The new language enhancements include implicitly typed locals, extension methods, strongly-typed lambda expressions, anonymous types, and LINQ - a builtin SQL-like syntax for data access. The spec, samples and a working compiler can be found on MSDN."
Who is Anders Hejlsberg? (Score:5, Informative)
I did not know he was very instrumental in developing Pascal, a language I was an expert at one in the mid nineties.
Re:Who is Anders Hejlsberg? (Score:4, Insightful)
Why implicitly typed locals? (Score:5, Insightful)
Can someone explain the point of this? C# is not JavaScript; these aren't true dynamically typed variables, the compiler just assigns a type for you instead of making you do it yourself. I can easily take half a second out of my day to figure out what type a variable should be, and end up with more readable code.
Re:Why implicitly typed locals? (Score:5, Insightful)
It also allows you to write pieces of code that are more generic. The LINQ samples have a lot of examples of this.
For example:
foreach (string s in collection) {
Console.WriteLine(s);
}
means you have to change the type everytime you change the type in the collection.
foreach (var item in collection) {
Console.WriteLine(item);
}
means that you can use it with any time that implements ToString, which is pretty much any type.
There are numerous other benefits from the type inference, and they become more apparent with lambda expressions, where you can write expressions like "x => x % 2 == 0" instead of writing the equivalent bool-returning delegate with a typed parameter.
Most of the new features of C# 3.0 are quite impressive and more importantly very useful.
Re:Why implicitly typed locals? (Score:3, Insightful)
However, this example of yours seems like a bad one:
If you're changing the type of the collection, a few for
Re:Why implicitly typed locals? (Score:2)
It will fail to compile if it really doesn't make sense. See my other post for comments on the danger of logic errors that remain here.
Re:Why implicitly typed locals? (Score:3, Insightful)
One of us is misunderstanding here, but I'm afraid it's not me.
There is nothing about inferred typing that requires things to be of some base "object" type. Indeed, in many languages that use it, there is no base type, nor even necessarily the concept of inheritance.
In the case of the code we were discussing:
it would be normal to deduce the type of item from the type of collection and the behaviour of the foreach ... in ... construct. That typ
Re:Why implicitly typed locals? (Score:2)
So just:
foreach (object o in collection) {
Console.WriteLine(o.ToString());
}
Or I'm missing something here?
Re:Why implicitly typed locals? (Score:2)
Re:Why implicitly typed locals? (Score:2, Insightful)
foreach (var item in collection) {
Console.WriteLine(item);
}
This example makes no sense.
Is "collection" a collection of objects or something more concrete? If it's an object collection, s/var/object/ in your example.
The compiler inferes the variable type at compile-time, not run-time. So "var" will become "object" anyway.
var i=5;
i="str";
Of course, maybe I got it wrong..
Re:Why implicitly typed locals? (Score:3, Funny)
Ahh, but just think of all those poor migrating Visual Basic programmers whose only expierience of a c type syntax has been a spattering of javascript. They'll feel right at home.
With any luck, we'll make programmers of them yet.
Re:Why implicitly typed locals? (Score:3, Informative)
One point of it is to allow you to use anonymous classes without having to declare them. Lets say you use LINQ to do a join between two tables - you can assign the result of the join to an implicitly typed variable and reference the fields, without having to give this new object type an actual name.
So (forgive screwy SQL-like syntax):
The variable result
Languages falling behind (Score:3, Insightful)
Perhaps. But then again, Java evolved very fast in its first few years, and a lot of what it evolved was crap, particularly the numerous poorly-considered additions to the library that now have to be supported pretty much forever. Policies on language features were made on evangelical grounds -- "We don't need templates!" springs to
Re:Why implicitly typed locals? (Score:2)
It's about saving time and typing effort. This C# 3.0 is honestly just a trivial hack though. Why bother with C# 3.0, when there's a
Re:Why implicitly typed locals? (Score:2)
Because Microsoft's weight is heavily behind C#, but not Nemerle. Ask any Visual J++ developer how much you can count on Microsoft's long-term support for proprietary languages that aren't their current pet. Caveat programmor. :-)
Re:Why implicitly typed locals? (Score:2, Insightful)
var q =
from c in customers
where c.City == "Seattle"
select new { c.Name, c.Age };
q would result in an implicitly typed collection of objects that contain Name and Age properties only.
Here [msdn.com] is a good description of using both
Re:Why implicitly typed locals? (Score:2, Informative)
Why implicitly typed variables? Anonymous types.
Today, you have C# code that looks like this:
Which you could replace with var:
However, with anonymous types, you can have code that looks like this:
Without var, what type would you declare this variable? You could declare it as object, but to access the object's Product and Price properties, you would still need to cast the variable to some type, and w
Re:Why implicitly typed locals? (Score:5, Informative)
The language is still strongly, statically typed, though - the following would throw a compile-time error:
Now, as to why this construct was added to the language in the first place: these anonymous types are useful when using LINQ to query a data source: expr and item are both given the appropiate type for the data they contain, with no need to explicity define the types. Most of the benefits of strong static typing are retained with this approach, and there's no need to define a type to store data for every weird query you run against the database.One benefit that is lost is the ability to share these types across assembly boundaries, which might be an issue in real, three-tier applications. On the other hand, if there's a need to pass data directly from the database to the client application, what's the point of having the middle tier in the first place? So, this might turn out to be a non-issue.
(My examples were taken or adapted from this white paper [microsoft.com], which is an overview of the LINQ project, including the new syntax added to C# 3.0.)
Re:Why implicitly typed locals? (Score:2)
myClass exampleInstance = new myClass("Test");
that they have to type the word "myClass" twice.
This way you can presumably type
var exampleInstance = new myClass("Test");
Not sure it's a major saving though...
Re:Why implicitly typed locals? (Score:2)
Iterator<AdvancedHashMap<HashingClass56,NestedKey
new Iterator<AdvancedHashMap<HashingClass56,NestedKey
when definining a complex generic type, not having to declare the full type for "i" makes sense, no?
Re:Why implicitly typed locals? (Score:2)
The alternative is Java, where everything extends from Object (requiring minimal typing stuff.)
Re:Why implicitly typed locals? (Score:2)
Check out this page [boost.org] to see why it'd be so useful.
Re:Job security (Score:2)
Re:Why implicitly typed locals? (Score:4, Insightful)
The one good rebuttal I got was that it really helps to declare types on function parameters; it serves as a kind of documentation of the intended use and operation of a function. Plus, of course, it allows the compiler to catch errors where the function you write doesn't have the type you say it does.
I guess that's also the reason Haskell programmers like to declare the types of their functions, even though it's optional in Haskell.
Re:Why implicitly typed locals? (Score:2)
I like dinking around in Lisp, PostScript or Forth from time to time but you quickly realize that wit
Re:Why implicitly typed locals? (Score:2)
You state, repeatedly, that large programs "without typing" or "without type checking" cannot be maintained. I think you're missing the point.
Most of the languages we're talking about here are strongly typed, and their code is naturally highly generic. Type inferencing doesn't leave a gap for run-time errors in this context, because you can't have type mismatches in the first place. This framework also avoids implicit conversions yielding accidental type coercion, a significant class of programmer error i
Re:Why implicitly typed locals? (Score:2)
People who complain about run-time type checking errors are obviously not running unit tests! They think that if their statically typed code compiles, it must be correct!
--jeff++
Re:Why implicitly typed locals? (Score:5, Insightful)
In a dynamically typed language, the answer is always yes because variables have no fixed type. But in C#, the variables still have fixed types; they're just hidden. You have to look at the declaration "var x = 5" and think "Hmm, I guess that's an int", just like the compiler does. And for declarations like "var y = SomeFunction()", you have to go look up SomeFunction to find out what type it returns before you can know y's type.
It might save you a split second of typing to write "var" instead of a real type name, but 6 months from now when you have to find a bug in that code, it'll cost you just as much time to figure out what type those variables are.
Solid evidence, please? (Score:5, Insightful)
Do you actually have any solid information to support your claims here, or are you just expressing your personal opinion as fact?
Almost all of the posters objecting to type inferencing here quote examples like your
as an illustration of how code is less readable without a type. Guess what? Code isn't very readable if you call your functions SomeFunction anyway, and writing or really doesn't help.On the other hand, if your functions and variables have meaningful names, you probably don't care whether the value returned is a float or a double most of the time. Type inference makes your code more generic, without losing any particularly useful information (if it is useful, you can still specify it), and the type safety of the system prevents the sort of
errors typical in languages like C.In other words, I see a lot of scare-mongering in this thread, but very little evidence that it's justified, other then people saying, "It's unfamiliar and I don't like it". Do you have anything more for us?
Re:Why implicitly typed locals? (Score:2)
If your code uses "out" or "ref", it's pretty much broken by design. There's good reason why most modern languages (Java among them) don't have these anachronisms. If you need to return several values, return a struct (many languages have tuples for that, but unfortunately C# doesn't).
The whole point is that instead of wasting time on this, you let the comp
Implicitly typed local are good (Score:2, Insightful)
* type names can get long, especialy when templates are used
* why do you want to do the compiler's work
* editor with intelisense will tell you the type for the expression in most cases so no need to repeat it
* you do not need to modify so much places if type changes during development
* and if you really want you can get the exact type, but mostly it is just waste of time
AFAIK, they are going to add this to C++ too
Not trying to be rude, but ... (Score:5, Insightful)
Re:Not trying to be rude, but ... (Score:2)
Re:Not trying to be rude, but ... (Score:2)
Re:Not trying to be rude, but ... (Score:2)
I'm starting to become tiered of flaming microsofties, so maybe I will just skip them.
...or you could consider not flaming them?!
Bashing MS is the whole point of this website... (Score:2, Interesting)
Are you a newbie? That is the whole point of this website.
If you don't want to bash MS, then go to some MScentric site and wax wonderful about their propietary crapola. Some that are on the MS payroll continue to espouse the virtues of MS here (perhaps you?!), but we all enjoy how much time, money and effort MS spends trying to alter the overall message of slashdot.org.
Lesson for MS to learn: FUD doesn't effect a community of a single mind and purpose.
C# will not replace Java. It is a wonderful Ja
LINQ (Score:2)
Re:LINQ (Score:3, Interesting)
Yep. If done right, it can completely eliminate the possibility of SQL injections. This is something that too few people realize, but with SQL injections being a very common kind of vulnerability, it's definitely worth putting some thought and effort in.
Way to go! (Score:5, Insightful)
Of course,
Re:Way to go! (Score:2)
PDC Keynote, day 1 (Score:3, Informative)
A lot of it is market-speak and sales, but it is a developer conference. The link can be found here: http://www.microsoft.com/events/executives/billga
The Microsoft Trap (Score:5, Interesting)
I work for a software house in London and we have a large VB6 application that has been built up over many years. VB6 has effectively been dumped by Microsoft, so our application is slowly rotting away. There is absolutely no way we can rewrite it in C# or VB.Net, we just don't have the resources. I suggested that we at least write all new components in C# and use interop, but that turned out to be a real pain, especially when trying to debug.
So what do we do? Spend a fortune rewriting our product in C# while our competitors (who may be using Java) continue to improve their products. And once we have eventually finished the rewrite, will Microsoft just dump
I have to wonder. If there had been a number of VB6 vendors, rather than just Microsoft, they could never have dumped VB6. In that situation we would have all just moved over to another vendor.
Is anyone else here in a similar situation?
Re:The Microsoft Trap (Score:2)
Maintaining a big database driven app. But I'm in a somewhat less nasty situation. We have this curious setting here, people keep coming up with new ideas for the program, and I keep implementing them. This is allowing me to simply decide that a change is radical enough so that I might as well rewrite that part in C#, and that's what I'm doing. For now it's going pretty well. Since it's an internal app, making people run two programs instead of one is quite possible.
It looks like Mono is progressing
Re:The Microsoft Trap (Score:4, Funny)
Yes! We has all these Apple Hypercard applications, then Apple dumped us like a hot potato! However, I'm prohibited from the /. "terms of service" from saying anything bad about Apple, or comparing Apple to Microsoft.
Re:The Microsoft Trap (Score:2)
Re:The Microsoft Trap (Score:5, Insightful)
Not that that actually matters, because most people are all still using Windows anyway, and will be for a long time.
Re:The Microsoft Trap (Score:3, Interesting)
Yes, we had a similar problem, made even worse by the fact we needed something that could scale a lot better than VB does.
The solution for us was to move to Java. Fortunately our company is growing at a resonably rapid rate so that we were able to adsorb the VB programmers who for one reason or another didn't want to move to Java into some other role.
We still have a few older customers running the old VB6 application but by end of next year they will all be moved o
Is Java falling behind? (Score:5, Insightful)
Java's language features, by comparison to C#, seems to be moving along at a glacial pace, only recently getting features like foreach loops, and generics.
I personally prefer Java because of Eclipse [eclipse.org], but Sun are really going to have to get a move on if Java is to remain competitive with C#.
Re:Is Java falling behind? (Score:2, Informative)
I'm not sure I'd call it a "glacial pace". There are plenty of enhancements being made to Java (the platform and language) beyond convenience enhancments. See JCP [jcp.org].
Re:Is Java falling behind? (Score:3, Insightful)
Re:Is Java falling behind? (Score:4, Insightful)
Now it is true that as a more widely used (on the Enterprsie level) language, Java is going to move more slowly than C#. C# is newer and trying to take mindshare from Java, so it must move faster. Just having a great IDE is not enough.
Re:Is Java falling behind? (Score:3, Funny)
Even worse, C's language features don't seem to have moved since the late '70s. Thank god no-one is still using that any more.
Phillip.
Re:Is Java falling behind? (Score:2)
Language Bloat? (Score:4, Interesting)
Heck, it took me years to learn all of the components in C++, and I'd bet that the specification for the complete language is now much smaller than C#'s. And there's still stuff waiting to be discovered on the level of template meta-programming.
Is all of the stuff they keep adding actually useful? Or is it just being added so that they can give the impression of progress, and maybe convert more people to using it? Granted, I'm excited about C++0x, but unlike what I would be thinking if I used C#, I'm not worried because I trust the standards body to not put completely unnecessary stuff into the language. What do you C# programmers think?
I just realized... (Score:2)
Re:Language Bloat? (Score:3, Informative)
BUT, for those people that DO want to use them, they provide powerful features that would require either a lot more work, or couldn't be done at all. Or, the features make the language safer, and less error prone for certain tasks.
Lots of people still write C++ code as "more strongly type C" or "C with classes". They don't use templates, or over
Re:Language Bloat? (Score:2)
Microsoft May Have a Future (Score:3, Interesting)
Now, too bad management will keep on trying to tie
If only the
But no
Where's the Kitchen Sink? (Score:5, Insightful)
Why, oh why must language inventors continue to add every possible concept to their pet project? Must every language try to be everything to everyone?
No programming language is suited to all applications; anyone who claims omnipotence for their particular language is exhibiting either ignorance or arrogance. A wise programmer knows how to use many tools in appropriate contexts; it's this sort of rational maturity that separates amateurs from professionals. It makes no more sense to develop a web-hosted applet in C++ than it does to write a high-performance batch-processing engine in Java. Using multiple programming languages isn't a simple matter of syntax -- it's a matter of divergent perspectives that force me to think about what I'm developing.
A disturbing trend has emerged in the last decade, with developers trying to make every programming language applicable to every task; we add object-oriented features to COBOL and Fortran, add generic types to Java, and expand the C++ library with a plethora of complex templates. Now C# is "borrowing" all sorts of ideas from all over the map, without any thought for how all these pieces fit together into a cohesive and logical whole.
In the end, we get bloated tools that include features ill-suited to their core design. Instead of focusing on a clear set of goals, languages compete in an edless feature competition that often ignores sound engineering practices.
I have done professional C# programming, and the language does not impress me. Certainly it has some very good ideas -- but it lacks any sense of cohesion in design or intent, and it's ties to Microsoft make me leary of using it for long-term coding projects.
Re:Where's the Kitchen Sink? (Score:5, Insightful)
This will make me a lot more productive and I'm going to install it ASAP!
Re:Where's the Kitchen Sink? (Score:2)
In C#'s domain, improved database connectivity is very important. Heck, I've been known to write a bit of VB or C# when the situation calls for it -- if I want a quick Windows app, I reach for C#, not C or C++. However, I don't do very much platform-specific work anymore, and Mono notwithstanding, .Net-tools aren't really appropriate to the code I develop.
Re:Where's the Kitchen Sink? (Score:2)
Isn't the whole point of the
Makes me wonder why they bo
Re:Where's the Kitchen Sink? (Score:3, Insightful)
This isn't just a random heap of features. They all combine to create the query syntax which can run in-memory as C# code or be translated to external query languages such as SQL or XQuery and sent to a remote server for execution.
No programming language is suited to all applications;
But C# with embedded query syntax is an elegant solution to bridging high le
Re:Where's the Kitchen Sink? (Score:2)
True, true... *shaking head* all those nice people, if only they knew ho
General vs. specialist languages (Score:3, Insightful)
I think there's a lot of truth in what you wrote there. That said, while specialist languages have their place, I'm increasingly wondering why no-one has yet produced the next great general purpose language.
Why can't we have a simple, elegant syntax like much of Haskell or Python, with punctuation frenzies reserved for things like regular expressions and printf formats where history shows they work well? Why can't we have a grammar that's amenable to parsing by automated tools, to make it easy for IDEs to
Re:Where's the Kitchen Sink? (Score:2)
The point of my original post is: Real programmers use concise tools that are appropriate to the task at hand.
The more you complicate the plumbing, the easier it is to plug up. Creeping featurism is the major source of bugs in software today -- the more features, the harder a program is to implement, test, and debug.
As for assembler: I don't do much of it any more, except on certain performance-critical inner loops, and only then if the app is guaranteed to be platform specific. Otherwise, I stick to
Microsoft and innovation (Score:5, Insightful)
This is a terrific example of honest-to-god innovation from Microsoft.
Yes, I know, the building blocks have been available in some form or another in many other platforms. But so far nobody has managed to bring all of this together so elegantly.
The features are not just a random heap of syntactic sugar. They combine to create the query syntax (using lambdas) which can be either executed directly in C# (with the help of external methods) or be available as a runtime data structure (shades of lisp) that can be translated dynamically to an SQL or XQuery and sent to a remote server for execution. The type inference ensures that the query syntax is not littered by type declarations yet remains typesafe.
Nice work, Anders. I guess the Comega team deserves much of the credit, but I have the feeling it was Anders who brought it all together into a clean and not too "academically smelling" framework.
Microsoft and Lisp - Innovation? (Score:3, Informative)
ECMA or Microsoft Standard? (Score:2, Interesting)
I have just one problem with it (Score:3, Interesting)
The problem is that MS strongly ties the language with the IDE.
That is, whenever C# (or Visual [anything] for that matter) gets new features, we have to buy a new version of Visual Studio to take advantage of it.
For every developer that may work on a project that will use these new features (and our developers tend to move around).
I have run into several annoying bugs and limitations in the
Now C# 3.0 comes along. Will we have to upgrade to VS 200x yet again?
With these forced upgrades, MS has effectively implemented a subscription model for their software.
Re:I have just one problem with it (Score:4, Interesting)
What forced upgrades are you referring to? I must be missing something here.
Greenspun's Tenth Rule of Programming (Score:3, Insightful)
These changes to C# bring it closer to Common Lisp, and therefore make it easier to include those ad hoc implementations of it.
Re:Looks more like Delphi every release (Score:5, Insightful)
What are you talking about? I used Delphi for years, and then switched to
The toughest thing about this sort of technology, though, is that it isn't complete and usable in real projects, so as developers we're uncertain how much time to waste playing with the demos and learning (how many developers must be pissed seeing the hype machine starting over C# 3.0, when they still don't even have the ability to use C# 2.0 in production - e.g. VS.NET 2005 is only at the RC stage). Unless you're a blogger or writer making money writing about how much it makes you wet your pants, there's just no practicality in it.
Re:Looks more like Delphi every release (Score:3, Interesting)
On the contrary, it is big step backwards. One area of intensive research in IT for years is setting up a portable high-performance disconnect between database and other tiers. For many applications the database is just a resource, and embedding query languages within code is a bad idea. If you look at transparent persi
Re:Looks more like Delphi every release (Score:5, Interesting)
It is high-performance. Watch the demo - at one point Anders sets up a log, and you can see that the LINQ query was transformed into the appropriate, performant T-SQL which is passed to the RDBMS. It isn't doing the standard, shittacular "pull everything back in a terribly unscalable manner and then filter it in the middle tier", but rather appears to be analyzing the whole of the query and communicating it effectively to the source.
Embedded SQL in computer languages has been around for a very long time
It isn't embedded SQL. It's set operations that obviously share commonalities with SQL, but are largely different. Again, have you watched the video or read the spec? DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).
Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.
I doubt it'll include support either, out of the box. Instead, like always, they've created a generalized data services layer that any provider can plug into - create a ADO.NET 3.0 data provider for MySQL, and your data service can be the target of LINQ operations.
Re:Looks more like Delphi every release (Score:3, Interesting)
It isn't embedded SQL. It's set operations that obviously share commonalities with SQL, but are largely different.
I should have said 'embedded query languages'. My point stands... this is new.
Again, have you watched the video or read the spec?
Yes.
DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).
Nowhere in the information can I find terms such as 'persiste
Re:Looks more like Delphi every release (Score:5, Informative)
turns into
Of course, if you don't like it you can always pass strings of SQL text to the data layer, or do everything with StoredProcs -- after all, DLINQ helpfully shields you from ADO.NET but nothing stops you from using ADO.NET either directly or through alternate layers like NHibernate.
This should also answer your point about optimised SQL generation
Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.
They don't have to. Implementing DLINQ is really as simple as implmenting a pattern (which Helsberg called the 'query expression pattern') and adding your own DB-specific code.
Currently Oracle and DB/2 ship libs for ADO.NET, you can be quite sure they'll ship libs for DLINQ. If the MySQL and Postgres communites want DLINQ support badly enough, I'm sure someone will write it.
Re:Looks more like Delphi every release (Score:2)
I did.
This isn't 'embedded SQL' in the sense of Pro*C -- the 'queries' are really a bit of (helpful) syntactic sugar over an object-oriented, typesafe set of expressions (you'll see the lambda expressions, new to C#, used heavily here):
It is still an embedded query language. This encourages a
"Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc."
They don't have to. Implementing DLINQ is re
Re:Looks more like Delphi every release (Score:2)
Only for extremely simplistic cases, eventually you _will_ need to write queries.
Only minimal ones, which is why I used the phrase 'almost all'.
However, you don't use the database's native query language, you use one provided by the ORM tool. This appears to be the same sort of thing....
Indeed, but possibly lacking major features of other mat
Re:Looks more like Delphi every release (Score:2, Insightful)
Fat clients? You do know that the majority of
Re:Looks more like Delphi every release (Score:2)
I'm not trolling, but I had no idea. Can anyone verify this? I don't have any experience in Delphi and the Wikipedia entry is not much help.
In any case, I'm pretty excited about the new features, as they were the exact things that I often needed but did not have. And it's about time we got querying in-language (although anonymous methods can also do the job most of the time).
Re:Looks more like Delphi every release (Score:2)
Re:Looks more like Delphi every release (Score:5, Informative)
For existing languages that offer similar features in a braces syntax, see Nemerle [nemerle.org] or Scala [scala.epfl.ch].
(Languages like Ruby offer related features, but their lack of static typing means they're more distant cousins.)
Re:So what? (Score:2, Informative)
Re:Next version : line nunbers (Score:2)
Re:Can someone explain the advantages of C# over V (Score:2, Insightful)
I'll just give you the top reason that I use c#.
In VB.NET, Build and Rebuild are the same thing! If you change one class and do a build, on a large project it can take MINUTES.
The same project and change in c# can take SECONDS to build.
The time savings alone could buy a lot of stuff.
Re:Can someone explain the advantages of C# over V (Score:2)
Personally, I hate just about every aspect of VB.NET's syntax. Too wordy and inconsistent. 'List (Of Integer)' instead of 'List<int>', 'CType(x, String)' instead of '(string)x', etc.
A more objective advantage is C#'s support for unsafe code. If you need to do high-performance bitmap operations, or pass pointers back and forth to native code, you can't do it in VB.
Also, the yield keyword is simply awesome if you need to implement IEnumerab
Written in both-- (Score:4, Insightful)
My VB apps were much quicker to prototype- to provide something to a customer in helping them determine requirements when they aren't really sure what they need. Also, the VB apps are often easier to maintain (less cryptic code can be easier to maintain).
My C# apps were usually written in that language because the client had a preference for it- not that any logical reason was given (unless you count putting C# in marketing information to justify higher costs). Also, because the lanugage can be more difficult to follow (meaning less likely the client's in-house developers can code or update it) than VB, consultans can often charge a higher hourly rate to code in it.
Both languages build to the same IL output.
Comments such as this one from above a great language for people who don't want to know to much about what thier program is actually doing - but VB
show a real bias whilst not providing any detail whatsoever. So take them with a grain of salt. Unless your reading machine language, you don't really know what your appp is doing.
It is possible to write great code in each. It is also possible to write really bad code in each. It comes down to the developers ability and preferences.
If you have a nice fat contract and want to perch in your ivory tower looking down upon the commoners, go with C#.
If you have demanding clients and need to give yourself some breathing room, go with VB.
Re:Can someone explain the advantages of C# over V (Score:2)
Re:Seems to get more like Ruby, Python and Delphi (Score:2)
* People often cite performance, but there's no reason a Ruby program couldn't perform comparably to a C program. Yes, Ruby is interpreted, dynamically typed, and all that, but with enough effort, a compiler could be built that optimized away unused
Not really (Score:3, Informative)
You might think C# is moving away from being strongly typed with the new "var" construct, but you would be wrong. All types are still inferred and verified by the compiler.
As IDEs and compilers grow more powerful, I think people will start to realise that strongly typed lang
Re:Not really (Score:5, Informative)
Re:Not really (Score:2)
My experience so far even with stuff that has tens of thousands of very well refactored code is that static typing has caused me more problems then it has solved.
Mostly because type systems are not very good and most bugs I run into have nothing to do with o
Re:Not really (Score:2)
So while I'm with ya on the whole "python is strongly, dynamically typed," and "c is weakly, statically typed" thing, if you were to go out to textbook CS, you might have
Re:Not really (Score:2)
Now, you will see some theoretical CS types argue that dynamic typing doesn't constitute typing at all, i.e. that tagged values are not the same as types in a type-theoretical sense. However, I've never heard any of them claim that C is strongly typed eithe
Re:Not really (Score:3, Insightful)
not a good solution for multi-K-line programs written by large teams of programmers.
Re:Not really (Score:4, Informative)
Static types are just a very weak form of formal specification. A stronger form would be something like contracts (preconditions, postconditions and invariants) as used in things like Eiffel and D and SPARK, which allow you to specify not just the type of the inputs and outputs, but specific properties that are required of them. Another step up the formality chain again requires you to be very explicit in your specification allowing the contracts to be statically checked prior to compilation - that covers all the code paths and doesn't require runtime checking - and properties of the software to be formally proved.
Static typing finds maybe 10% of the possible potential errors in your program at the expense of doubling the effort to write and understand it. In some cases static typing may be a necessary evil to attain the required execution speed, but as a "safety" feature any benefits it provides are outweighed by the complexity it adds to your code.
Whether the benefits you gain from any level of formal specification, be it static typing or full formal methods, are worth it depends on how badly you need to be sure the system works and how costly any errors are. For some systems it really isn't that important - having a prototype or working code is more important that catching every last glitch. For other systems (security, avionics, banking and finance software etc.) any sort of glitch, bug or exploit is sufficiently costly that the extra effort to catch as many errors statically as possible is going to be worth it. There is also a spectrum of different needs in between.
As another note, static types needn't complicate your code as much as you might imagine. Try looking at a language with good static types (SML or Haskell come to mind) and you'll see that static types can be quite easy and require very little extra work (in comaprison to static types in other languages).
In my experience static vs. dynamic typing is really a matter of how well I've managed to nail down exactly what sorts of data structures I'm going to use. If I'm still doing exploratory/prototype/research code then dynamic types win out every time because they provide incredible flexibility. If I have nailed down what data structures I want to use then static types aren't any extra work and provide and extra buffer of safety.
Jedidiah.
Re:Such a pity (Score:2)
It is nice that C# exists, and it has a lot of nice features, but I fail to understand you 'raw productivity' statement. How is C# more productive to code in than, say, Java 5? I'm not dissing your opinion, I just want to see some solid reasons. I think that the existence of C# is good for everyone as it will drive innovation in Java, and vice versa, but I don't see where it has massive advantages overall.
I do like C# slightly better than Java 5 but that's not the big difference. It's the tools. VS.NET
Re:Such a pity (Score:2)
As a company, they have become used to rapid revenue growth. They have sustained this, in the past, by increasing their customer base. In the future, it is very likely that they will try to maintain revenue growth in two ways. The first is by expanding into application packages at the expense of the VARs. The other is by milkin
Re:I recomend Java (Score:2)
It's much better, runs everywhere and is already used by many big vendors. I strongly recomend Java.
That's nice to hear. Fortune 500 companies are always interested in recommendations by Anonymous Cowards.