What do you mean by this ? Both VB6, VB.Net/C# can be used to author a wide range of applications.Quote:
Originally Posted by Tanner_H
Printable View
What do you mean by this ? Both VB6, VB.Net/C# can be used to author a wide range of applications.Quote:
Originally Posted by Tanner_H
@Niya:I wonder why they did not respond? Obviously, if they said anything about that then it would made a bigger shame on .Net technology, and they don't want that.Quote:
Microsoft had previously used TradElect as a case study in marketing material to position its Windows operating system as suitable for "highly reliable" systems. It did not respond to requests for comment.
If there's some similar story regarding VB6, then yes. In the future they will definitely need to switch on the another OS, and I think that it would be ReactOS. It seems that it will be the next platform for developing VB6 programs. :)Quote:
Originally Posted by Tanner_H
I don't see .Net being mentioned anywhere in that quote....Quote:
Originally Posted by MikiSoft
And they switched to Linux....use common sense. What does that tell you about where the blame was being placed.
My common sense tells me that .Net should be blamed because that was hopefully the last Microsoft's massive project which was based on it. Just look around and you won't see any Microsoft's program that is running on .Net platform.
And I almost forgot to mention: Before TradElect, Windows Vista was the first to be based completely on .Net technology, and guess what? It was also a horrible flop, so the Microsoft had to recode the whole OS from scratch. That's the reason why they have released it with a delay, and because they were in a rush it was the one of the worst Windows editions ever. If they didn't changed the plan, it would be even worse.
Sorry, I didn't say that very well. The point I was trying to make was: there are very few circumstances where VB6 - or VB.Net - is the *best* tool for the job.Quote:
Originally Posted by Niya
In my personal opinion, aside from existing VB projects, C# is always preferable to VB.Net. There's a much larger development community, more code samples, and the syntax is similar to enough to other C-based languages that porting code from other languages is generally easier. It also gains new features first, and from a job-security standpoint, there are way more positions for C# developers. So unless you're already a VB.Net developer, there's not much point to learning and/or using it.
VB6 is the same way, only 1000x stronger on all points. ;)
IMO, VB6 and VB.Net users should be united against anti-BASIC forces, instead of constantly fighting among themselves. VB6 users don't gain anything from the death of VB.Net (except maybe schadenfreude?) and VB.Net users don't gain anything from the death of VB6.
I do, however, think it would be unfortunate to live in a world where BASIC doesn't exist. Since Microsoft is the primary force behind serious BASIC implementations, and BASIC has a crucial place in Microsoft history, I would like to see their version of BASIC - whatever it is - remain viable.
That may be a pipe dream, however.
I don't think you understand the TradElect story very well. It was a classic case of a company naively using the wrong tool for the job. (And believe me, VB6 would have been the *worst* possible tool for their needs.)Quote:
Originally Posted by MikiSoft
TradElect's problem is that they were using .NET for an incredibly specific purpose - stock trading where even milliseconds of latency can impact earnings - and .NET was simply not designed for that kind of usage. (Protip: neither is VB6!) Accenture also created a horrifying labyrinth of middleware tying together disparate pieces of old and new tech, and as is common with projects of this scale, the whole thing launched long before it was really ready.
Microsoft, for better or worse, took their money and made the most of the contract (what company wouldn't?), but when the **** hit the fan, they totally bungled the PR response, even though the problem probably wasn't even tied to .NET.
There are valid complaints to be leveled against .NET. This really isn't one of them.
But since we're here, I'm still confused about your point in this thread. How does this mantra of ".NET sucks" in any way lead to a new version of VB6 being released? Do you really believe that mocking Microsoft's existing tools will somehow endear yourself to them, so they decide to take your VB6 requests seriously? (This is a genuine question, because I do not understand the current strategy at all. In my opinion, you're just destroying any good will VB6 has left, and if naive VB6 users keep hassling Microsoft, MS is just going to drop what little VB6 support they still offer.)
Ah...I see. Makes sense. Although I'm not too disturbed about C# over taking VB.Net. As I said, the main improvements in my opinion is not the language itself but the IDE and the .Net Framework. I prefer writing VB code over C# code because I'm accustomed to VB code but any argument for or against VB.Net also applies to C#, except for arguments about syntax. C# is a really beautiful language, VB(both 6 and .Net) is very crude and clunky in comparison.Quote:
Originally Posted by Tanner_H
It won't, but there are some people here who repeat that VB6 sucks and think how .Net is the best platform ever. And to be clear, I didn't create any of those requests on UserVoice, I'm just linking to them.Quote:
Originally Posted by Tanner_H
Microsoft deserves to be hassled, not VB6. And if they ever drop it's support, that would be the last in a series of mistakes, but this time with fatal consequences. People already began to dump Windows in favour of Linux so that won't be a smart move, but of course they know that and that's the main reason why VB6 runtime is supported to this day.
Don't try to use logic in thread!!!Quote:
Originally Posted by Tanner_H
https://gallery.mailchimp.com/ca6ae3...s/laughter.jpgQuote:
Originally Posted by MikiSoft
It's important to avoid hyperbole in these discussions. VB6 is not relevant to Microsoft. They already abandoned it once, and there were no consequences. If they abandoned it "for real," there would be no mass migration to Linux. (If you think migrating complicated VB6 apps to VB.Net is painful, you have clearly never tried migrating a complicated VB6 app to Linux. ;) )Quote:
Originally Posted by MikiSoft
Microsoft knows this, and loudly yelling that they're stupid won't change anything.
In my opinion, there are better ways to go about this. For example, what is more likely to motivate continued VB support from Microsoft?
1) 100 cool VB apps, used and loved by thousands of people
2) 100,000 threatening posts on UserVoice
3) 100,000,000 VB.Net insults on vbForums
NB: Microsoft won't abandon developer tools that produce good software. I'm not sure VB6 or VB.Net currently meet that criteria, and it's not Microsoft's fault - it's the community's.
If VB users (of all varieties) can build a thriving community, and produce lots of well-written, professional applications - maybe even some open-source ones! - I think both VB6 and VB.Net could have long, productive futures.
(After a few years of participating in these forums, I would say the odds of that happening are... not great.)
The mobile market has gone through a lot of fits and starts over the years. Through those years 3rd parties have stepped in to provide BASIC in different forms to meet a demand.
Some of those forms were (and are) VB-like, others are closer to traditional pre-Windows BASICs. Many have fallen away as platform churn continued, far faster than desktop Windows changes. New ones have popped up.
So I doubt there is much threat of a "world with no BASIC" any time soon. However there do seem to be a lot of forces weighing in against BASIC out there in the world.
These guys cover all of the significant platforms, with a suite of compilers for several BASIC languages that are close enough to allow a ton of code sharing across the platforms they target. The downside is that a small company is hard for people to "bet the farm" on. What if they disappeared tomorrow?
I use their products, but more often as a "gateway drug" to help companies get legacy code off Windows to the platforms they need to be on today. The people coming from VB or VB.Net get transitioned to these BASICs, and are later guided to Java as the long term tool for future development. The C# guys are taken straight on to Java, skipping some pain.
There isn't a clear path for iOS development though, and most of the planners just hope iOS will die off soon or gain native Java support in the future. More likely the guys using B4i are going to have to bite the bullet and learn Objective-C or Swift.
They didn't kill VB6, they just shot it in the knees. And believe me, if they shot it in the head by dropping support, many people out there won't have choice but to stay on older versions of Windows, and finally to have reason why they should switch to the free platforms like Linux. On Linux you can also run VB6 applications with Wine, so that's not the problem. Another good option is ReactOS.
You already have Planet-Source-Code with millions lines of good VB6 code. And as Windows will now spread on tablets too, all of that code should work, so that would be another productive decade. :)Quote:
Originally Posted by Tanner_H
A perfect summation. Having bet on bad technology in the past (Pascal, Delphi), I'm much more inclined to stick with a known quantity like C++ these days. Love it or hate it, at least it's not going anywhere.Quote:
Originally Posted by dilettante
These "middleware" approaches to BASIC come and go like the weather, but I very much like your analogy of a "gateway drug": they're a temporary solution for existing codebases, nothing more.
Yeah, betting on iOS dying or gaining Java support is right up there with Microsoft-built VB7 on the list of "things that are never gonna happen". ;) Swift is a fine language, and Objective-C has been stable for 30+ years now. It's about as safe a bet as you can get for a developer tool. (Of course, the downside is that you need to need to own a Mac to develop with it, so there's that.)Quote:
Originally Posted by dilettante
I think the original topic of this thread, "What if there was a NEW vb6", is actually a pretty fascinating question. Of all the suggestions I've seen, Olaf's suggestion of a community-driven IDE that spits out LLVM bytecode is arguably the most sound approach I've heard, because it offloads the nastiest part of the compiler chain onto a very good, well-supported project. A solution like that could become a project worth pursuing if enough people felt it worthwhile, but I don't know that we'll ever reach that point as long as people keep wasting energy hoping for a Microsoft-supplied solution.
It's difficult to count the number of fallacies in this single post. A few obvious ones:Quote:
Originally Posted by MikiSoft
- Have you ever actually used ReactOS? I don't think you have. I've followed their work closely for 15 some-odd years now. It is a very impressive hobby project, but utterly useless for serious work. If you doubt this, find me a developer who uses ReactOS as their primary development platform.
- Take everything I said above, and repeat it for Wine. I use Wine regularly (and in fact, have answered a number of Wine-related posts on these forums, since I'm fairly familiar with its inner workings). Wine is a nice stopgap for "emergency" deployment on Linux. It will not work for any serious VB6 project. Again, try setting it up yourself before recommending it as a permanent solution.
- Planet-Source-Code?? That's your argument? When a layperson can download a project from PSC and use it without compiling their own copy (because you know, EVERYONE has a copy of the VB6 IDE), get back to me.
C'mon MikiSoft: we can make a good case for a future for VB, but so far, none of your comments have been serious. We need to approach this thoughtfully, without hyperbole and making stuff up (like ReactOS being a viable Windows replacement).
@tanner_h - what types of programs have you written in c++? Any user-window like apps?
General question - I never thought much about Java. I know a bit about the syntax having coded a proof-of-concept app on an Android device in Eclipse. I always thought it was a client-server based tool for doing web-type apps. Apparently it is also for creating desktop apps. Question - what commercial products are written in Java?
My C++ experience is almost all backend stuff, mostly standalone imaging libraries. I have never been very comfortable doing front-end work in C++. :( (I wish I was better at it.)Quote:
Originally Posted by szlamany
For publicly available, open-source C++ projects, I prefer to participate in other people's open source projects. For example, I submit a lot of patches to the FreeImage library.
An obvious example is the popular PC game Minecraft, which is entirely written in Java. OpenOffice is a mix of C++ and Java. A lot of embedded systems use Java; for example, Blu-ray disc menus and interactive features are all written in Java. Obviously Google's Android mobile OS is powered by Java.Quote:
Originally Posted by szlamany
I don't know if you're familiar with C#, but here's a nice, comprehensive comparison of it and Java. Maybe helpful...?
I swear we are the same person :eek:Quote:
Originally Posted by Tanner_H
This is exactly my experience with C++. I only used it to write DLLs for use in VB6, never a full desktop app and like you, I wish I was better at it. Right now, I'm back to that place. I'm currently, in my spare time, tinkering around in my pet project, Demon Arena and I'm having some serious trouble solving some performance issues. I'm at the point where I believe I need to port some of its most CPU intensive parts to C. I was also wondering if I would even have these problems if it was written entirely in C++ in the first place. Seems VB6 and VB.Net/C# cannot produce a fast 2D engine by themselves. These environments have way too many abstractions so we cannot achieve the godly performance necessary for any 2D engine to manage hundreds of objects on the screen. I'm gonna try a couple of other approaches but I think ultimately, I'll have to go with a hybrid approach, using VB.Net in combination with C++ like I did in the past.
Java is my backup plan when the day comes that I have to seriously consider other platforms beside Windows. Seems to be the best option since it been tried and tested.Quote:
Originally Posted by Tanner_H
Java's big strength was always its cross platform compatibility. In the desktop world, though, users of different OSs generally had different expectations of a UI. That seriously compromised Java's position in that arena because, although it was perfectly possible to write a single UI that functioned in different OSs it wasn't easy to write one that felt right. I think that's why it mostly gained traction in the web world where there weren't really any OS specific expectations from a user. It was always great for writing cross platform back end components (although not particularly performant when stacked up alongside the likes of C). Mobile computing has changed that further because it broke down user's expectations of a UI so, as with web, Java's found a natural home in that environment.
I think Java has always struggled in the desktop world and will continue to do so but anywhere where the expected look and feel carries less baggage it'll be a strong offering.
The truth is browser-embedded Java is pretty rare and has been for quite a while. It suffers from the same kinds of security problems that client-side ActiveX and .Net had, which is why the more heavily sandboxed SilverLight was created but even that's deprecated now. Most people have moved on and live with Ajaxy JavaScript for browser interactivity.
Java was weak on GUI widget libraries for a long time (1995-1998?), but much of the world settled on Swing. Native look and feel portable was pretty much solved for most purposes. When you want true native look and feel you use SWT, which is platform-speciifc and wraps native controls. That's similar to VB6/Win32 controls or WinForms.
However as the world got more and more used to web pages and demand rose for more of a "flow based layout" UI we got new widget libraries. In Java's case that's JavaFX, .Net got WPF. In both cases the result is "native nowhere" and in general one big skinfest (as in skinning) of deviant looking UIs. Microsoft tries to reign this in a bit for WinRT by dictating guidelines you must follow to get into their Store.
But Java doesn't have any desktop UI issues, and hasn't since the late 1990s. For some reason we see this straw man raised over and over here.
Ah, now I have context for threads like the one about Cairo performance. Cool project! I'll pop over to its thread to take a closer look.Quote:
Originally Posted by Niya
You can eke surprising performance out of GDI (and sometimes GDI+), but it's not always pretty. The hardest part is that both pipelines have unpredictable places where their performance suffers, so depending on the task, you'll likely have to mix and match both.
But in most cases, I think it can be done. Right now in my PhotoDemon project, I'm reworking the main rendering pipeline to improve performance on photograph-sized images (10+ megapixels) with tons of layers, and varying uses of alpha, overall opacity, and custom blend modes. Custom blend modes in particular have to be implemented manually, since neither GDI or GDI+ supports them. Despite using VB6 and being single-core and CPU-bound, the program already outperforms GIMP and Paint.NET, so I think there's hope for hobbyists. (Most of the credit goes to modern CPUs, which are pretty incredible feats of engineering.)
Granted, my code is pretty frightening, but I think that's true for any project where performance is crucial, regardless of the language used. :)
And like all NPAPI plugins, Java is totally unsupported on mobile platforms, so that's another nail in its "browser-embedded implementation" coffin. (I find this ironic, since Java was also the go-to language for mobile app development for some time, due to its strong support in Nokia's Symbian OS.)Quote:
Originally Posted by dilettante
I don't see this as a straw man, and in fact I agree with FunkyDexter's explanation.Quote:
Originally Posted by dilettante
Swing does not wrap the underlying OS APIs. It's written entirely in Java, and while it's made to look like various underlying platform toolkits, it still stands out like a sore thumb (in my opinion). Not only are the fine details often wrong, but things like fonts and animations do not even try to mimic the underlying OS settings. While this wasn't a problem so much on XP and earlier, it's pretty noticeable on Aero, and downright terrible on OSX. (Hence the need for other OSX-specific UI libraries, like Quaqua.)
For something like a game with a custom UI, no problem. But for standard desktop software, I don't see many people writing serious apps anymore in Swing... or JavaFX, for that matter. Even major projects like LibreOffice (the far superior successor to OpenOffice) have dropped Java UI components completely.
Outside of the web, I don't think multiplatform front-end development will ever be feasible. Even on the web, it's only become practical in the past few years, thanks to browser vendors *finally* taking standards seriously.
I recommend you implement DirectX rendering with your normal renderer as a fall back. Its performance is truly unbeatable especially on a PC with a powerful GPU. Your custom blending in particular will benefit tremendously if you can find VB6 bindings for DirectX 9 and up. From DirectX 9, one can write their own shaders which would execute on the GPU when you make draw calls. If you re-write your custom blending as shaders, this should give you a massive performance boost. It's quite daunting(DirectX on the whole is too) but I'm resolved one day to learn how to write shaders and use them myself as everything I've read about them and samples I've seen here and there have thoroughly impressed me. I'm far from being a DirectX expert but what little I managed to get working and use over the years hasn't disappointed.Quote:
Originally Posted by Tanner_H
BTW do you have the source for PhotoDemon posted anywhere on the internet ?
Ah nevermind I found a link on your page.
Wow this thread has moved on a bit since i last looked!!
MikiSoft your posts are becoming delerious
What about Visual Studio and Paint.Net ?Quote:
Just look around and you won't see any Microsoft's program that is running on .Net platform.
... but .Net and VB6 are both used primarily for business software and as such your not going to find many examples of big public software offerings made in either of them.
Oh so a bad program is made using a language so therefore that language is crap?? Talk about blaming the tools for a poor job or what!!!Quote:
My common sense tells me that .Net should be blamed because that was hopefully the last Microsoft's massive project which was based on it.
Using your logic considering the multitude of awful VB6 written programs i have seen and worked on over the years VB6 is lucky to still be used by anyone!
MS has made many mistakes not least they where left completely flat footed by the move to Web and Mobile but dropping support to VB6 when it does happen will not be the fatal mistake. The rest of the world has moved on even if you haven't.Quote:
Microsoft deserves to be hassled, not VB6. And if they ever drop it's support, that would be the last in a series of mistakes, but this time with fatal consequences.
Absolute nonsense. People are NOT moving to Linux on the Desktop, even those in the Linux world have pretty much conceded defeat on the standard desktop.Quote:
People already began to dump Windows in favour of Linux so that won't be a smart move, but of course they know that and that's the main reason why VB6 runtime is supported to this day.
Linux is heavily used on the Server in particular web servers, more and more in manufacturing, and now on Mobile. These are places where Linux has already either a growing or big market share, or are markets they have a shot at. (Dilettante i am sure could probably come up with a few others)
99% of Business Desktop users use Windows !! at least for now and probably for then next 10 years at least. Try getting a Secretary to use Linux and see how far you get with that !!!!
Obviously, you know nothing about Linux. It can be also easy like Windows.Quote:
Originally Posted by NeedSomeAnswers
http://en.wikipedia.org/wiki/List_of_Linux_adopters
Indeed, but I never said it did. SWT is the toolkit that wraps native controls. Swing just has skins to help it look a bit more native.Quote:
Originally Posted by Tanner_H
Microsoft ran head on into this with its efforts currently sold under the "Universal Apps" banner. Getting around the need to build multiple user interfaces is probably one of the main reasons they've trashed WinPhone again to make yet another version, this time based on NT. You still have to build multiple UIs for different form-factors, but at least they all use similar APIs for the first time.
I'm not sure this is quite as true as it was just a few years ago. But business in general moves slowly. I see a lot more secretaries using ChromeOS or Android desktop boxes and all-in-ones these days than Linux though.Quote:
Originally Posted by NeedSomeAnswers
Microsoft Office has seen its day and it has passed, which is probably why Microsoft is scrambling to produce versions for more non-Windows OSs. I'm not convinced this will work anymore than its desperate strategies will rescue their vanishing mobile market share.
But no matter how often Microsoft shoots itself in the foot I just don't see Linux (which Linux?) poised to make a difference on the desktop.
I see you are trying to dump these 'groups' together: they are very different people. Those who can adapt, and those that can't. If and when .NET comes to an end, the VB.NET people will migrate to whatever is next; this is the differential. The only commonality is syntax.Quote:
Originally Posted by Tanner_H
Indeed. My adoption plan for when .NET is no longer viable is to open a food truck. Actually, it might be even sooner than that if things work out.Quote:
Originally Posted by SJWhiteley
-tg
Maybe its 97% now then :) i agree though if the traditional desktop is going to be challenged it wont be through Linux but through one of the other competitors you have mentioned!Quote:
I'm not sure this is quite as true as it was just a few years ago. But business in general moves slowly. I see a lot more secretaries using ChromeOS or Android desktop boxes and all-in-ones these days than Linux though.
I don't think it has yet had its day, as to many big companies are completely wedded to the advanced office integration they have, Also Power Excel users don't have anywhere else to go. However i agree that it is no longer quite as dominant as it once was.Quote:
Microsoft Office has seen its day and it has passed
Quote:
But no matter how often Microsoft shoots itself in the foot I just don't see Linux (which Linux?) poised to make a difference on the desktop.
I know enough about Linux, i have built Linux web servers in the past i have tried various flavours on the desktop a few times as well and its just isn't a great alternative to Windows.Quote:
Obviously, you know nothing about Linux. It can be also easy like Windows.
Even the Linux community no longer thinks it will replace Windows on the Desktop!!
Mine is to become your customer. I'd like a Burrito please.Quote:
My adoption plan for when .NET is no longer viable is to open a food truck.
Desktop .Net would probably see me to retirement but towards the end I'd probably be doing dull legacy maintenance work. I've always dabbled in web but have been actively sharpening it up for a year or so and that'll probably allow me to keep doing more interesting stuff. I'm not particularly interested in mobile computing - perhaps I should be but it just doesn't grab my attention. Ultimately programming is just programming and a decent programmer can move between platforms with relative ease if they have to.
All told I'm comfortable that I'm unlikely to starve but I'm hoping you'll offer an OAP discount on that burrito.
If VB.Net users could adapt, they would be using C#. It is better than VB.NET in every way. (Except for maintaining existing VB codebases, as discussed above.)Quote:
Originally Posted by SJWhiteley
Some VB6 users can't adapt. As this thread should have made abundantly clear, some of us use it simply because it is the right tool for certain jobs. It doesn't mean that VB6 is the only tool in our toolbox. Just one of many.
VB.Net users need to stop assuming VB6 users only use it because they're too lazy to use something new.
I've coded BASIC since my PDP/11 and VAX/11 minicomputer days. When I started migrating clients to PC's around 2000 VB6 was my choice - .Net too new - me too new to PC.
In the past 15 years I've slowly landed in JavaScript/jQuery to VB.Net web methods as the best way to serve my clients.
Having done so much JS I am now able to do C# .Net - and I have done so. Did a proof-of-concept WPF app in C#.Net. (Actually have an app in Eclipse on an Andriod as well - JavaScript has helped me a lot)
I see very little difference between VB and C# in the .Net world. VB was forced to get all the same collection and iteration constructs that C# has.
Where do you see C#.Net better in every way over VB.Net??
Snip from my previous comment on the topic (no worries, I don't think any of us can be bothered to read all the replies on this monster thread, hehe):Quote:
Originally Posted by szlamany
Quote:
In my personal opinion, aside from existing VB projects, C# is always preferable to VB.Net. There's a much larger development community, more code samples, and the syntax is similar to enough to other C-based languages that porting code from other languages is generally easier. It also gains new features first, and from a job-security standpoint, there are way more positions for C# developers. So unless you're already a VB.Net developer, there's not much point to learning and/or using it.
I am primarily a C# user and i do prefer the syntax, but the languages are so close these days i don't see what you mean by C# being better??Quote:
If VB.Net users could adapt, they would be using C#.
As far as i am aware the only real differences nowadays are Pointers ( in C#) and XML Literals ( in VB.Net)
As an additional comment, I would say that at present, the "killer feature" for C# is .NET native. The performance gains alone would convince me to switch any existing Vb.NET projects over (assuming the project were performance-sensitive, of course).
I guess if I was ever going to write .Net desktop apps again that feature would matter.Quote:
Originally Posted by Tanner_H
As for it being a de facto cause to migrate...
.Net has other factors that slow it down - not just IL. Based on what you are doing, the GC might be evil to you.
I'm not sure the web method I have in VB.Net would benefit from this feature - building huge JSON strings with StringBuilder is probably all taken up doing just that work.
I am all for C as a better syntax for the business and professional reasons you mention. I would never tell a new coder to go the BASIC path over C syntax - that argument has no support.
But that doesn't turn into a mass exodus to C.
[edit] just playing devils advocate - I personally believe you should have a slew of language choices in your tool belt [/edit]
It's only for Windows Store?Quote:
Originally Posted by Tanner_H
For now. From the FAQ:Quote:
Originally Posted by Carlos Rocha
It's hard to overstate how cool this could be if it actually works as promised, e.g. from the FAQ:Quote:
Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
Quote:
Is this just about performance, or does this also allow for building C# code (say) that is natively compiled to Win32/64 and doesn’t require an install of the .NET Framework on the target machine?
That is correct: .NET Native is not just about performance, but also about productivity and a consistent device experience. .NET Native allows you to write code using managed languages and upload MSIL packages as always. However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.
Does using .Net native mean that people no longer have to worry about obfuscating their applications?Quote:
Originally Posted by Tanner_H
Yeah, no disagreement here. But just like multiple languages in your programming toolbox, I'd say that understanding GC behavior is just part of being a modern developer. (Short of C/C++, most relevant languages - Java, Javascript, etc - are all GC.)Quote:
Originally Posted by szlamany
I was never trying to say that all VB.Net devs should migrate to C#, per se. Just that - in my experience - most VB.Net devs use VB.Net for the same reason a lot of VB6 guys use VB6: maintaining legacy codebases.
For new projects, I think it's difficult to make a case for any variation of VB, unless you just *really* love the syntax. (But obviously, if someone insists on writing new code in VB, .Net is going to be the right choice 99% of the time.)
*Turns on sarcasm detector*Quote:
Originally Posted by szlamany
*RESULT INCONCLUSIVE*
:rolleyes:
That's odd. Mine gave a very definite result :DQuote:
RESULT INCONCLUSIVE
I agree with most of what you've said (it's certainly been one of the more balanced contributions, for which I offer up a heartfelt "Thank You") but I'd take a slight issue with this: " most VB.Net devs use VB.Net for the same reason a lot of VB6 guys use VB6: maintaining legacy codebases".
I think many VB.Net users don't migrate to C# because there's no killer reason to (.Net native aside which I personally think serves a fairly niche set of use cases), whereas the killer reason for moving away from VB6 (with the exception of a few very niche cases) has been apparent for over a decade. I personally did make the choice to move from VB6 to .Net because I recognised I would have a very limited career if I didn't. A few years later I also made the choice to migrate from VB.Net to C# but mostly because I felt it was easy to do and it rounded out my CV which is pretty crucial as a contractor, not because I felt it was an imperative. If I was a permanent employee in a shop that was happy for me to carry on in VB.Net then I think the effort to learn C# would probably be better spent learning the various nooks and crannies of VB.Net - you can't know everything.
Migrating to C# is pretty trivial which is either an argument for just getting on and doing it or it's an argument that you don't really need to until you're good and ready.
I got the idea that .Net Native also tries to extract whatever your Metro Store app needs from the Framework and compiles it in. But I'm less certain that you do not still need some subsetted CLR for core runtime fnctions. Even C++ Store apps need and use a runtime library.
See "So you want to sideload Windows fart apps... headache #783" C++ Runtime for Sideloaded Windows 8.1 apps.
lol, you never know in this thread!Quote:
Originally Posted by FunkyDexter
All fair points, and I'd be hard-pressed to disagree. If there's one point of contention I'd make, it's "the killer reason for moving away from VB6 (with the exception of a few very niche cases) has been apparent for over a decade."Quote:
Originally Posted by FunkyDexter
I'd say this would depend a lot on the application and the developer. For hobbyist or non-professional developers, their choice to stay with VB6 has become oddly justified. I don't think any of us expected VB6 support to be so solid a full 15 years after it was deprecated. For people without the time or inclination to learn something new, they've gotten pretty good bang-for-their-buck with VB6.
For professional devs though, no argument that they should have moved on a long time ago for their own career viability.
I think there's also an argument to be made for companies, particularly SMBs, who have stuck with VB6 apps that are currently in "maintenance-only" mode. Getting 15 years of use out of an application is pretty remarkable, especially in an age where things like web apps have to be reworked every time a new browser releases. (That's a little hyperbolic, but you know what I mean.)
Yeah, I'm sure this will be a much more complicated problem to solve when the desktop version releases. I wouldn't be surprised if you're right about some subset of the CLR being required (although given how much of the CLR just calls into core WAPI functions, inlining just the CLR-specific parts may not be too terrible...? IDK).Quote:
Originally Posted by dilettante
As long as we're reading tea leaves, I expect this was much less about desktop development, and much more about improving mobile app performance, where the interpretation hit is a lot more meaningful for not just performance, but battery life too. iOS apps have been native-compiled since day one. Android has supported some form of native development since 2009 via the NDK.
Windows Phone already has a plethora of hurdles to deal with, but hopefully .NET Native can remove a few more.
I love the .Net Native idea for two main reasons. One, it provides natural obfuscation. .Net EXEs are far too easy to decompile. And two, it relieves you from the extra responsibility of checking for the and installing the correct version of the Framework. As I understand, it would perform some form of static linking during compilation.
However, there is one single major possible reason that I don't want to see .Net Native come to fruition, it may completely break reflection. For quite some time now, I've been quite reliant on the reflective capabilities of the .Net Framework. Reflection is quite possibly the single most useful ability to come with .Net. However, for it to work correctly, the EXEs and Dlls must have metadata and MSIL code itself sometimes acts as metadata. .Net Native is going to break reflection in some way. It is not worth it in my opinion. If this ever becomes standard and they do indeed break reflection, that would quite possibly be the beginning of the end of the love affair between me and .Net.
Given that .Net has had free express versions while 6 cost hundreds of pounds or had to be... ahem... independently acquired... I reckon they'd have had more bang for less bucks from .Net but I do know what you mean. I don't think MS ever envisaged that they'd still be supporting it after all this time. I know I certainly didn't when I decided to switch. I personally reckon that's mainly due to the fact that VBA never got replaced as the language behind office but there's a variety of reasons if you choose to go looking.Quote:
For people without the time or inclination to learn something new, they've gotten pretty good bang-for-their-buck
SMBs and maintenance only apps are an interesting case. I've always argued that migrating an app purely because you want it to be in a new language is insanity - you re-engineer when you need to, not because you saw something shiny and wanted to chase it. My experience was that I had a few clients with VB6 (or in one case VB3:eek:) apps that they wanted maintained beyond the early millennium and I was able to make a bob or two supporting them for a whole but they inevitably found that their own worlds moved and at some point they all changed direction, either by paying for a rewrite or just buying in a completely different product. I can honestly say that I am no longer aware of anyone still using it - which is not to say they don't exist, just that they've dwindled to a largely irrelevant market that's no longer worth me targeting.
I'm really talking about bespoke apps there though, and I do have some sympathy for folks that developed an off the shelf app in VB6 and then saw active support removed. Such sympathy as I have, though, is tempered by the fact they've probably had the best post deprecation support the IT industry has ever seen. If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with. So if I see someone say "I've never migrated my app and now I'm doomed and it's all Microsoft's fault" then I don't really have any sympathy. If, on the other hand, I see them say "I never bothered migrating because I guessed right that MS would never quite drop support and I've saved myself a mint on migration costs, Suckaz", then I'm inclined to pat them on the back and respond "good call, dude, good call".
The implication is that VB.NET developers will be in the same boat as VB6 developers. As already noted, the transition to C# is actually quite trivial step from VB. If the .NET platform goes away, there are a whole host of other technologies - web development which has a fairly strong market share is not reliant on .NET in any way shape or form. I believe most .NET developers have more than a passing familiarity with web-based technologies (e.g. JavaScript and associated libraries).
VB6 does not give 'hobby developers' any bang for their buck, and has not for well over a decade. It was easy to learn, but at a dollar cost. VB6 allowed someone with no programming skills to create applications; the similarities between VB6 and VBScript demonstrate this, and why VBA has not gone away, as atrocious a programming language that it is (it served a purpose).
the .NET (Express) opened up 'real' programming practices to the non-programmers. Those without programming training, education or skills would find .NET very daunting and overly complex. Much like any other skill, just because you have the tools, doesn't make one a craftsman in that field. This is where VB6 was lauded as an amateur language; it didn't have the rite of passage that the real programming languages demanded.
This is so true. This is half the reason that VB is so despised by programmers with a non-BASIC background. It is considered a toy language and one only has to look at languages like C, C++, ASM, hell even Pascal to understand why. However, this is not a bad thing, the language is called BASIC for a reason, its meant to be basic. And while back in the day I used to scoff at the elitist attitudes of C/C++ programmers towards VB, it wasn't until I started writing C++ code myself that I understood just how justified they were. VB.Net tries to correct this and while it succeeds, its far too late. QuickBasic and earlier incarnations of VB have already cemented the status of any thing based on BASIC to be amateur.Quote:
Originally Posted by SJWhiteley
Isn't that the point though? VB6 did enable non-programmers to produce functional apps and I think that's a good thing. Us "trained professionals" can sit in our ivory towers and pour scorn if we wish but those non-programmers produce ALOT of working functionality for the companies they work for, whether that's excel macros, python scripts, batch files or any other medium that enabled them to get the job done.
Where I think I really differ is in the belief that .Net is daunting - or rather that it has to be daunting. The actual act of throwing together a simple single form app that does some simple work is really no different in .Net than it was in VB6. I think the problem non-programmers face is that .Net framework and the ide has loads of features they don't care or need to know about at first and that, I can see, can be intimidating. Then they go on line to look up how to find an item in an array and they're presented with Linq and Lambdas before they've really had a chance to just loop it and do a comparison. They get information overload.
IMO, if MS want to make .Net accessible to the masses in the way that VB6 was all they really need to do is provide a beginners version (or a beginners "mode" in the full version) with a cut down framework and some tutorials right there in the IDE so the user doesn't have to go to google the first time they get stuck.
It goes so much further back then that.Quote:
Originally Posted by Niya
When I used PDP/11 machines (back in HS - 1979) you sat at a READY prompt - on screen or paper terminals.
You typed things like NEW "FILENAME.BAS" - SAVE, RUN - and code lines as well.
PDP/11's where BUSINESS machines - most schools had them and ran student admin packages like attendance on them. Colleges used them for billing.Code:Ready
10 PRINT 'HELLO WORLD'
20 END
Run
HELLO WORLD
Ready
TRS/80's from Radio Shack behaved the same way.
Primitive file statements are unlike regular language constructs for many of these reasons (like NAME AS)
From a wiki link
In 2006, 59% of developers for the .NET Framework used Visual Basic .NET as their only programming language
VB6 Control Creation Edition was free for anyone. The primary limitation was no compiling to native code, but for beginners, that wasn't a deal-breaker.Quote:
Originally Posted by FunkyDexter
So true. I always go back to the seminal article on code rewrites: Joel on Software - Things You Should Never Do, Part I.Quote:
SMBs and maintenance only apps are an interesting case. I've always argued that migrating an app purely because you want it to be in a new language is insanity - you re-engineer when you need to, not because you saw something shiny and wanted to chase it. My experience was that I had a few clients with VB6 (or in one case VB3:eek:) apps that they wanted maintained beyond the early millennium and I was able to make a bob or two supporting them for a whole but they inevitably found that their own worlds moved and at some point they all changed direction, either by paying for a rewrite or just buying in a completely different product. I can honestly say that I am no longer aware of anyone still using it - which is not to say they don't exist, just that they've dwindled to a largely irrelevant market that's no longer worth me targeting.
I'm really talking about bespoke apps there though, and I do have some sympathy for folks that developed an off the shelf app in VB6 and then saw active support removed. Such sympathy as I have, though, is tempered by the fact they've probably had the best post deprecation support the IT industry has ever seen. If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with. So if I see someone say "I've never migrated my app and now I'm doomed and it's all Microsoft's fault" then I don't really have any sympathy. If, on the other hand, I see them say "I never bothered migrating because I guessed right that MS would never quite drop support and I've saved myself a mint on migration costs, Suckaz", then I'm inclined to pat them on the back and respond "good call, dude, good call".
As for "If 15 years wasn't enough time to viably migrate your application then the application wasn't financially viable to begin with," we must work in different fields. ;) This is no different from companies who built some horrible web app in ActiveX and are now tethered to IE6 forever. (Yep, I steal deal with this WAY more often than I'd like.)
Maybe it's an American business thing, but I have worked for far too many places where the approach to code maintenance was "do not migrate until the end of the world." Hacks, VMs, dedicated boxes running insanely old OSes - whatever it takes to keep working code working.
I used to think businesses like this were crazy, but honestly, the older I get, the more I subscribe to "if it ain't broke, don't fix it." I'm sure there are exceptions, or maybe some nice formula you can use to estimate the costs of maintenance vs rewrites, but idk... there are so many new problems that need solving, that I can't blame companies for wanting to rewrite or migrate until the last possible instant.
(Of course, when I'm the guy stuck deciphering ancient FORTRAN code and trying to figure out how to rewrite it as a modern web app, I'm a little more furious about this...)
Oh please - not this tired argument again.Quote:
Originally Posted by SJWhiteley
There is no magical demarcation between "real programming" and "fake programming". If you are typing out instructions for a computer to follow, guess what? You're doing programming.
.NET did not magically make programming "real" for hobbyists, any more than BASIC or HTML or Javascript any other language did. Languages like LOGO were helping the masses understand programming long before VB even existed!
Sorry, but this is just silly. Why do you think many universities and community colleges use .NET as part of their intro to programming course? .NET development is cake compared to C/C++, so I have no idea why people think it's some kind of mythical terrifying thing. (VB6 guys might make this argument, and if they do, they should be called on it, because it's idiotic.)Quote:
"Those without programming training, education or skills would find .NET very daunting and overly complex."
Please stop parroting the ridiculous argument that some kind of "rite of passage" is required for True Programmers (tm). There are hobbyists who write better code than guys with Ph.D.'s and thirty years experience. Good code is good code, regardless of the source, and regardless of the language.
While I'm certain there was a VB5 Control Creation Edition (I have a copy here) I'm not sure there was ever a VB6 Control Creation Edition (and if there was I don't think it was free but possibly part of VFP 6 or possibly the same as the VB6 Learning Edition only legally distributed on books with CDs).
As far as "newbyism" goes, I'd think if anything VB.Net is a far better choice than VB6. I say that because Microsoft has updated to tools to make it easier for the novice to create working programs on current versions of Windows. You also get easy use of ClickOnce.
Producing and deploying VB6 programs that work properly can be a far tougher thing since the VB6 community was long ago abandoned to live or die on its own. This means you can't rely on intro books or stuff downloaded from POS Code any more, you need to know a bit more about Windows and be a lot better at reading Microsoft documentation and making use of the Windows SDK. Windows has changed substantially since 1998.
We see a lot of this in the question threads on VB6. A good number of them deal with UAC, deployment, Unicode, and other issues VB6 didn't have to "worry about" at release. Anyone can cope with these given some effort, experience, familiarity with the documentation, and good reading comprehension. The "pro" is more likely to have these but it doesn't preclude dedicated hobbyists from getting there as well.
There are people who stumble as novices with a first programming language. They reject it, blaming the tool, and move to a second. Once they make progress with the second language they acquire a confirmation bias and their rejection of the first one becomes more extreme.
This reminds me of back when I had a regular full-time job before I retired.
Back around 2004 there was a push to migrate several major mainframe application suites to "another platform" and Windows was chosen. This was put under the direction of a 3rd party consulting company, and "fire one" was "Let's do all of this in C#!"
The full-time programmers were sent to 3rd party training, teaching Microsoft's official curriculum. These were 4 and 5 day intensive courses with labs using Microsoft's training materials. The idea was for the staff to work with the vendor during the "porting" process and take over maintenance once conversion was complete.
The progress was amusing.
The full-time ASP.Net guys came in cocky, but they failed to complete the first 4-day course!
The VB.Net "desktop" guys made it through the first course, struggled with the second, and failed to complete the third course.
The old-timer Cobol guys struggled with the first course, then aced the second and third. A couple of former systems programmers with multilanguage background being retreaded as application developers were able to sleepwalk right through all three courses.
Then the conversion project smashed right into a wall after two years of effort. It got about 1/10th of the way along in that time and the users and testers got totally fed up with the poor performance of this system, front-ended with Ajaxy ASP.Net, middle in C#, and SQL Server as the database.
It just couldn't cut it... at all. Even with a load of 10 users!
Back to the drawing board, and a year later the vendor came back. Now they proposed a fatter-client approach using VB.Net, discarding ASP.Net for anything but a few minor public-facing interactions.
No training this time. The vendor would do 90% of the conversion with a new team, and the local guys were told to just keep up.
The ASP.Net guys were worthless, and the VB.Net guys were removed from the project and sent back to maintain their existing code. Only some of the Cobol and formerly-systems folks were involved in the programming, and everyone else was forced to do little but unit testing.
The last I heard... even this many years later only a small fraction of the job was done, working as a parasite on the existing mainframe suite. This vast waste of money, effort, and time has made the newspapers a number of times.
What does this show?
The language doesn't make the man, the man makes the language. It is far less about the tools than the workman.