Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft plots the end of Visual Basic

thurrott.com

Post reply on HN
Print view View original

281–290 of 292 posts

Re: Microsoft plots the end of Visual Basic

#281

Post by pjmlp »

pragmatic wrote: post #277
beholder1 wrote: post #184

Earlier quoted context omitted.

You write: > ...astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97 Thay were not "glaringly missing in the Java world" in 1997 when Visual Studio was released. By that time at least these 2 IDEs with "drag and drop" were released and used already: Symantec Visual…

Java GUIs were weird purple garbage in those days. Horribly slow, painful to deal with.

That is what happens when one stays with AWT, does everything on the main thread, and doesn't bother to read Java UI design books like Filthy Rich Clients, or integrate component libraries like JGoddies.

However I do agree Visual Basic and Delphi were much better, and if Java hadn't happened we wouldn't have lost 20 years playing around with VMs and dynamic languages, to finally start paying attention to AOT, value types on type safe languages.

Re: Microsoft plots the end of Visual Basic

#282

Post by pjmlp »

Fr0styMatt88 wrote: post #259
ptx wrote: post #246

Earlier quoted context omitted.

This behavior? https://devblogs.microsoft.com/powershell/suppressing-return... It seems like it might make some kind of sense, since it doesn't output directly to the console but rather to a pipe. Bash functions sort of work the same way since they don't have complex return values (aside from exit codes) other than the function's output stream.

Yeah, keep in mind that the output is a fully-fledged object, it is not the text you see. The text is generated by the PowerShell host if the returned object makes it back there and the host is set up to present that object to the user that way. Take the following in PowerShell: ls | sort DateTime -d ls returns an array of objects, sort then sorts the array by each object’s DateTime field (and here I’m asking it to s…

Yeah, PowerShell is the only mainstream shell that behaves like the REPL environments from Xerox PARC workstations.

Structured data with direct access to any OS API, regardless how it is provided, .NET, COM or straight C like DLL.

UNIX world never had that, beyond trying to fit language repls as user shell, which on UNIX always feels like a leaky abstraction.

Re: Microsoft plots the end of Visual Basic

#283

Post by DaiPlusPlus »

int_19h wrote: post #211
DaiPlusPlus wrote: post #99

Earlier quoted context omitted.

IIS ASP and the Shell CScript/WScript hosts are just environments for the COM-based Active Scripting engine. At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically. Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/serv…

I wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls. Even as late as 2010, COM support…

I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications.

VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool!

While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem).

Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process).

I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.

Re: Microsoft plots the end of Visual Basic

#284

Post by 7thaccount »

kjaftaedi wrote: post #12
rkagerer wrote: post #6

I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one. As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debuggin…

I used to think this too, but everything you can do in VB6 you can do in powershell, and do it better. Try/Catch, windows forms.. literally anything you can think of. You can even mix powershell and C# together in the same script. Once I realized I had a better version of everything I wanted, it became my new favorite.

Just remember that parsing text files (big for me) is glacially slow in Powershell due to all the object mess. I enjoy most other things.

Re: Microsoft plots the end of Visual Basic

#285

Post by mlazos »

kjaftaedi wrote: post #12
rkagerer wrote: post #6

I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one. As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debuggin…

I used to think this too, but everything you can do in VB6 you can do in powershell, and do it better. Try/Catch, windows forms.. literally anything you can think of. You can even mix powershell and C# together in the same script. Once I realized I had a better version of everything I wanted, it became my new favorite.

Mixing c# and power shell in the same script is amazing. You can load methods from DLLs on the command line as well. I had to do this when I didn’t have permission to run unregistered exes on a server I was debugging. Luckily the admins didn’t restrict powershell and I ran my main method from a script.

Re: Microsoft plots the end of Visual Basic

#286

Post by badsectoracula »

laumars wrote: post #209
badsectoracula wrote: post #117

Earlier quoted context omitted.

I'm not sure what you have in mind but in the 1975 dialects of BASIC the code was something like 10 REM Grab input 20 GOSUB 1000 30 IF VALUE=BAR THEN GOTO 100 40 IF VALUE=BAZ THEN GOTO 200 50 IF VALUE=BLA THEN GOTO 300 60 GOTO 20 100 REM Bar stuff 110 blahblah 199 RESUME 200 REM Baz stuff 210 blahblah 299 RESUME 300 REM Bla stuff 310 blahblah 399 RESUME 1000 REM Code that grabs input 1010 blahblah 1100 RESUME Or just…

I don't think that example you've posted is right (the grab input one, not the game on Github). Firstly, RESUME was to continue execution after an error (eg ON ERROR RESUME NEXT). I think RETURN is what you might have meant? Secondly, you cannot RESUME/RETURN from a GOTO. I think you meant GOSUB; which was a crude approximation of subroutines. BASIC did also have GOTO as well though.

Yes you are right, i meant GOSUB/RETURN. Though instead of "RESUME" (which should have been RETURN) most programs would use GOTO 20 (in an opposite expression of what Dijkstra wrote about, i accidentally used a 'function call' idiom instead of a spaghetti 'jump wherever' one :-P).

Re: Microsoft plots the end of Visual Basic

#287

Post by marcus_holmes »

dragonwriter wrote: post #115
marcus_holmes wrote: post #65

Earlier quoted context omitted.

to me, that was always a great example of the difference between IT and CS. I totally understand how someone trained in VB was "mutilated" for CS. Because the priorities for CS coding are totally different than for commercial coding. But from an IT perspective the point of programming is to be profitable, not perfect. VB allowed people to write profitable programs quickly. It was a fantastic environment if all you wa…

> I totally understand how someone trained in VB was "mutilated" for CS The quote isn't about VB; its from 1975, VB was released in 1991.

The quote is about BASIC. Visual Basic is a variant of BASIC.

The quote was also thrown around a lot in the late 90's as a "VB sucks, you should use a real programming language" comment in the usual language flame wars.

Re: Microsoft plots the end of Visual Basic

#288

Post by jkingsbery »

Koshkin wrote: post #57
jkingsbery wrote: post #11

I first learned how to program in VB4. I can see why as a professional programmer it lost favor, but it was a great learning language.

> great learning language E.W.Dijkstra would disagree: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

Certainly, the next few years of my learning to program was unlearning ideas I had developed from coding in Visual Basic. But it gave me the start in understanding how functions work, how sub-procedures work, and how objects work. More importantly though, Visual Basic gavve me the excitement and possibility that I could make this thing on my family's desk do pretty much whatever I wanted. And Visual Basic made that very accessible.

Re: Microsoft plots the end of Visual Basic

#289

Post by trent_lott »

tmh88j wrote: post #175
trent_lott wrote: post #91

Earlier quoted context omitted.

Quickly and easily design and make a GUI program with n real training? VB6 got me into programming as a kid. I mostly use python for stats stuff. I sorta understand how to run up a GUI using tkinter, but it seems like a huge pain in the ass. I'm sure Visual Studio offers the ability to do whatever VB6 could with a GUI, but it isn't obvious how to get there. VB6 was one nice thing - build 'a program' as you understand…

Curiosity got the best of me so I have to ask...why Trent Lott? Without an explanation I find the seemingly pure randomness amusing. edit - I'm guessing whoever downvoted doesn't know who Trent Lott is.

It wasn't exactly sure randomness. I was registering for some band forum as an edgy teen and he was on CNN stroking Strom Thurmond's ego

It's wierd enough that any old niche forum friends I've lost touch with would recognize it...and I can't imagine anybody else would use it coincidentally. He's been a non-figure for years and years

Your curiosity demands more upvotes than I've got!

Re: Microsoft plots the end of Visual Basic

#290

Post by int_19h »

DaiPlusPlus wrote: post #283
int_19h wrote: post #211

Earlier quoted context omitted.

I wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls. Even as late as 2010, COM support…

I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications. VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (…

I think we need to distinguish between COM and OLE/ActiveX here. COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. OLE is much more challenging, because the UI framework needs to be aware of it, and because it's built on Win32 UI primitives - so any framework that doesn't use those is going to have issues much like WPF (Qt is another example).

Bitness is not a new problem - VB6 similarly has problem consuming COM components written in C++, but compiled as 64-bit. Or, to put it another way: VB6 didn't have a problem, because 64-bit wasn't a thing back when it was popular, and didn't really became common on Win32 until relatively recently. But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.

Getting back to OLE and ActiveX - I would say that it was killed by Microsoft directly, not because of .NET. Back in the day, most non-trivial Windows apps made by MS supported OLE for embedding - this was most commonly used with IE, but you could also do it with e.g. Word and Excel... until you couldn't anymore. If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.

Post reply on HN