5 ms·

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

by pixie_ 10y ago

daxfohl 10y ago
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!
frik 10y ago
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.
- cm2187 10y ago
  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.
  - frik 10y ago
    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.
    - snaky 10y ago
      > 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.
      - frik 10y ago
        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.
        snaky 10y ago
        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.
- snaky 10y ago
  > Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner Delphi was much better.
  - mobiuscog 10y ago
    I miss Borland.
    - snaky 10y ago
      Since 1984 (SideKick)
- headmelted 10y ago
  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.
  - douche 10y ago
    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"
    - headmelted 10y ago
      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.
  - GrinningFool 10y ago
    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 https://github.com/rustyio/sync
- louhike 10y ago
  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.
flukus 10y ago
Did you ever maintain vb6 apps? Because I still want to cry thinking about the times I've had to.
- alex_hitchins 10y ago
  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.
  - flukus 10y ago
    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.
    - alex_hitchins 10y ago
      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.
      - pjmlp 10y ago
        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.
        10y ago

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

by pixie_ 10y ago

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

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!

frik 10y ago

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.

cm2187 10y ago
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.
- frik 10y ago
  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.
  - snaky 10y ago
    > 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.
    - frik 10y ago
      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.
      - snaky 10y ago
        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.
snaky 10y ago
> Between 1998 and 2000 VB6 was perfect, you could develop Windows GUI applications in a rapid manner Delphi was much better.
- mobiuscog 10y ago
  I miss Borland.
  - snaky 10y ago
    Since 1984 (SideKick)
headmelted 10y ago
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.
- douche 10y ago
  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"
  - headmelted 10y ago
    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.
- GrinningFool 10y ago
  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 https://github.com/rustyio/sync
louhike 10y ago
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.

flukus 10y ago

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

alex_hitchins 10y ago
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.
- flukus 10y ago
  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.
  - alex_hitchins 10y ago
    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.
    - pjmlp 10y ago
      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.
      - 10y ago