Propriety software as quality of life issue
June 12, 2011 12:06 AM Subscribe
I'm being interviewed for a job as a VB.NET programmer. I have a good chance of getting it, despite all my past experience being with Java/Perl/Python/C. I'm somewhat of an Open Source ideologue, and hate the idea of using Microsoft technologies, which strike me as not only technically inferior and frustrating to work with, but on the wrong side of history. I'm looking for other options, but assuming they don't come through before I'm given an offer will I regret taking it? Doesn't Microsoft itself consider VB deprecated? To what extent are the other .NET languages (C#) better?
I'm also worried about forgoing OSS experience in favor of something I'd hate to work with the rest of my life, if anyone even remembers it in a decade.
I'm also worried about forgoing OSS experience in favor of something I'd hate to work with the rest of my life, if anyone even remembers it in a decade.
VB.Net is in no way deprecated. Frankly, if you're asking that question, you need to do some cursory research.
VB.Net is almost literally line-for-line interchangeable with C#. Most people find it slightly more verbose - if you're used to semicolons, it's hard to give them up. My personal experience, being quite partial to C#, is that it takes a few minutes for my brain to switch to "VB mode", but past that transition, writing VB.Net code is extremely similar to writing C# code. Your fluency with the .Net API will immediately apply from one to the other, so if you keep up with the C# syntax (which is almost identical to Java), you'll basically be learning two languages at once.
The key thing to realize here is that VB.Net and C# programs both compile down to MSIL. While there are some very minor differences between what semantically-equivalent VB and C# programs will emit in terms of MSIL, for the most part they are identical once things are actually running. VB.Net is related to VB6 only in its superficial syntax.
VB.Net programs run on top of the .Net framework, parts of which are included in the CLI/C# ECMA standard; additionally, the Shared Source Common Language Infrastructure is a shared-source implementation of the CLI, not to mention Mono.
posted by 0xFCAF at 1:00 AM on June 12, 2011 [5 favorites]
VB.Net is almost literally line-for-line interchangeable with C#. Most people find it slightly more verbose - if you're used to semicolons, it's hard to give them up. My personal experience, being quite partial to C#, is that it takes a few minutes for my brain to switch to "VB mode", but past that transition, writing VB.Net code is extremely similar to writing C# code. Your fluency with the .Net API will immediately apply from one to the other, so if you keep up with the C# syntax (which is almost identical to Java), you'll basically be learning two languages at once.
The key thing to realize here is that VB.Net and C# programs both compile down to MSIL. While there are some very minor differences between what semantically-equivalent VB and C# programs will emit in terms of MSIL, for the most part they are identical once things are actually running. VB.Net is related to VB6 only in its superficial syntax.
VB.Net programs run on top of the .Net framework, parts of which are included in the CLI/C# ECMA standard; additionally, the Shared Source Common Language Infrastructure is a shared-source implementation of the CLI, not to mention Mono.
posted by 0xFCAF at 1:00 AM on June 12, 2011 [5 favorites]
I'm a .NET developer and have been so since about 2003. I've worked with VB.NET and C# professionally and in my own development.
Doesn't Microsoft itself consider VB deprecated?
Not in any way, shape or form. Microsoft's commitment to VB.NET remains strong. It is supported for use in ASP.NET, Windows Presentation Foundation, Silverlight, and so on. Microsoft has committed to support --VB6-- through the Windows 7 life cycle; there's no reason to think that VB.NET is going anywhere.
To what extent are the other .NET languages (C#) better?
VB.NET and C# both compile to the same code behind the scenes (for the most part), so the differences between the two are mostly syntactical. There are a few things that C# can do that VB.NET can't (anonymous delegates, if memory serves), but they are few and far between.
assuming they don't come through before I'm given an offer will I regret taking it?
Probably. Not because of anything inherent in VB.NET, but because you're an "open source ideologue" who "hates the idea of working with Microsoft technologies" even though your knowledge of them appears to be pretty thin.
posted by DWRoelands at 1:08 AM on June 12, 2011 [7 favorites]
Doesn't Microsoft itself consider VB deprecated?
Not in any way, shape or form. Microsoft's commitment to VB.NET remains strong. It is supported for use in ASP.NET, Windows Presentation Foundation, Silverlight, and so on. Microsoft has committed to support --VB6-- through the Windows 7 life cycle; there's no reason to think that VB.NET is going anywhere.
To what extent are the other .NET languages (C#) better?
VB.NET and C# both compile to the same code behind the scenes (for the most part), so the differences between the two are mostly syntactical. There are a few things that C# can do that VB.NET can't (anonymous delegates, if memory serves), but they are few and far between.
assuming they don't come through before I'm given an offer will I regret taking it?
Probably. Not because of anything inherent in VB.NET, but because you're an "open source ideologue" who "hates the idea of working with Microsoft technologies" even though your knowledge of them appears to be pretty thin.
posted by DWRoelands at 1:08 AM on June 12, 2011 [7 favorites]
VB.NET is certainly not deprecated. The language itself is not just wordier - it feels sloppy to me. While they do try to keep it feature for feature the same as C#, it's different in a number of ways.
C# is pretty good as far as languages go - I like it better than Java, especially for events, delegates, anonymous delegates, metaprogramming through attributes, and the using block.
There are a number of otherfully supported languages that target the CLI - they include C++/CLI (which grew from Managed C++), which for any kind of significant work with native code is *the* way to go, IMHO. There is F#, which is a statically typed functional language. I've used it for one real-world project, mostly for the ability to use inline functions and partial function applications which made my tasks much easier to get done and done right. However, I needed an LRU cache, which was trivial to implement in F# and ran like an effing dog with no good way to improve it - I wrote the LRU code in C# to the same API and it ran much better. You might also look at Boo, which I've heard a number of good things about. I looked at it several years ago, but it was not ready for prime time.
posted by plinth at 5:48 AM on June 12, 2011 [2 favorites]
C# is pretty good as far as languages go - I like it better than Java, especially for events, delegates, anonymous delegates, metaprogramming through attributes, and the using block.
There are a number of otherfully supported languages that target the CLI - they include C++/CLI (which grew from Managed C++), which for any kind of significant work with native code is *the* way to go, IMHO. There is F#, which is a statically typed functional language. I've used it for one real-world project, mostly for the ability to use inline functions and partial function applications which made my tasks much easier to get done and done right. However, I needed an LRU cache, which was trivial to implement in F# and ran like an effing dog with no good way to improve it - I wrote the LRU code in C# to the same API and it ran much better. You might also look at Boo, which I've heard a number of good things about. I looked at it several years ago, but it was not ready for prime time.
posted by plinth at 5:48 AM on June 12, 2011 [2 favorites]
You may be able to have your cake and eat it too.
One of Microsoft's best new products (IMO) is their ASP.NET MVC 3 web development platform, which is released as open source.
As others have said, if you do a bit more research, you can hold better-informed opinions.
"To what extent are the other .NET languages (C#) better?" is a loaded question, and since development language preferences are subjective (helping to explain why there are so many), until you state what your issues are with VB.NET, it is hard to provide alternative suggestions.
posted by SNACKeR at 6:25 AM on June 12, 2011
One of Microsoft's best new products (IMO) is their ASP.NET MVC 3 web development platform, which is released as open source.
As others have said, if you do a bit more research, you can hold better-informed opinions.
"To what extent are the other .NET languages (C#) better?" is a loaded question, and since development language preferences are subjective (helping to explain why there are so many), until you state what your issues are with VB.NET, it is hard to provide alternative suggestions.
posted by SNACKeR at 6:25 AM on June 12, 2011
I'm somewhat of an Open Source ideologue, and hate the idea of using Microsoft technologies, which strike me as not only technically inferior and frustrating to work with, but on the wrong side of history.
Well, I don't think you should reject a programming language simply because its development is being driven by Microsoft. If you like Java, I'd be surprised if you don't like VB.NET.
posted by WalkingAround at 8:34 AM on June 12, 2011
Well, I don't think you should reject a programming language simply because its development is being driven by Microsoft. If you like Java, I'd be surprised if you don't like VB.NET.
posted by WalkingAround at 8:34 AM on June 12, 2011
You may be getting confused by the foofarah a few years ago, when all the VB6 programmers contemplated upgrading to VB.NET. My impression (based on very little) is that if you had zero programming experience you could make stuff work with VB6, but VB.NET required some programming knowledge (like "what's a class"), so they got scared.
I've got a similar background to yours, and once got away with porting a Perl module to C# by pretending it was Java. (Plus, C# actually has some niftier language trick missing in Java. They did learn from Java's mistakes.)
I say take the job if there's nothing else around. Having some VB on your resume might help you pay the bills some time in the future.
posted by benito.strauss at 9:33 AM on June 12, 2011
I've got a similar background to yours, and once got away with porting a Perl module to C# by pretending it was Java. (Plus, C# actually has some niftier language trick missing in Java. They did learn from Java's mistakes.)
I say take the job if there's nothing else around. Having some VB on your resume might help you pay the bills some time in the future.
posted by benito.strauss at 9:33 AM on June 12, 2011
# is basically Java, so you'd probably have a better time with it. On the other hand its all the same set of libraries and same set of principals for any .net language, and it all compiles to the same thing.
posted by Artw at 9:46 AM on June 12, 2011
posted by Artw at 9:46 AM on June 12, 2011
Also use of VB.net does kind if suggest an old VB6 shop, which may be a bad sign.
posted by Artw at 9:49 AM on June 12, 2011 [3 favorites]
posted by Artw at 9:49 AM on June 12, 2011 [3 favorites]
My guess is you're not going to be happy working in a .net shop and you're especially not going to be happy with one that uses VB.NET.
I would hold off for a ruby/java/perl gig if all possible.
posted by sexymofo at 10:22 AM on June 12, 2011
I would hold off for a ruby/java/perl gig if all possible.
posted by sexymofo at 10:22 AM on June 12, 2011
I'm like you: I prefer C style languages and OSS development, but have worked in .NET shops using C++/C#/VB.NET. I was never as happy writing C# and VB as I was writing C++/C/ObjC.
In my experience, it doesn't matter that .NET doesn't distinguish between the languages at runtime, it matters what your boss and other devs want, and if the codebase is VB they're going to expect you to write and maintain VB.
I've interviewed for a lot of different kinds of dev jobs in the past couple of years and a common requirement is not merely whether the candidate is qualified, but rather, will he be happy and manageable doing exactly what the job demands and not trying to change the operation.
Of course this decision depends on how badly you need this job, but if you are someone who isn't going to be happy writing VB, I would strongly urge you to look elsewhere.
posted by hellslinger at 10:26 AM on June 12, 2011
In my experience, it doesn't matter that .NET doesn't distinguish between the languages at runtime, it matters what your boss and other devs want, and if the codebase is VB they're going to expect you to write and maintain VB.
I've interviewed for a lot of different kinds of dev jobs in the past couple of years and a common requirement is not merely whether the candidate is qualified, but rather, will he be happy and manageable doing exactly what the job demands and not trying to change the operation.
Of course this decision depends on how badly you need this job, but if you are someone who isn't going to be happy writing VB, I would strongly urge you to look elsewhere.
posted by hellslinger at 10:26 AM on June 12, 2011
One way you might regret the experience is if it's actually a Silverlight/WPF job where the future looks dim, but Microsoft moving toward open technologies for the UI layer is a bonus from your point of view.
Another way you might regret it is if you're the kind of person who aims to bang out 1000 lines a day of good, bug-free code at work and then come home and use that automatic, reflex-based fluency to do personal projects. If you'd never use Microsoft technologies for the personal stuff, then a simple fact is you're going to be a bit slower or have to work harder to maintain a similar rate. It's not something that impacts most intermediate programmers, but context-switching has a penalty that increases as you approach maximum fluency in your preferred environment.
But neither of those are usual/expected cases. The odds are you will be fine, particularly if you let yourself "go native" for a little while and learn the details of .NET/WCF/Visual Studio/MS-SQL/etc. from a sympathetic point of view. If you don't like it, congratulations on having a good "no offense" explanation for why you want to work elsewhere in a year.
posted by Monsieur Caution at 10:43 AM on June 12, 2011 [1 favorite]
Another way you might regret it is if you're the kind of person who aims to bang out 1000 lines a day of good, bug-free code at work and then come home and use that automatic, reflex-based fluency to do personal projects. If you'd never use Microsoft technologies for the personal stuff, then a simple fact is you're going to be a bit slower or have to work harder to maintain a similar rate. It's not something that impacts most intermediate programmers, but context-switching has a penalty that increases as you approach maximum fluency in your preferred environment.
But neither of those are usual/expected cases. The odds are you will be fine, particularly if you let yourself "go native" for a little while and learn the details of .NET/WCF/Visual Studio/MS-SQL/etc. from a sympathetic point of view. If you don't like it, congratulations on having a good "no offense" explanation for why you want to work elsewhere in a year.
posted by Monsieur Caution at 10:43 AM on June 12, 2011 [1 favorite]
It's the closed sourceness of VB .NET you should be concerned about - it's the language itself, which is very ugly. C# is a decent modern language at par with Objective-C, Python, or Java.
I moved on from a job in part because I got tired of dealing with VB .NET. The rest of it was because they were a very backwards company, despite producing results I had liked. There could be VB .NET shops that value elegant code and basic software engineering best practices, but like Artw said, the choice of VB .NET could be a bad sign.
posted by ignignokt at 12:23 PM on June 13, 2011
I moved on from a job in part because I got tired of dealing with VB .NET. The rest of it was because they were a very backwards company, despite producing results I had liked. There could be VB .NET shops that value elegant code and basic software engineering best practices, but like Artw said, the choice of VB .NET could be a bad sign.
posted by ignignokt at 12:23 PM on June 13, 2011
I would stay away from a VB job personally. VB is going to be fully supported by MS for a long time, but really the winds are pushing towards C#. There was some knee jerky response to your uneducated of VB here, but I'd really question why anyone would start out a project in VB. Nothing wrong with the VB language, but:
- As stated earlier nearly all the examples are in C#. I can't recall a single example of MongoDb, NServiceBus, etc. in VB. So you'll always be doing some translation, this seems to me like an unnecessary burden.
- I would make sure they aren't using WebForms or if they are using WebForms it is in a legacy application.
- I would also ask how they do testing. Unacceptable is, "Joe over there knows how to unit test and does so on his projects," acceptable is, "We're requiring all new projects to unit test but we have legacy stuff that has poor test coverage."
- Make sure they aren't using stored procedures and have caught up with using ORMs. Surprisingly, I found a lot of shops that are still acting like it is 1996.
- Ask what they use for source control and generally what technology stack they use. If everything that comes out is a Microsoft endorsed technology (Unity, Entity Framework, etc.), that would be a flag that they don't like using anything but Microsoft. To be fair, Microsoft puts out pretty good stuff, but when they don't ... it doesn't make sense to use them. I can't imagine being at a shop that didn't let the developers use the best tool for the job and enforced the MS restraint on them.
And in all honesty, I really doubt you'll find a shop full of really engaging and sharp developers who love open source technology and working as a developer ... and it be a VB shop. I know, those are fighting words, but I'd be very careful.
posted by geoff. at 5:39 PM on June 13, 2011
- As stated earlier nearly all the examples are in C#. I can't recall a single example of MongoDb, NServiceBus, etc. in VB. So you'll always be doing some translation, this seems to me like an unnecessary burden.
- I would make sure they aren't using WebForms or if they are using WebForms it is in a legacy application.
- I would also ask how they do testing. Unacceptable is, "Joe over there knows how to unit test and does so on his projects," acceptable is, "We're requiring all new projects to unit test but we have legacy stuff that has poor test coverage."
- Make sure they aren't using stored procedures and have caught up with using ORMs. Surprisingly, I found a lot of shops that are still acting like it is 1996.
- Ask what they use for source control and generally what technology stack they use. If everything that comes out is a Microsoft endorsed technology (Unity, Entity Framework, etc.), that would be a flag that they don't like using anything but Microsoft. To be fair, Microsoft puts out pretty good stuff, but when they don't ... it doesn't make sense to use them. I can't imagine being at a shop that didn't let the developers use the best tool for the job and enforced the MS restraint on them.
And in all honesty, I really doubt you'll find a shop full of really engaging and sharp developers who love open source technology and working as a developer ... and it be a VB shop. I know, those are fighting words, but I'd be very careful.
posted by geoff. at 5:39 PM on June 13, 2011
This thread is closed to new comments.
I understand your love of OSS, but I wouldn't let ideology get in the way of using the Right Tool for the Job. And when programming for Windows/Windows Phone 7/ASP, the .Net suite of languages are the best tool for the job.
posted by sbutler at 12:51 AM on June 12, 2011 [3 favorites]