Hacker News Reader

Comment by pixie_ | Hacker News Reader

The most productive I've been as a developer was 20 years ago when I was creating VB6 apps and components...

So true. Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner. The VB6 IDE, the Windows UI guideline, the VB6 API, everything was great. And PlanetSourceCode.com was what was later SourceForge and nowadays GitHub. When I read about Microsoft's vision for .Net in 1999 about applications running as a service over the internet (that was their original idea), I thought that will end the great Windows platform and started looking for alternatives. Microsoft dumbed VB6, but it took them until 2003 to come up with DotNet with a different implementation, it (C# 1) was basically a Java clone with small syntax improvements. The biggest fail was to announce VB.Net and their lackluster Channel9 video that showed the third party developed the converter wizard (VB6 to VB.Net) that barely worked and was free only in the lite version. In the meantime I switched to C, C++, PHP, etc. The web replaced desktop applications in many cases anyway. And nowadays Android and iOS are important targets too. Sadly, the rapid development never got that easy to use as it was with VB6 IDE, with HTML4+PHP with Dreamweaver being almost as fast. But nowadays, the GUI builder aren't as polished and well integrated and don't support all features of the supported languages - so many skip the GUI builder and write the GUI code by hand.

Edit-and-Continue is the greatest productivity feature ever added to a development stack for the real conditions one would encounter in large projects, and it astonishes me even now how misunderstood it's purpose is.

Consulting has me moving jobs a lot and I encounter a veritable kaleidoscope of crappy work. Being able to correct minor issues in scope without restarting, while ten form posts deep in an archaic webforms app with dodgy "we-didnt-know-so-we-rolled-our-own" state management has been a lifesaver. Thank you nineties VB team, it's because of you that I'm not rocking back-and-forth in a padded cell making animal noises today.

If you've ever tried jrebel or even the default hot swap feature on the JVM the edit-and-continue feature feels like a bad joke though. Any non-trivial change requires a restart, and you are forced through a series of distracting button presses and dialogs any time you want to use it.

In Eclipse (for example) you just start typing code, (none of this silly locking the IDE while debugging stuff), and the debugger will update the running program instantly. With jRebel you can even change things structurally without restarting.

Oh how I would love an actually working hot swap feature for .Net.

Does Edit-and-Continue ever work? I'm curious, because I'm almost always forced to build x64-only, because of some libraries we have to use that are 64-bit only, and I've never been able to change code while the debugger is running. Supposedly it is supposed to work in VS 2015, but I'm not seeing it - it's always the nasty messagebox saying "Changes to 64-bit applications are not allowed"

Build 64-bit only or release 64-bit only?

I only ask as I can usually manage 32-bit builds on dev while working, then just test there's no spooky differences when I target 64-bit.

There are issues with some projects that aren't well documented. E+C on web apps on local or remote IIS are a no-go (at least to the best of my knowledge), whereas if you can target IIS express during development it works beautifully.

I've always found that the juice has been worth the squeeze, for values of squeeze that only require me to tweak configuration for my dev box.

I was a huge fan of E&C when I was doing VC++ in the 00s.

I'm not sure about other languages, but with Erlang's hot loading (plus the sync[1] project) I find that aspect to be nearly as good as E&C in Visual Studio.

While it's not quite at the level of 'stop the code from executing, changing something, continue', it's close enough for practical usage - save a file, the underlying module is more-or-less instantly recompiled and loaded.

[1] https://github.com/rustyio/sync

> Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner

Delphi was much better.

I miss Borland.

Since 1984 (SideKick)

I had to do some maintenance on old and messy VB6 code one year ago. I studied best practices to improve the code while fixing bugs.

In the end, I found it hard to do maintenable code for complex applications. And it was not specifically because of the IDE but more because of the way you have to organize the code.

But I did not spend more than some months on it so maybe I'm wrong.

VB.net development is not that different from VB6. It is a way more sophisticated language and therefore can do more complex things. But the basic things take pretty much the same syntax than they were in VB6.

It is and it isn't. VB.Net is basically everything from C# with an syntax heavily inspired by VB6. But the similarity ends there. The RAD IDE of VB6 or Delphi are unmatched, and the compatibility is gone. As WinForms is legacy as well, the whole experience is different anyway. People would like to run their Win32 apps on their smartphone, nowadays you have more luck with Android than what Redmond comes up.

> People would like to run their Win32 apps on their smartphone

And they did actually. Windows Mobile - the original Windows Mobile, 2000-2012 - had 42% smartphone market share in 2007, a native Win32 API (and .Net Compact Framework for C# and VB.Net too), had WinCE kernel and worked on x86, MIPS, ARM and SuperH CPUs.

I loved WinCE/WinMobile back then, except for RAM as document storage - only WinMobile 2005 or so and later supported Flash-storage as well. Though, it supported yet another Win32API implementation with less functions and you had to recompile your code for the target (another reason was: mobile had ARM based CPUs).

All what people like me want is NT kernel, Win classic UI, WinAPI with transparent JIT of x86 exe applications on a mobile device (like WinNT on Mips or DECAlpha or OSX Rosetta). And no nonsense like the metro crap from Win8/10.

Add to it resistive screen with stylus - because it provides much more information density instead of gigantic interface elements catered to fingers-driven UI, with no luck however - fingers are closing half of the screen, unlike a thin stylus - hardware qwerty keyboard and a small optical trackpad, which moves a cursor on the screen or works like two-dimensional Tab button cycling focus between UI elements, depending on mode. Removable battery, and multi-color programmable RGB LED would be nice to have too.

I loved it until the 'trendy' movement toward fingers-driven UI started, around version 6.0.

You mean back when you could type a whole ten characters without twenty new languages and frameworks coming out showing you how obsolete you were? How lame!

Did you ever maintain vb6 apps? Because I still want to cry thinking about the times I've had to.

I have. If they were designed well then they are normally OK to maintain. If they were developed badly then they can take extra effort. Much like any other project in any other language.

If you had an large old Vb6 project build using MVP pattern you would be laughing.

    Much like any other project in any other language.

Yes, you can write good or bad code in any language. But some languages have an endemic culture of not caring about good code. IME, VB is one of them, as is PHP.

All the VB6 code I've seen has been a random mashup of databinding directly to the and click handling. The tools encouraged this approach.

I see your point to a degree. The tools made it easy for folks to get apps up and running quickly, RAD being a popular buzzword at the time. I don't think it's fair to say the culture was that of people who didn't care about the code.

I've certianly seen lot's of terrible VB6 code, but also lots of Vb6 apps that were better designed than some WinForms C# apps I've seen. I know this is all subjective.

My experience tells me that any company whose business isn't selling software, doesn't care about the code.

I have learned the hard way that they don't care one single second about quality, only that it works the way required to support business, anything else is secondary.

In some sense it's true, but what's your point? Still in those companies, a better language/framework can go a long way in conducing better code quality, even if the boss gives zero shit about it.

The boss giving zero shit about it means not getting the approval IT requires to support anything you might want to do.

In such environments even root access is time limited to a few hours and requires a ticket asking for it with a reason that should be validated by the boss.

Reply on news.ycombinator.com