|
To each their own. I frankly never liked C# - feels like VB sprinkled with semicolons and curly braces 
|
|
|
|
|
I thought that way for a while too, until I had to use it. I wouldn't use it for apps that require heavy computation, but for business apps its nice and much much better than VB.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: much much better than VB
Why, I converted to c# about 6 years ago and would not like to go back but that is mainly comfort and familiarity.
When I was doing VB I though the same thing about c#, imagine a language that is case sensitive bleh.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Well, to be fair, my comparison is really more about the bias I've built up against the typical VB crowd than the language itself. My first language was QBasic. I did a lot of classic VB. Never really had to use VB.NET all too much thankfully. It's a good tool for what it's intended for.
But the main reason would be I just don't like the mentality of the typical VBer, which is lazy when it comes to learning how to effectively program. Not all VB devs are like that of course, but you get the idea. I have the same issue with FoxPro devs.
I do think C#'s syntax is much cleaner and more elegant though. Which can lead to less typing errors. Which would be enough of a reason for me to choose C# over VB.NET, regardless of the typical VB crowd.
Jeremy Falcon
|
|
|
|
|
I think VBA is where you can lay the most blame, power users who work up through the VBA/Access route and keep going. No real discipline and no training. I started out that way and can understand the mind set, I do miss the formal training and grounding most really good devs must have.
I started with macros in the late 80s then went down the path of Superbase till it got completely marginalised, spent a couple of years doing Turbo Pascal and then moved to VB. I would not willingly go back to VB.net but only for comfort and familiarity not because I dislike the language.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I think VBA is where you can lay the most blame, power users who work up through the VBA/Access route and keep going. No real discipline and no training. I started out that way and can understand the mind set, I do miss the formal training and grounding most really good devs must have.
Oh man don't get me started on people using VBA inside Access to make a "real program". Totally get your point. But like you said, a good dev never stops learning and undergoes a lot of training about how things really work.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I wouldn't use it for apps that require heavy computation
I ended up re-writing a very computationally heavy app in C# from C++ and was quite surprised that the C# version performed as well, if not better, than the C++ version. Now, granted, I was using STL heavily in C++ and in the C# version, I optimized my data structures so I wasn't manipulating vectors and queues all over the place. Which just goes to show, that performance is less a function of the language than it is of the skill of the programmer. 
It would be interested to see how the code would fare in C++ now with the new data structures, but I'm a bit wary of STL's performance.
Marc
|
|
|
|
|
What you're saying is totally true, but I'd still wager an expert at C/C++/ASM could still write code to outperform most things in .NET. Of course, that's not practical for every last application as they'd have to be leery of frameworks used, if any, such as STL.
I mean I can write a slow program in C easy as pie, and probably make something run better in classic VB if I really wanted to. Doesn't mean classic VB is the way to go for real time code. It doesn't mean VB is quicker. It means I'd know VB better in that instance.
All that being said, I sure don't enjoy the slow compile times for C++. Especially with some of newer compiler tricks with C++ 11, such as generics. But it's still pretty zippy once compiled, and C/C++ will always be my go-to language for non-business apps.
Jeremy Falcon
|
|
|
|
|
I started in BASIC back in the 80's, and made my way through C, Perl, Java, and some dabbling in TCL and Python... But I haven't found anything better than C#.
Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere. The others I've tried all feel clumsy and weak. Well, I mean, Unity is several kinds of awesome, but that's a little different.
Now if only they would switch Excel's scripting interface from VBA to .NET, I could stop hating MS Office too.
|
|
|
|
|
Ian Shlasko wrote: Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere.
And I'm not an MS fanboy at all, but I recognize a good piece of software when I see it.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: And I'm not an MS fanboy at all, but I recognize a good piece of software when I see it.
Exactly... I generally dislike uSoft, but Visual Studio is just a work of art...
And honestly, so is Excel, as long as people use it as a spreadsheet/calculator and not an application platform...
|
|
|
|
|
Definitely - Excel is a superb piece of work. It's little touches, like CTRL+; inserts today's date that tells you is was designed by people who actually throw numbers around on a regular basis.
Mind you, that comes with a price: I have seen some total abortions done in Excel formulas (not even VBA). One guy I used to work for ran his entire stock control, estimating and build list production from a massive Excel spreadsheet. Damn thing took 15 minutes to load in the morning, and data entry was painful. Worked though...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Ian Shlasko wrote: Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere.
I will have to agree with that... I'm currently using Eclipse and it pisses me off on a regular basis.
Ian Shlasko wrote: Unity is several kinds of awesome
As in Ubuntu's Unity? ...there has never been a slower interface ever developed for Linux! I actually stopped using Ubuntu because of Unity, now I use Mint (grant it, it's still based on Ubuntu but with a better interface).
|
|
|
|
|
No no no no....
Unity 3D... The game development IDE...
|
|
|
|
|
Was wondering about that... it didn't make sense but I've also never heard of Unity 3D. 
|
|
|
|
|
I haven't actually managed to make anything playable with it, but that's because I aimed a little too high... Like... Alpha Centauri...
But I wrote a hex-map model and generator in C#/Unity, and it worked really well... It makes the graphical side really easy.
One of these days I'll go back to that... But once I started planning out the AI, I realized I had designed it so complicated that it'd make Black and White look like Tetris by comparison.
|
|
|
|
|
Ian Shlasko wrote: Haven't found a better IDE anywhere
The only IDE that comes close is the one made by JetBrains, which I use a lot for Ruby and Java stuff.
Marc
|
|
|
|
|
Marc Clifton wrote: frankly, C# is the most elegant and well crafted language I've ever worked with
Yes, it is.
Even though I still miss a QUICK compiler like Delphi had (and sometimes a linker), and aw, the joy of compiling your own VCL. Being able to allocate and deallocate by hand also seemed to be better than having the memory fill up until some lowpriority thread halts your app and starts cleaning up - even though NET4 does a good job at it, I'd rather still be doing it myself.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I agree - but it does mean it's a lot harder to get leaky programs. Not impossible, but a lot harder. You remember what it was like before C# - morons not releasing memory until the whole PC judders to a halt... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: a lot harder to get leaky programs
I disagree. When you're programming in something that demands you manage your own memory, you tend to be very aware of leaks, and program more carefully.
Many a C# programmer just assumes that it will be handled for them, and happily leave event handlers waving in the wind, preventing megabytes being cleaned up.
Not me, of course, but others
PooperPig - Coming Soon
|
|
|
|
|
_Maxxx_ wrote: When you're a competent programmer is programming in something that demands you manage your own memory, you tend to be very aware of leaks, and program more carefully.
Unfortunately, a large number of developers aren't competent, but think they are.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Most agree C# is good but times are changing again. First it comes with the overhead of the framework, undeterministic memory management with garbage collectors. Devices are getting smaller and competition on the server side is cutting into profits. Simply put in terms of performance per $ it cannot win on the server side and as mobile app with C++. We are slowly moving to true massive parallelism using GPU computing and it is doable with managed code going through some extra steps to bridge native and managed but why doing it? Modern languages tend to be more verbose. C++ code is terse, impressively logic and amazingly modern and relevant despite old age. C# facilities are nothing more than iteration of STL or Boost. The only advantage is UI but with Web front this is no longer main consideration in choosing the language. C# is evolving and there is nothing wrong with it (I am using .Net extensively) but looking forward, surprisingly, for many applications C# may not be the best choice.
|
|
|
|
|
Until VS2008 (more I don't know) I found a flaw that I hate: it is impossible to separate definition and implementation in separate files.
Also, it is slow to compile, it uses that crappy .NET framework with the crappier documentation and it is slow to compute unless you fill it up with unsafe.
I AM biased because I really need low-level functionalities, the only time I ued C# was to create a VS add-in to view areas of memory as 8 or 16 bit images and apply some algorithms and infinite zoom (with no blurring, must be exactly a pixel per pixel representation). The areas of memory come directly from the VS debugger on a running process, and it has to understand variable names, pointers, raw addresses and some internal data structures. With C# it is painfully slow, where the older counterpart of this add-in, developed in VB6, is fast as a Thunder (btw Thunder WAS the codename of VB6  ).
It has some good points, i like the UI designer and its way of managing events, but stil... I will hate the day we switch off VB6 and turn to C#.
|
|
|
|
|
|
Aye. I'm strange, I know, but it is easier (and faster) to make communications between two native environments than managed-native. Also the easy access to COM, OCX and WinAPI provided with VB is somewhat lacking in C#.
For projects that are no more than a boxed set of switches, VB6 is faster and easier. For project a little more complicated, .NET is bloated (to make I-don't-remember-which operation on a bitmap created in memory I would have to pin, extrapolate and use a ton of image converters between Windows.Media.Something.SomethingElse and Windows.Forms.Image forth and back. I solved wrapping GDI calls).
Of course this is my opinion, and I'm far from being guru or expert. I just hope that M$ changes its mind and releases a VB7. Native, updated VB6.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
