December 17, 2008 at 10:53 am
If you have been COBOL shop for years, why not look at Fujitsu NetCOBOL for .NET?
You may still need VB.NET for SSIS, SSRS, et al.
December 17, 2008 at 11:04 am
Lynn Pettis (12/17/2008)
If you have been COBOL shop for years, why not look at Fujitsu NetCOBOL for .NET?
That is an excellent point and it should be evaluated. If you go that route, you will face three obstacles:
1. You will find it almost impossible to find new developers who will work on your system, because many of them will consider extended experience with your language career-limiting
2. It will also be career limiting for your existing developers, since it will be hard for them to use their experience at another company
3. This is the main one: COBOL is a procedural language. Programming on Windows requires an event-driven language. This is a difference that requires a completely different mode of thinking, and I don't think that hybrid-COBOL will make it easier. If you are going to make this change, you might as well make it completely.
December 17, 2008 at 11:08 am
Actually, they have made this COBOL pretty much OO. I have been looking at the web site, and it looks like there is a lot of effort behind it to keep COBOL viable. Plus, when you get down to the nitty gritty of programming, even in C# or VB.NET, it's still procedural at some point in the coding of the application. It just isn't like the old days of mini-computer and main-frame computer programming.
December 17, 2008 at 11:13 am
gcopeland (12/17/2008)
If you made your pick for good business and professional reasons, your pick would be incorrect.Have a great day!
I'd agree if there was an actual technical reason to flat out rule one language better than the other. In my mind however, there isn't, since they each have their own strengths, and IMO you'd be hard put to find something you can do in one you just plain cannot do in the other.
Most of the backlash against vb.NET has nothing to do with it per se, but has to do with the negative associations to VB (classic) and VBscript, which had a tendency to tolerate and/or foster "less than optimal" code.
So - it seems to now come down to whether you like case-sensitvity and semicolons in your code or not, and NOT whether one is particularly better than the other.
Market preference has rarely proved to be a good predictor for "best technical product" from my own personal experience. As a matter of fact - more often than not, the "best" product failed miserably because the geeks who made it couldn't run a company/market/etc....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 17, 2008 at 11:15 am
Lynn Pettis (12/17/2008)
Actually, they have made this COBOL pretty much OO. I have been looking at the web site, and it looks like there is a lot of effort behind it to keep COBOL viable. Plus, when you get down to the nitty gritty of programming, even in C# or VB.NET, it's still procedural at some point in the coding of the application. It just isn't like the old days of mini-computer and main-frame computer programming.
Excellent points, but they don't change the career issues I mentioned. As someone mentioned earlier on this thread, changing languages completely might actually help the developers adjust to the new environment easier.
December 17, 2008 at 11:19 am
Matt Miller (12/17/2008)
I'd agree if there was an actual technical reason to flat out rule one language better than the other.
There are no technical reasons to choose one language over the other, there are business reasons. C# is ISO certified. VB is not, because MS chose not to get it into shape for certification. This shows that MS has a lack of interest in the language, and indicates that its support in the future will not be as good as that for C#.
Case closed, have a great day!
December 17, 2008 at 11:19 am
Not sure. I did a lot of COBOL programming at my previous employer and I think moving to an OO environment where I could continue to use the skills I already had would make that transition easier. I wouldn't have to learn a new language and a new paradigm in programming at the same time. Once I was comfortable with the OO paradigm, changing to a different language should actually be easier as then you are just learning a new syntax.
December 17, 2008 at 11:24 am
Thanks to everyone who's responded so far, and by no means let these comments end the discussion. As to the comment 'the poster didn't ask what you'd prefer', it would be so nice to have the answer to that question be the same as the one I asked. And acceptance from the programmers is going to be a big hurdle to overcome, so people's preferences are as important as anything else in this debate.
If it were just me using the language, I would absolutely agree with Jack: I think with verbose code (that's the COBOL programmer in me), it's easier to figure out what the original developer was trying to accomplish, and if someone has a good explanation of why I should prefer a case-sensitive language to one that isn't, I'd love to hear it. But, as with so much in life, this can't just be about me, which is why I really appreciate this discussion.
Mattie
December 17, 2008 at 11:25 am
Lynn Pettis (12/17/2008)
Not sure. I did a lot of COBOL programming at my previous employer and I think moving to an OO environment where I could continue to use the skills I already had would make that transition easier. I wouldn't have to learn a new language and a new paradigm in programming at the same time. Once I was comfortable with the OO paradigm, changing to a different language should actually be easier as then you are just learning a new syntax.
That is a good point, and you may be 100% right. I will point out that the developers will still have to learn the part of the language that makes it event-driven, and I doubt that will be trivial. It might equate to the effort it would take to shift to a new language.
Of course, if some of the existing codebase can be ported to the hybrid-COBOL, that should be a consideration, too.
Also, it occurs to me that dot net was designed to enable interoperating languages. If the codebase ports, you might be able to go forward with a heterogenous development effort.
December 17, 2008 at 11:28 am
gcopeland (12/17/2008)
If you made your pick for good business and professional reasons, your pick would be incorrect.Have a great day!
It also depends on what you are doing with the language as well. As I said in my original post, if you are using SSRS or SSIS pre-SQL Server 2008 you need to know VB.NET anyway. Also, based on what I have seen, VB has better XML support than C#, so if you are doing a lot with XML VB.NET may be the better choice for business and professional reasons.
If there were signs VB.NET was going away, I'd be more inclined to recommend C#.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
December 17, 2008 at 11:33 am
gcopeland (12/17/2008)
Matt Miller (12/17/2008)
I'd agree if there was an actual technical reason to flat out rule one language better than the other.There are no technical reasons to choose one language over the other, there are business reasons. C# is ISO certified. VB is not, because MS chose not to get it into shape for certification. This shows that MS has a lack of interest in the language, and indicates that its support in the future will not be as good as that for C#.
Case closed, have a great day!
I did not know the ISO certification which is interesting information. It's also interesting that one would be and the other wouldn't be since they compile to the same thing. I don't think that this necessarily indicates a difference in support between the languages.
A question, which may not be able to be answered here, is, could you use a compiled 3rd party component built using VB in a C# application and be ISO certified?
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
December 17, 2008 at 11:35 am
Case closed, have a great day!
If this were the case, there would be no choice in language. Seems to be a bit of arrogance in this stance.
I am advocate for SQL Server, but I also realize that there are uses for the other RDBMs that exist. For instance, SQL Server only runs on Windows Servers, where as the other will run on a variety of *nix systems. If you aren't a Windows shop, you most likely aren't running SQL Server.
Each business needs to assess its needs and what is available and base its decision on that information.
December 17, 2008 at 11:37 am
Jack Corbett (12/17/2008)
It also depends on what you are doing with the language as well. As I said in my original post, if you are using SSRS or SSIS pre-SQL Server 2008 you need to know VB.NET anyway.
Wow, that seems very odd, because the dot net CLR was designed to work with any language.
Also, based on what I have seen, VB has better XML support than C#, so if you are doing a lot with XML VB.NET may be the better choice for business and professional reasons.
Better XML support is a technical reason, not a business or professional one. Those will still be an isssue.
December 17, 2008 at 11:43 am
gcopeland (12/17/2008)
Jack Corbett (12/17/2008)
It also depends on what you are doing with the language as well. As I said in my original post, if you are using SSRS or SSIS pre-SQL Server 2008 you need to know VB.NET anyway.Wow, that seems very odd, because the dot net CLR was designed to work with any language.
Also, based on what I have seen, VB has better XML support than C#, so if you are doing a lot with XML VB.NET may be the better choice for business and professional reasons.
Better XML support is a technical reason, not a business or professional one. Those will still be an isssue.
The .NET CLR was designed to work with any language, unfortunately SSIS and SSRS weren't written that way pre SQL 2008. In SQL Server 2005 and earlier, these tools only supported VB.NET. Nothing to do with the CLR.
December 17, 2008 at 11:47 am
Lynn Pettis (12/17/2008)
The .NET CLR was designed to work with any language, unfortunately SSIS and SSRS weren't written that way pre SQL 2008. In SQL Server 2005 and earlier, these tools only supported VB.NET. Nothing to do with the CLR.
Gotcha, thanks for the info. Offhand I'm going to guess that MS made a mistake.
Viewing 15 posts - 16 through 30 (of 42 total)
You must be logged in to reply to this topic. Login to reply