4 ms·

>Today, I feel .NET is overly complex and much harder for beginners compared to the old days. I often see similar statements like that but that's not what I ex

by jasode 2y ago

>Today, I feel .NET is overly complex and much harder for beginners compared to the old days. I often see similar statements like that but that's not what I experienced. I did IBM DOS BASIC, MS GWBASIC and worked on VB3 to VB6 at a corporate jobs. The C#/NET workflow feels much the same rapid-development simplicity as classic VB6: Drag some GUI components like text boxes and buttons onto a form, code the controls' event handlers, build the exe. In contrast, the examples of GUI dev kits that had more complex language syntax and build steps than VB6 were original Apple iOS Objective-C, C++ Qt, Java AWT. Sure, C# is a bigger language than Visual Basic in VB6 but C# also does a lot more. E.g. in VB6, it didn't even have a built-in way to check the existence of a file. Instead, you had to declare a "win32" API monstrosity such as : VB6: Private Declare Function OpenFile Lib "kernel32" ByVal lpFileName As String, lpReOpenBuff As OFSTRUCT, ByVal wStyle As Long) As Long Function FileExists(FileName As String) As Integer Dim RetCode As Integer Dim OpenFileStructure As OFSTRUCT Const OF_EXIST = &H4000 Const FILE_NOT_FOUND = 2 RetCode = OpenFile(FileName$, OpenFileStructure, OF_EXIST) FileExists = (not OpenFileStructure.nErrCode = FILE_NOT_FOUND) C#: File.Exists() In many ways, VB6 being "simple" means it created a ton of extra complexity for the programmer to do basic tasks. Another example is that VB6 didn't include a datagrid. You had to buy 3rd-party VBX/OCX controls for that. C# WinForms includes a datagrid. EDIT reply to: >most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, From my memory the "pure" VB6 way checking existence of a file by opening a file with error handler had issues (other processes using exclusive access and/or other issues) causing false-negatives or false-positives. Therefore, the recommended way back in 1990s was the win32 api declaration using OF_EXIST flag. It looks convoluted but it was more reliable.

AshamedCaptain 2y ago
You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, as in many other languages. No need to import OpenFile for sure.
- Brian_K_White 2y ago
  But then you may have actually opened the file.
  - ahoka 2y ago
    But then the only way to make sure that you can open a file is to actually open it.
    - Brian_K_White 2y ago
      You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed. exists followed by open is a pointless exists because anything can happen in between. Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.
      - gus_massa 2y ago
        You can use it as an improvised lock.
        Brian_K_White 2y ago
        How do you impliment this lock? You use an atomic operation. Which atomic operation? You try to open the file in exclusive mode.
        gus_massa 2y ago
        Create the file to lock and delete to unlock. I'm not sure if there are corner cases.
        2y ago
personalityson 2y ago
Public Function Fso() As Object Static s_oFso As Object If s_oFso Is Nothing Then Set s_oFso = CreateObject("Scripting.FileSystemObject") End If Set Fso = s_oFso End Function Fso.FileExists("path")
- jasode 2y ago
  >CreateObject("Scripting.FileSystemObject") That's not included by default in Windows 95. (A lot of classic VB6 apps of that era ran on Win95.) In contrast, "kernel32.dll" is always included. Even for the later Windows 98, using "Scripting.FileSystemObject" as a dependency was fragile and could fail: https://www.tek-tips.com/threads/forms-do-not-open-in-windows-98.1249659/ https://www.tek-tips.com/threads/forms-do-not-open-in-window... https://www.vbforums.com/showthread.php?135362-running-vbs-files-on-windows-98 https://www.vbforums.com/showthread.php?135362-running-vbs-f...
nurettin 2y ago
This is the worst example you could give. Just add filesystem dll or whatnot from the .net framework as a reference to your project and you can use File.exists from VB.
- jasode 2y ago
  >Just add filesystem dll or whatnot from the .net framework as a reference to your project To clarify, "Visual Basic 6" in this thread's title that everybody in this discussion has abbreviated to "VB6" is the "classic VB" from 1998. There was no publicly released .NET in 1998. That came 4 years later in 2002. Maybe you're thinking of the newer VB.NET.
  - nurettin 2y ago
    yes, I misread thanks
Brian_K_White 2y ago
The sub thread this created of people not recognizing this as a problem is pretty interesting. It's probably one of many ingredients that went into how so many of these apps are so half baked and buggy. Not just the obvious that the language was aimed at and used by junior programmers and so of course much of the code is not robust in general. But here is an example of the toolbox missing a tool. You can't really fault people for doing whatever seems natural using the tools they are given. Not being experienced developers otherwise, they didn't know that something necessessary was missing, and made things that only mostly worked without it. To be clear they would have often mis-used the tool if it existed too. In this thread people have thought the way you would use exists is to check before doing some actual operation. The inexperienced coder aspect is also true, seperately. But the combination of a missing tool combined with a language explicitly aimed at users who don't come with their own experience and don't know anything but what the language provides, seems a little extra nasty.
- AshamedCaptain 2y ago
  Are you literally calling every commenter of this subthread an inexperienced developer? Seriously? First, the subthread starts by claiming you cannot check for the existence of a file, which is simply false. You can try to open it, you can try to read metadata from it, you can glob it, etc. all of it using language builtins. But then you claim that you need to check for a file's existence without actually opening it. If anything, as we people are constantly pointing to you, any code which does it is a code smell at the very least, and very likely wrong. There's a reason TOCTOU is a thing, and why these exist/access APIs usually have huge disclaimers right in the documentation. But let's entertain the idea. Maybe you really have a crappy IPC handshaking mechanism implemented with temporary files (sorry!). Maybe you want to avoid side-effects of trying to open file (virus scan overhead? network traffic?) . It cannot be that you want to preserve the atime, because that would also be a code smell, seing how undefined the atime is on win32. On win9x, for example, reading metadata updates atime - likely the AV scan, but nonetheless; also, the granularity is only 1 day (welcome to FAT). The WA offered by GP actually very likely opens the file anyway, so clearly he didn't have this requirement. But anyway, this scenario is no longer a "simple" feature whatsoever, and therefore the original complain loses all weight. And to top it all, you _still_ can check the existence of a file w/o opening it by just trying to read the metadata, using any of the myriad functions at your disposal, in around two lines of code; no need to interop with Win32 at all. In fact, (trying to) get the file's metadata is exactly how .NET's File.Exist does it. If you find yourself in a situation where everyone thinks you are trying to do a senseless thing, it is more likely you are, rather than everyone else being junior and inexperienced.
wink 2y ago
I know this is a bit of a first-world problem but back in those days[tm] you just slapped 2-3 DLLs into the exe directory and it worked. Yes, I know there were also different versions for different runtimes, but overall it was a couple of DLLs and fine. Since .net you really need to install the distributable by MS, and every new .net upgrade it's the same. Just 2 days ago I apparently needed the .net 8 runtime and even after installing it the app in question didn't work (without a reboot maybe, I will find out later today). Overall, strictly as a consumer, C# and .net apps have been mostly great, except the practice (is it a best practice?) that some of them end up somewhere in my home dir's Local dir and not in c:\program files.

by jasode 2y ago

AshamedCaptain 2y ago

You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, as in many other languages. No need to import OpenFile for sure.

Brian_K_White 2y ago
But then you may have actually opened the file.
- ahoka 2y ago
  But then the only way to make sure that you can open a file is to actually open it.
  - Brian_K_White 2y ago
    You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed. exists followed by open is a pointless exists because anything can happen in between. Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.
    - gus_massa 2y ago
      You can use it as an improvised lock.
      - Brian_K_White 2y ago
        How do you impliment this lock? You use an atomic operation. Which atomic operation? You try to open the file in exclusive mode.
        gus_massa 2y ago
        Create the file to lock and delete to unlock. I'm not sure if there are corner cases.
        2y ago

personalityson 2y ago

Public Function Fso() As Object Static s_oFso As Object If s_oFso Is Nothing Then Set s_oFso = CreateObject("Scripting.FileSystemObject") End If Set Fso = s_oFso End Function Fso.FileExists("path")

jasode 2y ago
>CreateObject("Scripting.FileSystemObject") That's not included by default in Windows 95. (A lot of classic VB6 apps of that era ran on Win95.) In contrast, "kernel32.dll" is always included. Even for the later Windows 98, using "Scripting.FileSystemObject" as a dependency was fragile and could fail: https://www.tek-tips.com/threads/forms-do-not-open-in-windows-98.1249659/ https://www.tek-tips.com/threads/forms-do-not-open-in-window... https://www.vbforums.com/showthread.php?135362-running-vbs-files-on-windows-98 https://www.vbforums.com/showthread.php?135362-running-vbs-f...

nurettin 2y ago

This is the worst example you could give. Just add filesystem dll or whatnot from the .net framework as a reference to your project and you can use File.exists from VB.

jasode 2y ago
>Just add filesystem dll or whatnot from the .net framework as a reference to your project To clarify, "Visual Basic 6" in this thread's title that everybody in this discussion has abbreviated to "VB6" is the "classic VB" from 1998. There was no publicly released .NET in 1998. That came 4 years later in 2002. Maybe you're thinking of the newer VB.NET.
- nurettin 2y ago
  yes, I misread thanks

Brian_K_White 2y ago

The sub thread this created of people not recognizing this as a problem is pretty interesting. It's probably one of many ingredients that went into how so many of these apps are so half baked and buggy. Not just the obvious that the language was aimed at and used by junior programmers and so of course much of the code is not robust in general. But here is an example of the toolbox missing a tool. You can't really fault people for doing whatever seems natural using the tools they are given. Not being experienced developers otherwise, they didn't know that something necessessary was missing, and made things that only mostly worked without it. To be clear they would have often mis-used the tool if it existed too. In this thread people have thought the way you would use exists is to check before doing some actual operation. The inexperienced coder aspect is also true, seperately. But the combination of a missing tool combined with a language explicitly aimed at users who don't come with their own experience and don't know anything but what the language provides, seems a little extra nasty.

AshamedCaptain 2y ago
Are you literally calling every commenter of this subthread an inexperienced developer? Seriously? First, the subthread starts by claiming you cannot check for the existence of a file, which is simply false. You can try to open it, you can try to read metadata from it, you can glob it, etc. all of it using language builtins. But then you claim that you need to check for a file's existence without actually opening it. If anything, as we people are constantly pointing to you, any code which does it is a code smell at the very least, and very likely wrong. There's a reason TOCTOU is a thing, and why these exist/access APIs usually have huge disclaimers right in the documentation. But let's entertain the idea. Maybe you really have a crappy IPC handshaking mechanism implemented with temporary files (sorry!). Maybe you want to avoid side-effects of trying to open file (virus scan overhead? network traffic?) . It cannot be that you want to preserve the atime, because that would also be a code smell, seing how undefined the atime is on win32. On win9x, for example, reading metadata updates atime - likely the AV scan, but nonetheless; also, the granularity is only 1 day (welcome to FAT). The WA offered by GP actually very likely opens the file anyway, so clearly he didn't have this requirement. But anyway, this scenario is no longer a "simple" feature whatsoever, and therefore the original complain loses all weight. And to top it all, you _still_ can check the existence of a file w/o opening it by just trying to read the metadata, using any of the myriad functions at your disposal, in around two lines of code; no need to interop with Win32 at all. In fact, (trying to) get the file's metadata is exactly how .NET's File.Exist does it. If you find yourself in a situation where everyone thinks you are trying to do a senseless thing, it is more likely you are, rather than everyone else being junior and inexperienced.

wink 2y ago

I know this is a bit of a first-world problem but back in those days[tm] you just slapped 2-3 DLLs into the exe directory and it worked. Yes, I know there were also different versions for different runtimes, but overall it was a couple of DLLs and fine. Since .net you really need to install the distributable by MS, and every new .net upgrade it's the same. Just 2 days ago I apparently needed the .net 8 runtime and even after installing it the app in question didn't work (without a reboot maybe, I will find out later today). Overall, strictly as a consumer, C# and .net apps have been mostly great, except the practice (is it a best practice?) that some of them end up somewhere in my home dir's Local dir and not in c:\program files.