 |
|
|
Yeah, but there are many web applications in production that use C#. BankOne for example.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
|
|
I like C#. As a self taught programmer (6 years in the making), I have shied away from C++ as it seems to be a bit nasty and you have to be really careful with memory etc.
C# seems to be really easy to pick up though, and essentially learning it is about familiarising yourself with the class libraries, followed by a bit of syntax familiarity (which isn't really important as its all there in the f1 key and code complete etc), and getting your head around method overloading etc.
If you wonder about cross platform compatibility being an issue, see how many people you can find that have used Java for its portability. I am sure people do use Java because of this, but I wonder in reality how often their efforts are actually ported.
I reckon C# will survive for a variety of reasons, one of the most significant perhaps being that the chap that headed up the development was the guy that essentially invented Delphi, now in its 8th version. That's pretty good staying power!
Jase 
|
|
|
|
|
|
|
What I find funny, is they created VB.NET. That is one of the most ridiculous and ugliest languages I ever saw, and useless, since it produces the same assembly as C#.
The only advantage I see in VB.NET is to improve your typing skills
|
|
|
|
|
|
|
Hee hee hee.
I think they made it because a lot of people who make decisions about what languages to use etc are not really technically savvy enough to understand the only real difference between C# and VB.net is a bit of syntax and VB doesn't seem to be able to do some of the things that C# can (though I couldn't name any, hearsay only). If Microsoft removed VB.net, loads of people would be panicking about there not being a VB like product in Vis Studio (even though we know that VB.net is closer to C# than it is to VB!)
Its a shame really, because lots of jobs advertising VB.net are going to be difficult to get if you profess to only know C#. I guess the solution is to lie a little on the grounds that if you know C#, you essentially know VB.net.
jase
|
|
|
|
|
|
|
Profox Jase @ Sitel wrote:
the only real difference between C# and VB.net is a bit of syntax
Not true. VB.NET has quite a few features C# doesn't have, among them late binding, declarative event wiring, a more refined select/case ("switch") struture, interface mapping, paramaterized properties, and the when clause in exception handling.
I got all this info from here. It has a few more, plus examples.
-Domenic Denicola- [CPUA 0x1337]
“I was born human. But this was an accident of fate—a condition merely of time and place. I believe it's something we have the power to change…”
|
|
|
|
|
|
|
Domenic [Geekn] wrote:
VB.NET has quite a few features C# doesn't have, among them late binding
Not sure I would call late binding a good feature, but hey, if you don't care about performance that's good.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
|
|
And yet, C# is about to get generics, iterators, anonymous methods, and partial types. Besides that, C# already has unsafe code/better interop story, XML documentation, operator overloading, granular overflow checking, unsigned data types, ability to declare a variable in a for() statment (VB.NET has this in VS.NET 2003), better distinction between arrays and methods ( VB uses parens everywhere, C# uses parens only for methods, [] for arrays ), and finally C# doesn't allow sloppy namespace work.
Hmmmm....I like my features better...
any idiot
can write haiku you just stop
at seventeenth syl
-ThinkGeek Fortunes
|
|
|
|
|
|
|
And more. This time I'm just taking directly from the site:
Declarative Event Wiring - This alone is why I will only use VB.Net for
WinForms
With VB.Net, you can declare events with the WithEvents clause. You can
then wire the event to a function with the Handles Clause. Example...
Private WithEvents MyButton
Private Sub ClickHandler(~) Handles MyButton.Click
//do something
End Sub
With C#, you have to wire events at run time. That makes it hard to
determine what control is wired to what event handler. Note that VB does
support runtime event wiring in case you need it.
Preliminary Diagnosis: Crap
Reason: All that does is hide all the delegate work from you. I was shocked to hear Mark Dunn and Carl Franklin on the .NET Rocks show say that it was odd how VB.NET converts delegates to MultiCastDelegates for you. If they would use C# (they're both VB.NET die hards), then they would realize that you have to have MultiCastDelegates for event wireups...otherwise you could only have one client for the event...and that's stupid.
C# still doesn't have a decent Select Case structure. You can't even write
something g like...
Select Case Grade
Case Is >= 90 : Return "A"
Case 80 to 89: Return "B"
Case 70 to 79: Return "C"
End Select
Preliminary Diagnosis: Slightly Viable
Reason: I don't want to get into a discussion of the MSIL here...but in the type of case that they use, it would be faster to use multiple else if statements than to use a switch/case statement. And the places where it's faster to use a switch/case scenario is not an integer case where you can say x to y. So while the example used is flawed, this is truly a feature, albeit a worthless one, that is in VB.NET and not C#.
C# doesn't support interface mapping. Every interface method must have the
same name as the real method. Thus you can't write...
Public Close() Implements IDisposable.Dispose
Instead you have to create a separate Dispose method that calls Me.Close.
Preliminary Diagnosis: Utter Crap and Horrible Technique
Reason: Okay, when I know that an object implements an interface, I'm going to look for the members of the interface. For instance, the IComparable interface, I'm gonna look for the CompareTo method. If I don't find it, I'm going to get frustrated. Then, I'll just be really pissed off when I find out it was hiding behind another name. That's horrible technique and a really bad "feature."
C# does support parameterized properties, other than the default indexer.
Thus C# can have...
MyCollection(5) //which is the same as MyCollection.Item(5)
....but not...
MyCollection.Key(5)
Note: There is a hack to give you the second version. The Key property can
return a inner class that has a default indexer, but it is messy.
Preliminary Diagnosis: True
Reason: Probably the only truly useful thing they point out. I have no argument here.
C# doesn't support all of the CLR error handling features. Specifically, the
When clause.
Try
//something
Catch Err as Exception When Debug=True
//version A
Catch Err as Exception When Debug=False
//version B
End Try
Preliminary Diagnosis: Semantics, Splitting hairs, aka: Crap
Reason: Has he ever heard of #if DEBUG? Or how about the ConditionalAttribute? Having that type of stuff embedded in the code itself seems ugly to me. I'd rather look at an attribute(which stands out) that says that it's only valid while debugging than have to wade through the already verbose VB.NET code.
Someone else posted about the optional keyword. But if you think about it, all that does is emit a bunch of overloads. Don't you think it would be better to know that you're getting multiple methods in your IL rather than thinking it is only one method...which is how most VB developers think. For instance look at this:
Jonathan Allen
"Optional Parameters have an advantage over Overloading when there are a lot
of options, especially of the same type. Below is a function that loads a
Combobox with info from a database. It cannot be simulated with overloads
because of the two optional Strings and two optional Booleans. And even if
it could, we are talking about 16 functions to do the work of 1.
Public Sub cLoad(ByRef o As ComboBox, ByVal IndexField As String, ByVal
TextField As String, ByVal Table As String, Optional ByVal OrderField As
String, Optional ByVal WhereText As String, Optional ByVal Clear As Boolean
= True, Optional ByVal SelFirst As Boolean = True)"
We're talking about a massive amount of functions here. There are way more efficient ways of doing things.
Same person said that VB.NET has
"Full background compile (not just syntax check) in the IDE
Additional in-built functions (OK, they can be called from C#)
Implicit typecasting (not necessarily a good thing!)"
Like he said, the implicit casting is not a good thing. The full background compilation whenever you hit a new line is just annoying and overbearing. For instance, in C#, I can skip around to find something that I want without it yelling at me that I'm missing a Catch statement or an End If. Also, those "Built in" functions aren't part of VB.NET, they're part of the framework, albeit in the Microsoft.VisualBasic namespace.
That's just my two bits...
any idiot
can write haiku you just stop
at seventeenth syl
-ThinkGeek Fortunes
|
|
|
|
|
|
|
David Stone wrote:
Has he ever heard of #if DEBUG? Or how about the ConditionalAttribute? Having that type of stuff embedded in the code itself seems ugly to me. I'd rather look at an attribute(which stands out) that says that it's only valid while debugging than have to wade through the already verbose VB.NET code.
Its not quite the same, they picked a horrible example because it is easi to confuse whether something is happening at runtime or compile time.
To give a little better example:
Try
...
Catch e As Exception When conn Is Nothing
[block1]
Catch e As Exception When someVar = otherVar
[block2]
End Try The same in C# would be:
try
{
...
}
catch( Exception e )
{
if( conn == null )
{
[block1]
}
else if( someVar == otherVar )
{
[block2]
}
} The VB.NET version is more clear in what is happening because you see at the catch level the condition on whether that code will be executed instead of having to go into the entire catch block for that exception type.
I might have the C# code wrong, because I can't remember (nor find) if multiple catch..when block will be executed or only the first matching.
James
"It is self repeating, of unknown pattern"
Data - Star Trek: The Next Generation
|
|
|
|
|
|
|
Quite true . I was just trying to point out that there are quite a few important differences between the two, and your points only strengthen that.
C# forever! 
-Domenic Denicola- [CPUA 0x1337]
“I was born human. But this was an accident of fate—a condition merely of time and place. I believe it's something we have the power to change…”
|
|
|
|
|
|
|
C# has late binding, you can read about it in Inside C# SE.
"We will thrive in the new environment, leaping across space and time, everywhere and nowhere, like air or radiation, redundant, self-replicating, and always evolving." -unspecified individual
|
|
|
|
|
|
|
Gah, I sit corrected! To be honest, of course, I've not really looked at VB.net, I really was just quoting hearsay.
Thanks for the link though.
Jase
|
|
|
|
|
|
|
It's an excellent tool to flock all the old VB'ers into .NET. When time comes, the VB-programmers will be ready to take the leap and use C# instead. Perhaps, VB.NET will be the final blow to VB? One can only hope.. 
--
Chatai. Yana ra Yakana ro futisha ta?
|
|
|
|
|
|
|
Jörgen Sigvardsson wrote:
Perhaps, VB.NET will be the final blow to VB? One can only hope..
Naaah. As I have said often VB still has it's uses while VB.NET is a joke. Two different things.
Laugh all you want but there are hundreds of thousands of small in-house applications written in VB all over the world.
Hopefully the same can never be said for VB.NET. I hatessss it.
Paul Watson
Bluegrass
Cape Town, South Africa
berndg wrote:
You misunderstand. The fridge... ...also has a web server for monitoring. Why?
So that you can see whether the light actually goes off.
Ahem. We can sink no lower.
|
|
|
|
|
|
|
Paul Watson wrote:
Hopefully the same can never be said for VB.NET. I hatessss it.
Really? I first came in contact with it when I wrote a couple of macros for the IDE, and I found it to be a much better version of VB. No more silly Set x = ..., and Func vs x = Func(). It felt a lot more mature IMO. Still too wordy though. 
Why do you hate it? 
--
Chatai. Yana ra Yakana ro futisha ta?
|
|
|
|
|
|
|
Jörgen Sigvardsson wrote:
Why do you hate it?
Because you have the easy language for the .NET Framework (C#) and then you have the powerful but hard language too (C++.NET.) Where is VB.NET supposed to fit in?
Also it is a lie that VB.NET is easy for VB programmers. I gave it a bash and thought "sod it, the .NET Framework classes are the key and if I have to learn them then I might as well take the plunge and learn a reasonable language like C# as well."
And I have not regretted it. Edited a VB.NET ASP.NET app today and it just got on my nerves. No braces, silly endif, end sub, end function, end life type things. Also Namespaces are quite big in my line of work and with VB.NET a small thing is that the ASPX.vb file is not created with a Namespace in it. Small thing but if you miss it out things can go very wrong down the line.
The whole thing is that I was a VB programmer, I tried VB.NET for a day, swapped to C#, loved it, then had to edit some VB.NET apps and got very frustrated. VB.NET does not fit in anywhere. The options are C++.NET or C#. VBers can't hit the ground running with VB.NET in .NET from what I have seen.
Actually the whole thing is the big wooly blanket MS are pulling over VBers eyes. VBers go in thinking "woot, sucks to C# dildos I can do .NET cause I know VB and VB.NET is the same thing with extra bits." MS markets it like that. That then causes problems for Bluegrass when we have to get reliable contractors for .NET jobs. VB.NET contractors are cheaper, but not reliable. Clients don't see that and insist. Only once the shi'ite has hit the fan do they go "ok, lets go C#." Am sure there are good VB.NETers out there but why they are out there I don't know.
Hard to explain. Is why I would rather just rant and wave my arms about till people accept my point just to get rid of me.
Paul Watson
Bluegrass
Cape Town, South Africa
Macbeth muttered:
I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er
|
|
|
|
|
|
|
I'm sorry about the "loss of VB".
It seems to me though that you learned the .NET Framework using the wrong language then (or right, depending on how you look at it).
But now that you've learnt C#, then why not just go for it? Why the extra fuss about VB.NET? I see little or no difference in using C# over VB.NET.
I can't really comment on C++ .NET. Haven't used it, and I haven't really found a reason for it. I do most of my reusable components in COM/C++, and as far as I can tell, it's just a matter of creating a COM-interop for it to work with .NET applications. Why on earth would I want managed code in my C++ software? I like the thrill of writing dirty and unsafe C++ code. 
--
Chatai. Yana ra Yakana ro futisha ta?
|
|
|
|
|
|
|
Michel Prévost wrote:
What I find funny, is they created VB.NET.
No it is not funny. In fact it is damned terrible for those of us pushing the .NET Framework.
I ranted about this awhile back but the basic point was that VB.NET to me is a marketing tool to fool VB developers into getting started with .NET. They will think it is a good upgrade path, but about two steps beyond the point of no return (reminds me of a quote from Macbeth) they will realise their mistake and then have to switch to C#. Switching is while not difficult, still a waste of time. Best to pick up C# straight away when venturing into .NET, VB or no VB skills. I have lots of VB skills and found VB.NET to be a joke. C# was so much better. VB still has it's uses, but VB.NET should be canned.
The worst bit, and the bit that makes what could be a funny situation not funny, is that the C# contractors know about this pitfall. They see all the contractors claiming VB.NET knowledge at a pittance and ramp up their charges, because they see they will be needed to mop up the problems in any case. So our clients demand we do VB.NET because it is cheaper. Long run though it just causes hassles and long run all that VB.NET stuff will be forced to migrate to C#.
They may create the same assemblies but in real world business situations having both C# and VB.NET skills on hand is a PITA.
Ugh, horrid situation. I want to just get Bluegrass onto C# from the start, not even take the VB.NET detour. But the *apparent* skills base is VB.NET and we are going to get burnt. Ugh, ugh, ugh!
Michel Prévost wrote:
The only advantage I see in VB.NET is to improve your typing skills
Not even that IMO. I was editing a VB.NET project and the intellisense and autocompletion is absolutely out of whack in VS.NET. In C# you press enter to select the intellisense option, in VB.NET you must press tab. Hitting enter completes the whole line, puts in the brackets (even if it is not a method!) and then line breaks. So damned frustrating.
Oh dear. I feel another VB.NET rant coming on... if the above is not a rant already!
Paul Watson
Bluegrass
Cape Town, South Africa
berndg wrote:
You misunderstand. The fridge... ...also has a web server for monitoring. Why?
So that you can see whether the light actually goes off.
Ahem. We can sink no lower.
|
|
|
|
|
|
|
Paul Watson wrote:
Oh dear. I feel another VB.NET rant coming on... if the above is not a rant already!
Yes, and a bit of sarcasm too..
|
|
|
|
|
|
|
Michel Prévost wrote:
and useless, since it produces the same assembly as C#.
I don't think it does. I've got a funny feeling C# is more optimised. Oh yes.
Quote from a clever bloke :
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein
|
|
|
|
|
|
|
I am guessing it will be relegated to back end/server work for Web apps. It may (we can only hope ) start being used instead of COM/DCOM stuff. But you never know, becuase...
Cons:
1. In many cases, it is still impractical to make your customers download and install the .NET framework. Not an issue with XP, or if you are shipping physical CDs and have plenty of space. Big issue for client-side Web apps or small, downloadable stand-alone apps.
2. AFAIK, templates/generics still aren't there yet. (You won't see me touching it until they are there.)
3. Upgrading compilers is expensive.
4. It's next to useless for low-level stuff. I doubt we'll ever see a driver, for instance, in C#.
Pros:
5. If .NET is ported to other platforms (Linux, Mac, etc.), and it actually works halfway decently, then C# becomes a cross-platform tool. Whether this will ever happen remains to be seen.
6. It's a halfway decent language.
You can pick your friends, and you can pick your nose, but you can't pick your friend's nose.
|
|
|
|
|
|
|
Agree 100%. Its main usage is for ASP.NET applications.
|
|
|
|
|
|
|
To be fair, there are heaps of articles on this site using C# for more than just asp.net.
Some great examples are Christian Graus' work with the image editing (although they do use some unsafe code).
Also, I reckon there are very few (any?) drivers written in Java. Don't get me wrong, I am not knocking Java, I have never used it after all.
I do agree with the points you guys make though, I am sure C# provides a far more elegant solution to forcing a browser to do something it wasn't originally intended for than old style ASP & VB script does.
Jase
|
|
|
|
|
|
|
Navin wrote:
1. In many cases, it is still impractical to make your customers download and install the .NET framework. Not an issue with XP, or if you are shipping physical CDs and have plenty of space. Big issue for client-side Web apps or small, downloadable stand-alone apps.
This will most likely be solved with the next release of Windows. The .NET runtime will be as standard as ole32.dll I reckon.
Navin wrote:
2. AFAIK, templates/generics still aren't there yet. (You won't see me touching it until they are there.)
It's on its way. Wheeee! You have no idea how happy that made me.
Navin wrote:
3. Upgrading compilers is expensive.
csc.exe is free, as in beer1 if I'm not mistaken.
Navin wrote:
4. It's next to useless for low-level stuff. I doubt we'll ever see a driver, for instance, in C#.
C# was never aimed at being the language of choice when it comes to drivers. This is where C/C++/asm shines, and I doubt that will change in any time soon.
Navin wrote:
5. If .NET is ported to other platforms (Linux, Mac, etc.), and it actually works halfway decently, then C# becomes a cross-platform tool. Whether this will ever happen remains to be seen.
We've already seen where that leads. It leads to the path of Java, where nothing works the way you want. The key to homogenous systems is not in the code but in the protocols.
Navin wrote:
6. It's a halfway decent language.
The only thing I have against it now is the single inheritance and object boxing. With generics we'll get a bit less boxing.
1 I use that phrase so I don't upset some GPL zealot for abusing the word free.
--
Chatai. Yana ra Yakana ro futisha ta?
|
|
|
|
|
|
|
Jörgen Sigvardsson wrote:
The only thing I have against it now is the single inheritance
But why not just simulate multiple inheritance with interface inheritance. There are disadvantages to multiple inheritance, it can get ugly, and ambigious detection of base classes.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
|
General 
News 
Question 
Answer 
Joke 
Rant 
Admin 
