Hacker News Reader

Comment by pjc50 | Hacker News Reader

Apple benefits from not being in "Enterprise".

Enterprise is where you have average developers with mediocre managers and ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again. The king of this kind of line-of-business app used to be VB6. There was a brief phase were people wrote intranet applications with embedded ActiveX controls and got permanently stuck on IE6. These days it's more likely to involve SAP or Sharepoint.

These customers made Microsoft a lot of money from all those desktops and Windows Server client access licenses, but they're extremely conservative.

And maybe they have a point; I can see what the advantage of UWP is for Microsoft, but as a developer it's not a clear win over WinForms.

View on HN

Seriously. The true geniuses are the non enterprise startup developers developing in JavaScript.

Wait what...

Edit: There’s nothing wrong with being a JS developer. Heck, my main job is JS. My point is the choice of language hardly determines what kind of developer you are. I’ve seen great developers working on VBA and I’ve seen shitty developers working on C/C++ and Java.

To play devils advocate, I don’t think there are too many terrible developers working on Haskell and Rust though. Yet.

I think he's saying the devs are average because they're in massive corps that hire average devs, who are managed by nontechnical, average middle managers.

Those corps often like Microsoft, so that's what those devs work in.

He's not saying working in Microsoft technologies = not a good dev.

There's a joke about monoids and semigroups in here somewhere but my lack of a college education is hindering me.

Someone has to be "average" by sheer laws of statistics. It's not really a criticism.

Most people are average. As defined by the bell curve

> The king of this kind of line-of-business app used to be VB6.

You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.

And even now, there are few tools where it's easier to make complex LOB CRUD UIs than in VB6.

If by easier you refer to the whole lifecycle of a reasonably secure application, I’m sure that many web frameworks with rapid CRUD builders are much easier, and don’t require distributing binaries, standardizing the desktop platform to Windows, or giving the client binary direct access to a SQL server.

Why not move to VB.NET? I thought the whole point of VB.NET was to give heavy enterprise VB6 developers an obvious non-legacy transition path that doesn’t require any retooling, and only a little (mostly automatic) refactoring.

Microsoft botched VB.NET so completely that there is no path forward. VB.NET was derisively called Visual Fred by VB6 developers because it's essentially a different language that should have a different name.

http://vb.mvps.org/vfred/breaks.asp

It would have been entirely possible to make a CLR version of VB that was 99% compatible with VB6 -- and that's what they should have done. It would have given a clear upgrade path for a huge number of applications. Instead they just re-skinned C#.

VB.NET was 99% compatible with the good parts of VB6. The problem was and remains that every project ever actually written in VB6 was written with at least some of the worst parts of VB6 in use. That list of "breaks" is a lovely list of some of the horrors that probably shouldn't have existed in VB to begin with.

> VB.NET was 99% compatible with the good parts of VB6.

Without backwards compatibility with VB6, there are no good parts of VB.NET. The Visual Basic syntax isn't that great to begin with and VB.NET then added more horrible keywords like `AndAlso` and `OrElse`.

In my opinion, most of that list isn't actually too bad. But it doesn't matter, all the horrors should have been included and then deprecated, giving a smooth upgrade path. Instead all VB6 code had to stay on VB6 as it was no where near 99% compatible. You have a language with different semantics, completely new way of building the UI, and superficial but incomplete syntax similarities. Anyone who was forced to rewrite, and was smart, went to C#.

Sure there is, I have done quite a lot work in life sciences enterprises where VB.NET rules, not R nor Python as many HNers would like to talk about.

Heavy Office users that have outgrown VBA and turn to VB.NET to keep doing their little department apps for data analysis without additional help from IT other than getting Visual Studio on their systems.

Also VB.NET gets all the tooling that C++ and C# get, not like the black swan in .NET, F#.

I know life sciences and I know enterprise

What’s an example of life sciences enterprises

Life sciences that are part of Fortune 500.

Several examples to pick from.

You mean pharmaceutical?

I am being as explicit as my NDAs allow me to.

Agreed that VB.NET is essentially C# in VB6ish syntax to largely accommadate legacy Windows developers

VB.NET has only superficial similarity with VB6. If you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.

that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard. WinForms to WPF is hard. WPF to UWP is a little better but still hard. Yes, they all still run but moving your project to the new shiny tech is very hard.

> you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.

Since C# and VB.NET are essentially equivalent in capability, if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?

> that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard.

VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise.

"if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?"

That sounds obvious. Yet, the group I was in using VB6 thought VB.NET and what people were doing with it looked like it was going to be a bigger learning experience that wasn't just VB6 on a new VM. More like we would be learning a new language, libraries, and so on. So, some of us learned a new language, libraries, and so on with some extra benefits over another BASIC.

C, C++, Java, and C# are where everyone went among those I knew. Some of us kept using stuff with VB6, clones, and/or homebrew 4GL's that were BASIC-like. Most folks just put all that time and effort they perceived as necessary into a language that was a step up. Especially, career-wise.

"VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise."

Correct. But VB6 was the main tool for quick UI development before Winforms took that place. Things that would have been written with VB6 would be written in Winforms once it came out.

I really don't know - I was never in that section of the business. Speculating...maybe they have their framework or some other VB6 piece certified for HIPPA compliance and don't want to change?

That industry is very old fashioned though - another good example is that every blue cross franchise uses the same software to process medicare/medicaid claims, and that software is powered by COBOL. At first it's shocking and you wonder how on earth things stay on the rails...but after a while you get used to it, a strange status quo.

I feel like it makes sense to use COBOL to talk to a government mainframe that’s likely also using COBOL, and likely has a wire protocol specced as a set of ready-to-use COBOL client structs.

Sort of like, in the modern day, it makes sense to use Go if the goal is to write an adapter that takes stuff from your database and pushes it out to some remote consumer that speaks ProtoBuf, and has a ready-to-use ProtoBuf schema.

Because VB.NET is like VB(5|6) in name alone. If an enterprise is going to move to .NET they might as well move to c#.

> ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again.

That sounds like a small startup, too.

(I won't speak to the "average developers" and "mediocre managers" bit, though I assure you they're not unique to big enterprises.)

Although I have to say, VB6 was AWESOME in the late 90s. :)

The same argument goes to Objective-C in the 80s :)

I still find writing Objective-C relatively enjoyable in this decade. It’s much nicer than C++, for example.

And COBOL in the 60s. :-D

VB6 was my first programming language and it was indeed awesome to open my eyes.

There are still no desktop rapid UI dev tools on par with VB6.

There are no rapid UI dev tools anywhere that hold a candle to VB6. Winforms comes the closest. Web development is just a disaster area; I've tried a few things like Bootstrap Studio that try to get something like the ease of slapping together a UI with a visual designer that we used to have, but it is not even close; wiring up events is still laborious because of client-server and data binding, and CSS makes a mockery of attempts to have a WYSIWYG editor. Razor Pages looked like it might have been trending in that direction, but I am unclear whether that is still being worked on.

So I'm hacking away in a text editor, running a babel/webpack compile and bundle process that makes my Visual Studio solution builds seem instantaneous, firing up the app, hard-reloading the page a few times to make sure nothing is cached, then realizing I fucked something up or made a typo, and starting over. It's stupidly laborious and time-consuming. This is not progress.

That's true only for web development. Due to nature of web development is next to imposible to have a good RAD tool that can cover all use cases.

For desktop and mobile there are a few RAD tools. Some of them: QT Creator, Windows Forms, Delphi, C++ Builder X, Mono.

Maybe some are not of the highest quality and maybe there's not enough RAD tools, but that's because many people think that "true" development happens only in VI and command line.

As someone already commented, a good RAD tool can save 90% percent of the time because you don't have to connect by hand signals, events with handlers and you don't have to draw the UI by code, unless you need something specific. Doing this tasks is a tedious and boring work, takes time that is better spent doing something else like working on the app logic.

There is a VB6-like tool for the web! I know, because I co-founded it: https://anvil.works

I have ranted at length before on the reason that the Web is not amenable to RAD tooling. The short answer is that you have five different programming languages (HTML+JS+CSS+Python+SQL), with each component generating source code in another language, and that's impossible for a single development tool to manage sensibly.

To take one example: One of the best things about VB6 was autocomplete. But there's no sensible way to autocomplete what keys are in a JSON value that's been generated by a REST endpoint written in Python serving data from generated SQL, all with about 4-5 different frameworks in the way.

So for Anvil, we dispensed with that and did everything in one language (Python). Python on the front end, Python on the back-end, a Python-native database, a drag-and-drop designer producing UI components that are Python objects...and all of a sudden, it's all one representation and you can autocomplete it!

(I gave a talk about how the autocompleter works at PyCon UK a couple of years back: https://anvil.works/blog/python-autocompleter-pycon17)

I place a lot of the blame for this stagnation followed by backward progress on the fact that a decent number of developers actually have a kind of quiet or even subconscious contempt for ease of use and RAD tools. "Real men" code by hand in a text editor. RAD tools are for wimps. As a result few developers work on them or use them.

It's sad because what developers are really doing here is wasting tons and tons of time. If we had really awesome modern and especially cross platform RAD tools the time savings would be enormous. We could spend that time working on more interesting stuff than wiring up controls to events.

I absolutely agree on you, the entry level of Windows developer used to be lower than other developers. People use visual studio to drag and drop the controls, glue the code all together. You don’t need to type command, you don’t need to understand how the things work behind.

This may be ok for a junior position, and in closed environment. However, people are lazy and not all people are hard core. As a result, there are a lot .NET senior who don’t actually “know” how to code. Nowadays things become extremely complicated, all sort of API, library and framework. Even Microsoft can’t provide a completed solution, and it go back to command line approach with .NET core. I have been recently contacted by my ex-employee who want me to do some C# API communication freelance because their .NET developers just don’t know how to read the documentation and implement them in code.

> as a developer it’s not a clear win over WinForms

Can you put a WinForms app into the Microsoft Store? UWP apps having a marketplace to sell them is kind of a point in their favour, even if it’s an entirely-artificial restriction Microsoft made up to push UWP.

Is the Windows Store a thing that people actually use? I'm broken by decades of Windows use, going back to 3.1 at this point, so I am completely conditioned to installing software off of disks (it's still a thing, I swear!) or downloading from a website. I also run Windows 10 LTSB on all my machines, so there is no Store available there.

The vast majority of the paid software I have consists of games that come from Steam or Gog. Steam really doesn't work well with UWP games, and the Gog stuff I have is mostly nicely packaged DosBox games from an earlier age.

I’m mostly a Mac user, but when setting up a friend’s Windows 10 PC, I used the Windows Store to download whatever apps I could that were available there, and only installed from the web for apps that didn’t have Windows Store versions.

My thinking is:

1. apps on the Windows Store have some level of sandboxing forced upon them, so I can rest assured that the Windows Store releases of these apps won’t make a mess of their computer, even after major-version updates. (Remember uTorrent?)

2. Windows Store apps get automatically updated in the background without ever running them—like apps installed via the OS package manager on Linux. Give some people any chance to cancel/delay an update, and they’ll do it, indefinitely. Better for most regular users [who aren’t relying on any reflexive professional workflows] to have their apps just “be” the newest version, at all times.

The sandboxing part isn't quite true anymore. You can use Desktop Bridge to package win32 apps for the store. These apps are not sandboxed in the way that UWP apps are though they are still kinda-sorta sandboxed (they can access any file the user can, but the appdata folder and registry edits are sandboxed).

There is also some sort of vaguely-stated plan to allow totally unsandboxed win32 apps in the store at some point in the future but seems to specifically only apply to games.

https://docs.microsoft.com/en-us/windows/msix/desktop/deskto...

Aren't games the easiest apps to sandbox? They do everything custom and it's not like they even need an open file dialog.

Except for the copy protection, anti cheat system and the low level access that is required for performance.

99% of users don’t have optical drives anymore so installing software from disks isn’t really that much of a thing anymore. You have to provide a usb optical drive with the disk if you want that and then you might as well provide a thumb drive.

It is, most of the new software I get is via the store.

I believe that restriction has been lifted:

https://www.theverge.com/2019/5/30/18645609/microsofts-unive...

Yes, since two years now.

Reply on news.ycombinator.com