Printable View
Well all you .net folks told us it would not happen:
http://visualstudio.uservoice.com/fo...improved-versi
Time to move on, Delphi here I come. All my embedded devices will ship with Linux!
It's Over
Sad DAY
Lots of hard work to be done, here we go!!!
It is no deader now than it was last year or the year before.
I do like the fact they stated that the runtime? should be supported through 2024
btw It wasn't just .Net folks that were telling you that, it was VB6 guys too. I thought it was pretty clear 10 years ago that VB6 was not coming back but would continue to work for the foreseeable future.
Sad news, but expected. I don't believe the pointed reasons tho.
Doesn't really matter. They're just sticking to the same position they've had since 2005 or so.
I think it is probably telling that no 3rd party has stepped up to create an acceptable alternative. Perhaps a big reason for that is how hard it is to define something "acceptable" in a way that doesn't step on some of Microsoft's legally protected stuff.
There are tons of 3rd party alternatives already though. Find one that works for you.
If you HAVE to post junk like this, keep it in the chat room....this forum (VB6 and Before) is designed to HELP people WITH VB6.
Thread moved to Chit Chat.
Doesn't sound to me as MS has killed it yet...Quote:
Originally Posted by Microsoft
Well, Delphi 8, Delphi 2010 and Delphi XE2 was all different and you needed to make substantial changes to your code to upgrade between these versions. Moving from VB6 to VB.Net is actually easier.Quote:
Originally Posted by axisdj
I think difficulty is not the major reason why lots of VB6'ers didn't move to VB.NET, it's .NET itself.Quote:
Originally Posted by Joacim Andersson
What do you mean VB6 is dead?
No it isn't. I'm using it right this moment and it still works
So what's wrong with .Net? If you're running a modern Windows OS you've already have it. With it you can develop desktop applications, console applications, Windows Services, Web Applications, Web Services, Modern UI apps, Windows Phone Apps, XNA Games for the XBox or Windows, and the list goes on... How many of these things can you do with VB6? If you also invest in Xamarin you can even use your .Net skills to develop for Android and iPhone.Quote:
Originally Posted by Carlos Rocha
Only thing I can see that is a considerable negative about .NET is that you need to install the whole framework even when most programs will barely begin to use a tenth of it. So I think as someone mentioned in another thread could be good to see it compile and include only the necessary stuff (could have my terms mixed up still learning).Quote:
Originally Posted by Carlos Rocha
Anyway I imagine VB6 development will still be quite prevalent for at least a few more years.
That's not the point. The point is: do you need .NET for most of that? I don't know about Windows Phone or XNA (whatever it is), but for all the rest you certainly don't need .NET. It's just, maybe,...easy to work with? but I don't think it's that easier than anything else as long as you know the right tools, and pure Win32/Win64 is still best, imho. The problem I see with VB6 dropping is that nothing is left from MS to create native binaries but C++.Quote:
Originally Posted by Joacim Andersson
Well, .Net Native is still rather new but it will be covering these issues (if they are issues, .Net is preinstalled on Windows). And VB6 never created pure native applications since you still needed the runtime libraries since they contained all the wrapped controls.
Quote:
To this day .NET has less features than VB6, is slow and bloated and has about 10x distribution size compared to VB6.
Quote:
My personal opinion is that Microsoft will make a new version of vb6, we are simply too many programmers. I'm glad we started to come together as a community and speak our minds.
Saw a few comments I found interesting in the link. I never got to involved in VB6 though it was the first language I used and still love it. But even now is .NET still feature-less compared to VB6? Also could the fact that Microsoft don't have the expertise be a reason they don't want to remake it?Quote:
Microsoft does not have the expertise to make a new VB6.
Also my understanding is technology has changed, every morning I pick up my phone and I use modern stuff that is generally all web based and extremely flexible. I don't think VB6 could really fit these purposes in today's world.
I have to say I didnt see any of this coming. I thought they were going to bring it back. Fatia said his petition has 7200 votes...
That would actually be a bad thing I think, The .Net framework is on most Windows machines already and lots of applications use it and have been doing so for quite some time. If each app compiled only the parts of the framework they needed and distributed it with their apps then all .net apps would be larger, some of them by huge amounts and the amount of disk space used would increase greatly.Quote:
Originally Posted by sharpCode#
What about VB6, most programs do not use most of the stuff in the runtime yet the entire runtime is required for all of them, pretty much the same thing with .Net just a different file set.
XNA is a free product that allows you to develop games for Windows, Windows Phone and XBox 360 using .Net languages.Quote:
That's not the point. The point is: do you need .NET for most of that? I don't know about Windows Phone or XNA (whatever it is), but for all the rest you certainly don't need .NET. It's just, maybe,...easy to work with? but I don't think it's that easier than anything else as long as you know the right tools, and pure Win32/Win64 is still best, imho. The problem I see with VB6 dropping is that nothing is left from MS to create native binaries but C++.
VB.Net also allows you to develop for Windows CE and Windows Mobile devices which I have been doing in VB.Net for several years now with much success.
Vb.Net is easy to work with once you have adjusted to it, and so is C# in many cases VB.Net can be easier to work with than VB6 and can do a lot more.
Which is a very small number to a company like MS.Quote:
I have to say I didnt see any of this coming. I thought they were going to bring it back. Fatia said his petition has 7200 votes...
What surprises me is that anyone is surprised that MS did what most expected them to do anyway. It really should have been clear to most a long time ago that VB6 was the last of the classic VB editions.
But this is coming with .Net Native.Quote:
Originally Posted by DataMiser
That's a ridiculous and an untrue statement.Quote:
To this day .NET has less features than VB6
Does that actually build parts of the framework into the exe [meaning that the framework does not need to be present on the target] or is it just doing native compile of the code like VB6 does still requiring the runtime and possibly one to several other dlls, and such to operate on the target?Quote:
Originally Posted by Joacim Andersson
I assumed it would still use the framework as a runtime but be skipping the JIT runtime phase
I haven't read too much on the subject but, while I could be wrong, I doubt that. I don't think each app would have parts of the .NET Framework compiled into its native code. I would expect that the Framework libraries would still be separate, whether in IL or native form, and there would only be one copy of each to be shared by all apps.Quote:
Originally Posted by Joacim Andersson
If you'll have a look at this Channel 9 video you'll see that that is exactly what it's doing. Of course that doesn't mean that there will be zero dependencies.Quote:
Originally Posted by jmcilhinney
However the .Net framework is all native, since in the end native is the only thing that will actually run on your machine. It's just that your app is JITet on first run, but the framework itself is already native. What .Net Native does is a lot of optimization and will compile all types that you're using into the app itself and produce two files: an app.exe and an app.dll. The app.exe is about 10kb in size and it's actually the app.dll that contains all your code. So the app.exe is just calling a main function in the dll.
The one thing I am curious about, but don't know how to ask about, is what the opposition to .NET is for those passionate about VB6? Some people appear to simply be misinformed, which is understandable, as there has been LOTS of misinformation out there. I stayed away from .NET for a couple years due to that mininformation, myself, but that's kind of minor. What I suspect is the case is that Object Oriented languages are such a different way to think about things when compared to block-structured, functional, or whatever the proper term is for the other way, that the shift from one to the other is daunting. Since I came from an OO background prior to VB of any sort, I tried to write VB5/6 in an OO fashion, which it doesn't really do. Therefore, I found OO to be one of the major selling points for .NET. On the other hand, I think TG said that he struggled with OO, initially (may not have been him, too, but until he contradicts me I'm sticking to it). I can really understand that. Our brains pick up concepts in different ways, and once some pattern is established, our brains work against changing that pattern (for good reason, too). So, there will be people who will really struggle with OO and there will be people who will not. I just wonder if that is the basis for much of the resistance to .NET, or if it is the misinformation stuff such as the need for the framework (all languages need a framework, and have since the 80s, we just shift the definition of framework around to suit our needs).
Run ScriptBrix™ instead :)
I've been using OO since I first learned about it back in late 80's early 90's ... it seemed quite natural and obvious... what I struggled with was event programming... Coming from a strictly procedural background of Pascal and BASIC, even programming was jibberish. "Where the fork is the IF statement that says 'If button clicked, call this method?'"Quote:
Originally Posted by Shaggy Hiker
was a common phrase from me during that time... it was a while before the penny dropped and realized it's basically FM ...
You may now unstick yourself.
-tg
@Shaggy,
I'm not "passionate" about VB6, I just think it's the easiest way to produce COM binaries, with near zero dependencies or deployment issues. Using .NET for this feels like using a train to go shopping.
My programming language is Visual Objects (created by CA as the Clipper successor for Windows, back in the 90s). It follows a beautiful OO paradigm that I can use with any ActiveX or COM Server, and I dont think it's too different from VB6 in this respect (at least at the basic level I use it). Sure, no inheritance, but there are other ways to accomplish something like it, and in fact COM is all about OO, so I don't think OO approach is the problem. The problem is the "non-simplicity" of .NET.
Now that we know Classic VB will not be further developed (so, no Win64 and no pure OO) it's time to find something else to fill the gap. That's why Delphi and the like are being referenced lately, and that's why I don't understand MS decision.
Bummer, I got the wrong detail wrong.
Axisdj, I really don't understand your position. Your arguments before now were always that you didn't want to have to rewrite you applications. This announcement means you don't have to. At least for another ten years. You can safely go on using VB6 until 2024.
I can understand (though I don't agree with) people's dislike of .Net. But the bit I can't get my head around is the gloom about having to move away from VB6 in response to MS announcing that you don't have to move away from VB6.
Just have to use the best tool (programming language) for each job (project)
Its still dead as a door nail
I had not saw the name CA for quite a while, I remember back in the late 90s I wrote a few pieces of software for them, part of it in VB5 and other parts in a couple of different scripting languages.Quote:
Originally Posted by Carlos Rocha
A couple of the guys I worked with were fans of Clipper but I never really used it much myself.
That's a good point. I don't produce COM binaries, so I have neither knowledge nor opinion about that. Nothing is without dependencies, though, and hasn't been for a very long time. We have just come to ignore the dependencies that are convenient to ignore. After all, any talk about cross-platform issues is due to the fact that our apps are hosted in the cradle of some OS or other. There once was a day when that wasn't true...but it wasn't the best of times, to be sure. We also all use libraries of one sort or another, though not for every app.Quote:
Originally Posted by Carlos Rocha
My programming language is Visual Objects (created by CA as the Clipper successor for Windows, back in the 90s). It follows a beautiful OO paradigm that I can use with any ActiveX or COM Server, and I dont think it's too different from VB6 in this respect (at least at the basic level I use it). Sure, no inheritance, but there are other ways to accomplish something like it, and in fact COM is all about OO, so I don't think OO approach is the problem. The problem is the "non-simplicity" of .NET.
Delphi was referenced by axisdj who was clearly making that reference out of anger at MS. He'll really go round the bend if he goes to Delphi and sees what JA has now reported twice: They are perfectly content to introduce breaking changes to the language every few years. I feel that axisdj shouldn't even be considering any other language. From what he described, he's got at least another five years before he needs to even be worried about VB6 going away, and the world can change a whole lot in five years. On the other hand, if he wants cross platform, is Delphi really the best option? I'd be looking at Java or C. Things like PhoneGap might be an option, if his program wasn't what it is. I doubt PhoneGap would suit him well at all with the hardware access he's dealing with.Quote:
Now that we know Classic VB will not be further developed (so, no Win64 and no pure OO) it's time to find something else to fill the gap. That's why Delphi and the like are being referenced lately, and that's why I don't understand MS decision.
On the other hand, it seems to me that .NET is the right language for him, and I don't understand the reluctance. While I don't deal with COM binaries, I have dealt with hardware control for robotics, and .NET is an excellent language for that. Better than VB6 was, in fact. There was one thing that I kind of liked better about VB6, which was the handling of UDP in a simplistic situation. That was super simple. It was also super simplistic, which meant that it didn't scale all that well if scaling was important. Hardware control generally doesn't use UDP, though, but rather serial (the other com), which .NET has always handled as well, or better, than VB6 (I don't fully remember how VB6 handled it, except that it was a bit awkward).
Every tool is the best for some job. If the reluctance to change tools is because you have the best tool for the job at hand, then that's great. If the reluctance is resistance to learning new things...then you're in great company, because everybody has some of that. If the reluctance is over OO, then I totally understand that, as well, because I do know people who don't see things that way (though apparently not TG). The problem would be if reluctance was simply due to anger over some decision made by a sprawling corporation. Heck, I'm still amazed that there was even a response. I figured MS would simply ignore the petitions it didn't want to deal with and thereby leave everybody in limbo.
Umm not really. If memory serves VB2003 and Framework 1.1 did not come with a serial class at all. I had to buy a 3rd party tool in order to do some simple serial stuff in VB2003.Quote:
Originally Posted by Shaggy Hiker
VB6 has the MSComm control which works fine in simple cases. I've used it on many projects for talking to printers, barcode readers and robotics. I also have a couple of 3rd party controls for VB6 that support the various transfer protocols such as X, Y, Z Modem and others.
As of VB2005 they added a serial class but still can be a bit tricky to use if you are coming over from VB6 due to the fact that it uses threading. Works very well once you get a handle on it.
TCP was easier to deal with in VB6 using the Winsock control but much more powerful in .Net using the Sockets Class
Well, I can't quite remember what 2003 had, but I thought I was using built-in serial back then for a series of PDA projects (I sure wasn't buying anything, as I had no budget, but I may have been using TCP). Now that you mention it, though, I do have some vague memory that it was added at some point.
.NET has always supported ActiveX controls so anyone with VB6 installed could use any ActiveX control that came with VB6 in the VB.NET apps. Some still do, but probably should have migrated away from them by now.Quote:
Originally Posted by DataMiser
I think part of the problem is that it's different things for different people. That's why there's never been a coherent plan for a new version of VB6 from anyone: because everyone wants something different. I've seen the fact that VB.NET is OO and VB6 is not used as an argument against VB6 before and then there will always be those who argue that VB6 had a number of OO elements and that was enough and I've even seen someone argue vigorously that VB6 is OO, even despite the lack of inheritance.Quote:
Originally Posted by Shaggy Hiker
Wasn't an option in my case as I was developing in VB.Net for mobile devices.Quote:
Originally Posted by jmcilhinney
Could you have written a mobile app in VB6 using that control? I'm not sure but I wouldn't have thought so. If not then I guess neither handling it at all still means that VB.NET handled it as well as VB6. :)Quote:
Originally Posted by DataMiser
Funky, Let me break it down. My program is sold to end users who buys a new laptop or windows machine to run my software(for controlling intelligent lighting). So lets say Windows 9 breaks my app/vb6 apps. I can no longer sell my product because my customer will only be able to buy a new pc with windows 9. I hope that makes sense.Quote:
Originally Posted by FunkyDexter
OR
Am I missing something. Are you saying that my vb6 app will work until 2024 on the latest OS, I THINK NOT!
WP
FYI,
I do not use serial communication. All my hardware communication is through a c++ dll.
I will have to do some more research, but from what I seen Delphi increments each version with mainly improvements, and something written in 1995, could very easily be converted and compiled in 2014. From what I understand there was never a version that completely broke everything as in vb6-.net. Correct me if I am wrong.
WP
Hmmm... I think that some, including myself, were interpreting that as saying that the VB6 Runtime would be distributed with Windows until 2024 but, upon reading it again, I now see that it looks to mean that the VB6 Runtime is supported on Windows 8.1 and Windows 8.1 will be supported until 2024. Rather a big difference.Quote:
Originally Posted by axisdj
I tried for a while to do them in VB5 with the CE toolkit but not much success there. Prior to moving to VB.Net 2003 I was using EVB 3.0 which did have a com control of sorts. or at least I think it did.Quote:
Originally Posted by jmcilhinney
I was a bit shocked the VB.Net did not have some method for talking to the serial ports, after all even GWBasic could do that. Of course it got added and all was well again. I think VB2005 was quite a jump forward in many ways.
You're right about the 2005 generation being a big step forward. As for serial ports, I'm guessing that Microsoft figured that they were being phased out anyway so why bother supporting a dying technology. They probably underestimated the number of people who were still using physical ports or, going forward, virtual serial ports with physical USB ports. Assuming that's the case then, to their credit they did listen and address the issue in 2005.Quote:
Originally Posted by DataMiser
Ah yes, I hadn't read it like that but you're right.Quote:
Hmmm... I think that some, including myself, were interpreting that as saying that the VB6 Runtime would be distributed with Windows until 2024 but, upon reading it again, I now see that it looks to mean that the VB6 Runtime is supported on Windows 8.1 and Windows 8.1 will be supported until 2024. Rather a big difference.
Axisdj, then yes, technically you're at risk. I still think you'd be being premature if you started rewriting before you actually see whether 9 will or won't support the runtime though. Even if the statement doesn't say that 9 will support the runtime it does say that they don't want you to have to rewrite your apps. And even if 9 doesn't support the runtime I'm willing to bet there'll be easier paths forward than a complete rewrite. Emulators, for example.
But you didn't write a Delphi app in 1995. You wrote a VB6 app so surely it would be easier to migrate it to VB.NET, which shares a syntax and reimplements a lot of VB6 functions, than to move to a completely new language like Delphi.Quote:
Originally Posted by axisdj
You're wrong. They have introduced breaking changes at, at least, 3 different occasions.Quote:
Originally Posted by axisdj
you are right, and what a big mistake. Because if I chose the latter(vb 6), with only small mods at a time I would have my app compiled on the latest version today.Quote:
Originally Posted by jmcilhinney
Emulators will not work for me, my customer expect the app to run just like any other, jumping through hoops is not acceptable.
So here is my train of thought.
Lets say I move from vb6 to .net. I would pretty much have to re-write my app for many reasons, the last import I did rendered 80,000 errors in vb.net.
So after all that work I would have the same app as I do now, but it may run slower, is not native and open to de-compilation. Yes I know .net native is coming but who knows how that will turn out. And at the end I am still at the mercy of MS who killed 100k lines of my code for the sake of OOP purity, and can only run on windows.
So lets say I re-write to delphi. BTW there is a convertor that would convert many of my classes which would speed things up. So what is the benefit: I get a native compiled app, that is able to be run cross-platform, maybe with better performance, on a language that has not broken previous versions completely like vb6- .net, that is open source, and free, with syntax that is more like vb6 than c++(QT Creator). I really think there is no competition here. As much as I hate moving to delphi because of some of the strange syntax, I think it is the right choice for me.
can you show me where I can find this information, I think minor things have broken, but nothing like the vb6-.net where you are just left %&** out of luck with all you 100k LOC.Quote:
Originally Posted by Joacim Andersson
Show Me, cause I cannot find it. All the change logs I have seen only adds functionality.
From what I can find, the only support/ major break they ever did was the removal of .net support...
http://delphi.about.com/cs/azindex/a/dhistory_3.htm
There's a common misconception about the write-once, run everywhere "promise" of cross-platform... to the best of my knowledge it doesn't exist. Even with JAva, it's still not a completely fulfilled promise. The problem is that "native" component of compilation. The resulting bytes for a Windows machine is different from a linux, Apple or anything else. So in order for your app to be available on other platforms, you will need that platform to compile on... now it's possible you may (MAY) be able to write-once and compile everywhere with little to no changes... but I suspect there are just enough variations in the platforms where some minor tweaking between the different versions. There's a reason the Netflix app on my Wii works differently from the version I have on my Roku...Quote:
I get a native compiled app, that is able to be run cross-platform,
Unless things have changed - which is very much possible. I'm not convinced they have though.
-tg
I agree, but cross-platform is possible. You just place conditional logic where it is applicable..Quote:
Originally Posted by techgnome
Another example is when they introduced Unicode and completely changed the data types String, Char, and PChar in Delphi 2010 (or maybe it was in Delphi 2009, I can't remember)
What? Delphi is not open source? The latest version cost €4159 + VAT (that's € not $). You also don't get cross-platform by default. The VCL is still Windows only, to get cross-platform you need to use FireMonkey which doesn't have nearly as many components. Read This before you decide to go with FireMonkey.Quote:
Originally Posted by axisdj
I'm not saying that Delphi is a bad choice, I've been using it for many years. However it's very expensive and you don't get any service packs or bug fixes. If there is a bug you have to wait for the next version where they hopefully have corrected it and then pay the upgrade fee to get the latest. Which will (currently) cost you around €2600+VAT. They release a new version every year.
Changing data types is hardly breaking everything....Quote:
Originally Posted by Joacim Andersson
Let me clarify, I am talking about Lazarus IDE, it's free and open source.. Language is the same used in the delphi product.
WP
Oh boy, do you realize how often you use strings in a project? I had to spend two month making changes to one of my Delphi projects because of this "tiny" change. I've updated large VB6 projects to VB.Net in less time than that.
I took something in VB6 and very easily converted and compiled it in .NET, so it's a matter of degree. In both cases, there doesn't appear to be a compiler that will take the old code and convert to the new with the click of a button (or less than that), so in both cases there is some amount of effort in conversion, but VB6 to .NET was trivial. A project that took me months to write took hours to convert, and much of that was due to redesign.Quote:
Originally Posted by axisdj
I would have to agree on thisQuote:
Originally Posted by jmcilhinney
How did you even do that? The number of errors I get caps out at about 100. If you are talking about the conversion tool, that's understandable. It should never have been added because it was so terrible. I never used it, so I don't know. Was that reporting errors way above the cap for the compiler itself? It may well be. Copy and paste often did a better job than that converter seemed to.Quote:
Originally Posted by axisdj
You may well have the same app that you do now, but it will likely run faster from what little I can find on Google. In my experience, it will run at the same speed. As for the not native and de-compilation, that's a false fear as I've already stated. Like I said before, I'm currently re-writing a pair of VB6 apps where I don't have the source code. They will work slightly better than before (because of some advances in availability of external data, not due to code changes), but they will look and feel the same. Any code coder doesn't need your source code to re-create your program. The only question is whether or not they will. You're actually a whole lot better off if they do steal the source code, because you then have legal recourse. You have none if they don't have your source and still write a program that does the same thing (unless you patent the ability to click on something).Quote:
So after all that work I would have the same app as I do now, but it may run slower, is not native and open to de-compilation.
So, if that is your reason, why would you pick Delphi? It's another proprietary language. It has a history of breaking changes that is FAR worse than MS. It's not exactly the first word when it comes to cross-platform. And finally, you already have your hardware interface stuff in a C++ dll, which means that you have all kinds of options available.Quote:
And at the end I am still at the mercy of MS who killed 100k lines of my code for the sake of OOP purity, and can only run on windows.
At this point, you are looking at a total re-write, and just seem to be trying to figure out what to write in. The easy route is .NET, which does give you a route to cross-platform via Xamarin. However, if you are set against that, the obvious choice would be either Java or JavaScript. As much as I dislike JS and feel that it is a language that will change, it is probably the most cross platform, non-proprietary, language in existence today. Yes, it would be utterly different from VB6, but that's not necessarily bad. If you move to something sufficiently similar, you will keep expecting it to behave the same way, so you will keep tripping over what differences exist.
I certainly don't know Delphi all that well, but what you just described doesn't match what I thought I knew about it or what others have said on here. The language started with Borland and is now Embarcadero. What's open source about that? I also don't see anything free other than a free trial.Quote:
So lets say I re-write to delphi. BTW there is a convertor that would convert many of my classes which would speed things up. So what is the benefit: I get a native compiled app, that is able to be run cross-platform, maybe with better performance, on a language that has not broken previous versions completely like vb6- .net, that is open source, and free, with syntax that is more like vb6 than c++(QT Creator). I really think there is no competition here. As much as I hate moving to delphi because of some of the strange syntax, I think it is the right choice for me.
No, it's more severe than that.Quote:
Originally Posted by axisdj
I'm currently working with some stuff that is truly cross platform. I didn't write it, but I know a bit about it. It's a piece of software for writing essentially scripts for data capture, which works across platforms and devices. In our case, we are evaluating not the software, but a sampling script written in the software on Android and iPad tablets. The people writing the script just so some simple and quick work, deploy the script, and it runs on the device in effectively a virtual machine. There is no conditional compilation, it's just a script. However, the behavior on the two platforms is dramatically different. On the iPad, zooming in on a map acts to filter a different dataset, while on the Android it doesn't. The guys writing this didn't add that feature to one and forget it on the other, it's just that the same script had the feature on one and not on the other. It's like it's different software.
You see this with web all the time. If you don't test on all the potential targets of your software, you are going to be surprised by things.
:confused: really?! That's a potentially massive change. Joacim could probably fill in the details but I imagine that could cause the kind of behaviour changes that a compiler wouldn't catch. That would be a complete nightmare.Quote:
Changing data types is hardly breaking everything....
Anyway, as I see it this announcement doesn't change your situation one jot from what it was a month ago. OK, at first I missread it and thought it actually gave you more security, which it doesn't, but it certainly doesn't take anything away. We've all been screaming at you for over a year on this forum that VB6 wasn't coming back and I'm sure we haven't been the only ones doing so. I'm sure you've heard that message from plenty of other sources too. I struggle to believe that you really believed it was coming back so this announcement doesn't change anything. All it's done is removed doubt.
So you're still working in a language who's future is limited. You still know you're working in a language who's future is limited. You still need to either accept that limited future or move to a different platform. You still have the same alternatives available to you. You could still use .Net if you want a familiar and reasonably priced alternative. You could still use delphi if you want an unfamiliar and exhorbitantly priced one. You could still use Java if you want a free and unfamiliar alternative that gives you a good shot at going cross platform. You can still pick C if you're a total masochist (actually I used to quite like working in C back in the day but, Christ, was it difficult to get anything high level achieved). You can still pick an open source option want to make your future REALLY uncertain or would like to spend time writing your own language instead of writing your own app.
Nothing's changed. You're still exactly where you were a decade ago except now you know the end is coming. Stop procrastinating and make a decision. Ten years ago I'd have had some sympathy for your situation but ten years of indecision removes that sympathy. In the words of Woody Harelson: "It's time to nut up or shut up".
https://i.chzbgr.com/maxW500/3408976896/h33375EF0/
I find it alarming that anyone was actually surprised by this. Did you guys actually expect work to be resumed on VB6 ?Quote:
Originally Posted by axisdj
I am alarmed at your ability to be alarmed at anything in this thread!Quote:
I find it alarming that anyone was actually surprised by this.