|
A form is a form. VB6 is usually a (thin) front end to a client server system. No hurry given such a big window. Might even be premature; not knowing what's around the corner 2 - 5+ years in the future.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Now. Even VB.NET is a low priority. I would jump to C# and Dot Net 7.0+.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
I think VB.Net has a different priority from C#. VB.Net's developers are trying to keep the language stable. C#'s developers continually add features. Their target development environment is different and language stability is important to the VB developers.
|
|
|
|
|
Very recently Damian Edwards[^] was asked about bringing VB in line with ASP.Net MVC, and the response was there is no plan to do it. That is just one example.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Oh my, am I that old already...
I felt nostalgic a few weeks back and started up an old lappie of mine(showpiece on display now). Guess what I found - VB6 Enterprise was still installed, a major folder with many a project. Man, did I have fun for hours on end!
|
|
|
|
|
Please recommend where to switch to.
|
|
|
|
|
Take your choice. Either C# or VB. Both have their pros and cons. VB might be easier to learn but C# will have more example code on the web for solutions.
|
|
|
|
|
Honestly, can't answer that question without knowing more about the apps. Staying with .net, C# or VB won't make much difference but it's easier to find talent in C#.
But, is that the best solution? Don't know.
|
|
|
|
|
Who knows, maybe by then tech buzzwords will make a full cycle, RAD becomes a thing again and VB7.0 will be released.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I do wonder whether this is in some way linked to VBA. If it is I assume that Microsoft probably don't want to break the back end of Excel. The fallout from that would be significant
It goes without saying
|
|
|
|
|
Those who haven't switched yet are prolly not ever going to.
Personally, I stopped doing anything VB6 years ago and I'm not touching it again.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
A few things, among several, factor into that decision.
1 - MS has a history of bringing .NET changes to C# first, VB second. Bill Gates was the driving force behind keeping VB at equity with C#, and he is long gone.
2 - More .NET developers use C# than VB, so MS markets to the larger customer base first.
3 - VB easily converts to C# with tools that take VB to MSIL and the MSIL to C#.
4 - Too many classic VB programmers ignored MS in the late 90s to use VB6 for object oriented programming instead of the older procedural programming that became obsolete by the time VB5 came out. Converting/refactoring procedural VB6 to OO VB takes as much effort as converting/refactoring procedural VB6 to OO C#, so many chose the latter.
If your context is converting/refactoring VB6 to .NET, start now. There is so much more available in .NET 7 than there was in VB6. Refactoring will take time to make the business rules and UI implemented in VB6 to an efficient design in .NET.
|
|
|
|
|
When to switch? I'd start now. Nothing ever goes as planned, so figuring things out now, well ahead of a complete drop in support, is the wiser choice.
I have no idea where the OP is in his career, but any newer language is a more marketable skill, so starting now also adds to the resume.
What to switch to?
I was a VB developer (among other languages) from 1993 to 2003. At that point there was still a lot of 3rd party support for VB6, but without MS support it was a dead language. Yeah, obviously as dead as COBOL, but as an IT consultant, I had to focus on marketable skills, and VB was no longer "it".
The obvious jump-to was VB.NET, but within a few months I formed the opinion that MS made VB.NET primarily to keep the VB5/6 developer base from jumping ship. VB.NET didn't get the same support and was not graining traction in market share.
Next I investigated C#, and that has been my primary platform since then. It's the MS flagship for programming languages, gets the support, and has a viable future. Market share of the tool matters greatly to ensure continued employment, and C# is ranked 5 or 6 in most surveys.
From the OP's POV? C# is going to be the easiest path. The environment is similar enough and C# has enough similarities in structure that the learning curve should not be too steep.
Jumping from procedural to OO can be a difficult jump. VB6 has some OO, and if the OP has been using classes, the leap may not be a long one.
|
|
|
|
|
OOP's overrated Seriously though, I use it where needed but depending on the desktop app and the object usage, procedural can be more efficient to build. Doing a complete from scratch rewrite, which these are, requires a ton of thought. I don't start by looking at code, I look at process and functionality. It's a good opportunity to really review processes in many cases.
|
|
|
|
|
I agree with you regarding OOP -- it's A technique, not THE technique. C# is an OO language, so things are pushed in that direction.
Something people don't often consider is that forms are classes. Forms in VB 4-6 are instantiable objects. It doesn't matter that the word "class" isn't there -- it's not a requirement, just a common convention.
Re-writing an application from scratch is not a trivial thing. It can be rather expensive, and management often defers the task to avoid incurring what appears to be an unnecessary cost. Until replacement becomes a requirement, and things are crammed into production.
As the old saying goes, we don't have time to implement correctly, but we do have time to fix it in production.
|
|
|
|
|
Very well said!
Years ago, when converting a VB6 app, one of my programmers told me I had too much code "behind the buttons". My reply was that sometimes a button click is just a button click. An extreme example, but goes to the "THE" mentality.
I don't know about all of you out there, but often times "agile" falls short of design flow. I'd call it more flux-rad. Easy to make the argument that OO is the way to go, but it takes some thought and a couple of lines of procedural code can be a better solution.
And, as you said, cost is very often a factor. The other old saying we use is, if it ain't broke, don't fix it!
|
|
|
|
|
BryanFazekas wrote: I have no idea where the OP is in his career,
The OP (me) has about 40 years.
And I don't use any version of VB if I can avoid it. My choice is Java or C#.
I was just posting because I found the subject interesting.
|
|
|
|
|
Regardless of the language(s) involved, application replacement is a good topic for discussion. As I said, management typically doesn't want to spend on re-developing an application when there is time, but freaks when there isn't time and they did nothing to help the situation.
A project I was on a while back was replacing an ancient application that relied on old tech. Everyone (customer, management, dev teams) dragged their feet on putting the new system in production, until key tech the old application required was dropping support. We completed the project in 3 months. It's amazing how a bit of heat, or maybe a raging bonfire, can motivate people.
Personally, I'd have no problem developing in VB again. Prior to VB, I mostly used C and Hypercard (Mac folks may remember that one), and a handful of other languages. VB was fantastic for productivity in creating desktop applications, far better than anything on the market at that time. Honestly, it's better in that venue than anything I've worked with in the last 10 years.
When the only tool ya have is a hammer, everything looks like a nail. That's the case for OO, Agile, RAD (yeah, I'm as old as the OP), and every other paradigm.
Before someone mentions "VB has GOTO" ... C# has GOTO and Java originally did (AFAIK, it's just a reserved word now). Bad code can be written in any language, and I've seen more in C# and Java than I have in VB.
A lot depends on one's POV. My job is not to write code. My job is to solve business problems, regardless of methodology or tools. Food for thought.
|
|
|
|
|
I counted 16 replies to the question of wich I se only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
|
|
|
|
|
|
I counted 28 words in your comment, and 7 were not correctly written... is this the normal level of working keyboards at your end?
Sorry... too tempting
To answer you...
The answers of "30 years ago" is for me totally serious. You can infer that the author thinks the OP should not "waste" any second more at all using it and move on to other languages. The fact that it got 10 upvotes means, that many other people (me, among them) agree with him.
And for me it is a perfect serious answer, although it is written with humor.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
thermia wrote: only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
In this forum (not site)? Yes it is is.
Although certainly with an open ended question I would expect answers that veer off in all sorts of ways anywhere.
But also as the OP and with decades of experience I don't actually need an "answer". If I really needed an solution I would already know what it was and how to apply it for any specific situation I was in. I just thought the question was interesting.
|
|
|
|
|
never switch. VB Classic was right
only now in C# you can write code without XYZ partial class App public static void main SubscriberMethodController... cough cough
Starting in C# 9, you don't have to explicitly include a Main method in a console application project. Instead, you can use the top-level statements feature to minimize the code you have to write. In this case, the compiler generates a class and Main method entry point for the application.
guess what, we had that since VB 1.0, any language had that, the compiler behind the scenes generated the _app & _main. i wonder when they are going to get rid of new in C#, since the instances of a class are not created on the stack anyway...
VB Classic will outlive VB .NET. if not, waiting for the shameful M$ narrative when they bring back the apparent syntax of VB to VB.NET
those who put class in JavaScript are the same who put var in C#
|
|
|
|
|
Martin ISDN wrote: guess what, we had that since VB 1.0,
Just noting that I don't consider that a feature that would have any impact at all in a language choice.
Further if one is spending a major part of their time creating new applications I would wonder what exactly is the business domain they are working in. After all if you are maintaining an application for 20 years then the entry point for that application should not change at all for the entire time.
|
|
|
|
|