I spent 90% of my 30-year career in this way. What I learned over time is that you become much more self-sufficient in problem-solving and learning. Having only worked in a couple of larger companies, it was easy for some people to hide. If you were lazy, there was little incentive to learn, as you could simply ask someone else for help. However, if you're a self-starter and eager to learn independently, you may find that this trait becomes a significant asset later on. Depends how much time you are sat reading HH :) on a serious point - the other comments below are all good advice. Going to meetups, user groups etc also were very beneficial to me in the early years - sadly face to face user groups are less in vogue now since the internet took over.
I started in Visual Basic 3 and then moved to Delphi. My first job at 18 was working for one of the large ActiveX component libraries, providing technical support to many developers when I wasn't one myself yet!
On my first day, I found a book on my desk—"Learn Visual Basic 3 in 21 Days"—along with a brand new 486DX250 and a 14" monitor. I learned a lot quickly! We answered support queries by fax back then.
I never fully understood why this programming paradigm died off. Building business apps beyond Access or Excel was so straightforward. It was great to get an .EXE that you could package up with InstallShield or Wise Solutions and send to anyone.
I guess the web came soon after, and trying to do WYSIWYG for HTML and CSS has never gone well—even today.
FrontPage came out but died soon after, and mixing desktop apps with web apps was never great.
Today, I feel .NET is overly complex and much harder for beginners compared to the old days.
Sometimes, I think there are only so many ways to control the appearance of business apps. I'd constrain visuals but provide the most straightforward visual builder possible.
The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.
Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.
I'd love to have a visual builder that creates code you can host yourself — something like retool.com but with open source and self-hosting, or maybe I'm just too old for this now! :)
> I never fully understood why this programming paradigm died off
My two cents --
A few reasons (briefly, I could have talked a lot more)
* Shift in platform: Windows is no longer the sole platform people want to build their apps for. Not a bad strategy by itself, and lots of companies still only develop for Windows (e.g. specialized software for instrument control etc), but people increasingly want their stuff to work on iPad, Chromebook etc and maybe even phones
* Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.
* Software and their UI got a lot more complex and require more expertise. On the other hand commercial software becomes easily available and accessible for those purposes. For the examples you mentioned -- stock control system, sales tool, they may be fine with VB6 for a prototype but can quickly get complex. And there is likely a commercial software you can buy and download within a few minutes at an affordable price.
* Shift to online/cloud: vast majority of "small VB6 applications" were used locally, and they never connect to the Internet. That's different now.
* Shift in language: BASIC/VB was often used for teaching, and it is indeed great as a first language to learn. Although Python already existed at that time, it became very popular, and I think many people would agree Python is a much better language than BASIC, in many ways. As a result, BASIC along with VB went out of fashion.
I've always found the use of anchors on UI controls to be light years ahead of what HTML/CSS have been doing. I always used to create UI forms with resizing and different screen sizes in mind. If you were coding for a hard coded 800x600 screen then that was just laziness.
It's a bit ironic how in the same breath you go from "it's impossible to build apps for multiple resolutions with drag'n'drop hence web" to "software and their UI has become more complex".
While the absolute vast majority of web-based software cannot hold a candle to UIs you could trivially build in VB (or Delphi and other RADs). Most web-based software is either trivial forms or a few screens of text and images they struggle to display with any acceptable performance.
As for "many different resolutions and screens", have you ever, I don't know, resized a desktop window? Desktop apps work at the number of crazy sizes the web would die at.
I think you left off the biggest reasons, commercial:
* No piracy. Can't crack code you aren't running.
* Immediate installs/updates. No need to tell people to ever update stuff, or to install your program in the first place.
* You can charge subscriptions. It's much easier to justify a subscription when you pay for server costs, even though the customer would be happier just running your application locally.
* Easier deployment. You can handle complex integrations on the server, without the customer having to open ports or whatever.
Good points. I was more focused on the technical side.
I want to add a bit more to "easier deployment" -- traditional model is that you push updates at some interval (regular interval like semi annually/annually or non regular intervals), and you need to manage multiple versions and potentially patch multiple versions for severe bugs or security issues. Lots of software still works that way. But with office 365, jira etc you only have one version to worry about. Of course it means different risk levels, SLAs etc, but that's a different topic.
> Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.
This... really doesn't match my experience at all. I may be thinking of later UI development tools from the .NET era (I no longer recall if VB6 had proper support for linear layouts and the like, that was forever ago) but GUI builders with responsive controls were absolutely a thing, and they ran circles around any "responsive" CSS we have today, if only because they had instant feedback. I don't miss most aspects of programming from that age, but this is one that I do miss tremendously.
Edit: I certainly agree on the other points. I think this one was less of a technical limitation and more due to the humans in the loop; lots of people just didn't know better, information dissemination was far more limited (lots of us learned these things offline, from books and the like), and the platform didn't force you to do the right thing, either.
> Shift to online/cloud ... they never connect to the Internet.
The fall of VB6 style RAD (for CRUD) started earlier with shift from "workgroups" (shared files on LANs) to client/server. This severed the direct link (ADO api) between apps and their persistence.
Tragically, the ODBC (then JDBC) API interface didn't quite fully bridge the gap. Meaning some necessary metadata was no longer front and center (for both compile and runtime, like ADO had always had). Yielding mitigation attempts like DAO/DTO, ActiveRecord, ORMs, LINQ, templates, etc.
Of course, client/server had to happen. But the innovators (and critics like Neward) didn't fully understood what they were replacing, what parts were missing. (Lather, rinse, repeat.)
--
It took noob me a LONG time to figure this out. (All I ever wanted was to recover the special magick of VBA + ADO.) And then even longer to attempt mitigation (cuz am noob).
Maybe if we had the new "internet's hourglass shape" analytical framework from the beginning (vs say OSI's layer model), someone(s) could have prevented the oversight. https://cacm.acm.org/research/on-the-hourglass-model/
> Software and their UI got a lot more complex and require more expertise.
In the B2C space sometimes sure. We do business with many companies all over the world and if you can see the 100s of 1000s of apps they are using; you could've done all of them with Delphi/VB without any tricks. Except now some incapable but suave talking Nextjs fanboi walked in and pushed all that overly complex nonsense while it's not needed for almost anything we see used in companies. Spending fortunes on stuff you should just click together in a few minutes and hook up a db. But yeah, we make nice money because of it for both of my main businesses; 1) fixing completely broken stuff because the person who introduced the tech left quickly after introducing the misery 2) creating LoB/ERP custom applications. Both are goldmines and both are goldmines because of the tech losers (resume driven 'workers' almost always) around the world who preach to always use the 'best tool for the job' and then completely do the opposite, introducing tools that really have no place there, ever.
And then the joke of course that they are not even really good at them, which is the worst pet peeve of mine; ONLY yesterday, I was virtually (via Teamviewer) fixing a new LoB app made by 2 freelancers who came (apparently) highly recommended; it was made in Next 15 with React 18 and shadcn (that's not fully compatible yet... but that's normal in that ecosystem; nothing is). So I checked the Linkedin / github's of these freelancers and had a short call with them if they could help (no, they had no time; new clients!); they were Django/Bootstrap guys before, but that sells less well than Nextjs/shadcn/tailwind, so they switched recently. What a joke. Why is this not liable really... But again, we make very good money, so please carry on!
* Idiot developers like myself. Okay, I was a teenager back when I got infected by this idea, but it did persist for some time into my start of my career too - the idea that RAD tools are inferior, they are not "true programming", just some lazy no-code clicking to save monkeys from understanding the program they're building as a whole, etc.
I mean, sure, you could do a lot in RAD tools really quickly, and do it well - but that was cheating. Too good results for too small an effort. It wouldn't impress any of your IRC friends.
(Curiously, those few I know from my "generation" who wrote software for e.g. their parents' business, would happily use VBA or Delphi. Wonder why...)
This was all adjacent to and connected to other ideas that became influential with our cohort of developers, like "Windows suxx, Linux rulez", "plaintext is best", "CLI is best", "code generation is evil", etc. Those ideas are still deeply rooted in FLOSS, too.
VBA - was not C-like, you couldn't exactly put the whole project in SVN and diff nicely, it's tied to a specific platform (that sucked), a specific vendor (at a time when we all hated the evil M$ because it was the Right Thing to Do), and to a specific software suite (which was not vim). It's tricky for a technology to survive after a significant part of the fresh workforce tried to steer clear of it as a matter of principle.
My main issue with these is using the the cloud dev tools has a cost, normally usage-based - so if you use Firebase, if you're not careful, you can end up with a large bill.
There are 1.46 billion iphones, 3.3 billion Android phones and tablets, 1.5 billion Windows computers in the world. About 100 million people use MacOS.
I'd say with the (few 100 million) Chromebooks it's an equal number of Windows devices to the sum of the other ones you listed.
P.S. What happened to Android in your list? That is like leaving out the 500 pound gorilla :)
I don't think the platform mattered much, this happened before macOS became popular, and remember that at that time mac developers would still use Interface Builder and Objective-C. There was a certain level of pride in making Mac apps look very much like Mac apps. Very rarely did developers target both Windows and Mac.
My take is: A lot of developers didn't feel like cluing components together in Visual Basic 6 or later Visual Studio, dragging and dropping UI elements, was "real development". VB-developers where looked down on as second rate programmers. If you used VB.NET and WinForms/WebForms who where not a real developer. You had to use C# and XAML, which was absolutely terrible, but "real programming".
Same with Delphi, not something you built "real" applications in, no you use Java if you're a real developer.
Shit like that was all to common, and yet WinForms are still around and working, but XAML is dead (Edit: Apparently it's not dead).
>The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.
>Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.
A RAD tool like Visual Basic, Borland C++ Builder, Borland Delhi, QT Designer doesn't mean no code. Rapid application design helps the developer quickly build the UI using already made components and using some predefined behaviors like gluing a database table to an UI component. But the developer has still to provide the application logic and to write whatever else is not covered by the RAD tool. It helps you build faster, write less code, but it isn't no code.
Delphi is still around and filling a niche for boring business apps where usability, accessibility and quick UI development is more important than following design trends. You won't get any VC money for Windows XP styled apps, but if you make industrial hardware and need control and maintenance software Delphi is a reasonable and somewhat popular choice.
> I never fully understood why this programming paradigm died off.
First and foremost -- the world wide web.
Suddenly, we had a much more flexible way to deliver applications.
If I remember it correctly, Visual Basic couldn't write to STDOUT -- so it couldn't be used as a scripting language for the web.
Microsoft tried to push VBScript as an alternative, but it was linked to their expensive ecosystem, while LAMP (Linux Apache, MySQL Perl and PHP) was free.
Developing visually with VB(A) RAD-like dev tools to build websites without wallgardening and cleanly generated html, css, js, server side code & whatever, is a huge niche to be filled. Incredible that it doesn't exist yet.
Maybe I'll do it myself.
We've been using ToolJet (the open source version) at my company with good results. It is self hosted, open source and you can export created apps in some JSON format.
I've successfully setup a dev-stage-prod flow where we export from one env and import into another pretty seamlessly.
The coolest thing about that is that I was able to hire a very Jr. Frontend dev to immediately start working building internal dashboards.
I've used retool in another company but found problematic not having the source code for the lack of control.
>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.
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.
I believe some people used that monster version because VB had simple libraries that didn't allow many options. Anything more complex required you to go down the Win32 rabbit hole. And that was the main weakness of VB, it was such a simple language that you didn't have many options to do something more complex than going straight to Win32.
It is a very different thing to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, the language allows many ways to do so) than to claim "the language doesn't have many options, but allows you to interop with the entire win32 API if you need to". The first is a valid if only false complain; the second reads to me not as a complain, but as a feature.
>to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false,
That's not what I wrote. I said there's no _built-in_ way to check existence of the file. A reasonable interpretation of "built-in" is for an obvious named function such as "File.exists()" _without_ cobbling together extra workarounds and hacks -- whether those workarounds include re-purposing other VB built-in functions with On Error ... or using Win32 interop.
> in VB, [...] would at worse be comprised of a exception handler (on error ...)
That's an example of what I meant of not being built-in to VB. I should have been more clear. We were using different meanings of "builtin".
In any case, the following "pure" VB code to check for file existence is not found on Google or Bing search but I still have it from my 1995 archives and copied it here. It has many lines of code (instead of a simple "one-liner") because it tries to cover all the edge cases. And yet with all that defensive code, there's still a hidden timebomb of a bug in it. Can anyone spot it? The code is unmodified from Visual Basic Programmer's Journal. In contrast, the alternative using Win32 interop with OF_EXISTS doesn't have the bug.
Dim strTestFilename As String
strFilename = Trim(strFilename)
' To avoid problem with known bug, don't pass root directory to
' the Name function
Select Case Right$(strFilename, 1)
Case "\": strExistsFilename = "Root": Exit Function
Case "\.": strExistsFilename = "Root": Exit Function
Case "\..": strExistsFilename = "Root": Exit Function
End Select
On Local Error Resume Next ' Enable error trapping for Name function
Name strFilename As strFilename ' A trick to see if filename/path is good
' Now check the resulting err code of the Name function
Select Case Err
Case 5 ' Illegal function call
Case 53 ' File not found
Case 58 ' File exists (maybe)
strTestFilename = Dir$(strFilename)
If Len(strTestFilename) Then
strExistsFilename = "" ' It's a file
Exit Function
Else
strExistsFilename = "Dir" ' It's a directory
Exit Function
End If
Case 64 ' Bad filename
Case 68 ' Device unavailable
Case 71 ' Disk not ready
Case 75 ' Access denied
Case 76 ' Path not found
End Select
My point was that C# builtin File.Exists() is a lot simpler than that.
So, what is so wrong about simply calling FileLen() to check if the file exists, or if you also want to distinguish between Files/Directories using GetAttr to check the directory bit ? Why do you have to go all the way to this monster of code which even hardcodes lists of errors (why do you care which error it is?) ?
Your code sample renames the file, then globs anyway (when dir$ by itself can also be used to check existence). It looks too convoluted, and I cannot imagine why it needs to be so.
What is exactly the corner case that you want to avoid -- and if such case really exists, why are you so sure the File.Exists() implementation would not fall into the same pit trap, considering it also simply uses the metadata?
Disclaimer: I'm only familiar with VBA, not VB itself. But these file metadata functions definitely already exist in 95's VB5. (EDIT: Actually 97's. Maybe the problem is these functions did not exist in earlier VBs? But I would find it hard to imagine you could not check a file's size).
The sample code smells even in the trivial-case checks. E.g. Right$(_, 1) will only return a 1-char string at most, yet it tries to compare it with 2, 3 len strings. I didn't check any further than that.
To elaborate.. just what is wrong with simply doing the following?
Function FileExists(Filename) As Boolean
On Error Resume Next
FileExists = (GetAttr(Filename) And vbDirectory) = 0
End Function
It's not 2 lines, but it's 4, including function header. All functions used are available at least since 16-bit VB3. Is this what you call "a workaround and a hack?". It's practically the same thing .NET is doing for File.Exists() (or at least the current one -- dunno what .NET 1 was doing), so I cannot think of any gotchas that would affect this but not File.Exists.
Another way, use Dir by itself. This is even mentioned in the VB docs...
FileExists = Dir(Filename) <> ""
3 lines. It also ignores directories. Sure, this has problems with wildcards, but so does your example, and that's another oneliner to fix, using Replace$ (as wildcards are not legal characters in filenames in win32, either way). And if Dir("\") returns true for some reason, I guess that's a runtime bug, which is pretty valid criticism, even if a bit of a corner case (who really wants to check if "\" exists?). I would prefer the first version anyway.
I still stand by my original point that this is a very poor example, since there are a million ways check for a file's existence, many using only builtin functions of the language. You can certainly find nigh-overcomplicated ways to do so, apparently even on books, but ... why? Not a fan of cargo-culting like this; it tends to create Cherteston's fences.
Many languages also lack a direct "File_Exists" function (e.g. Lua comes to mind) since it's about the most trivial thing to implement (and a magnet for TOCTOU issues). Or even if they do come with such function, it does not distinguish directories from files (e.g. Tcl). I hardly think the lack of a "file_exists" function discriminates anything in language design, modern or otherwise.
GP complains that there is no direct function for "file exist". And technically there is not on Tcl either because file exists cmd will return true for directories. You can trivially build your proc that specifically checks for files (it will likely use isfile) but that is exactly the point of my comment. I have shown how do that for VB and it is not far from a one liner.
Presence/absence of a file exists function is a very poor example. If the language didn't allow you to check e.g. if a file was a directory or not, then GP might had have a point. But this is not the case.
There's nothing wrong with [file isfile $filename] either. As I'm saying there's a million of oneliners for it.
I am not sure if I'm getting my point clear. I'm presuming you are trying to defend that yes, you can check if a file exists in Tcl, even if there's no specific function for it, but that is, again, exactly my point. Like what you're doing, I've shown many ways to do it in VB.
I guess the fact that someone needs to nitpick me in exactly the same way I was nitpicking the GP is quite the proof that the analogy works perfectly...
But if you rely on these subtleties this is hardly a "basic feature" that the language is lacking. In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).
If you actually open a file, you update it's access time, and you interfere with the process that should actually open the file. Those both break perfectly simple business logic.
The documentation for OF_EXISTS literally says it will open then close it. I leave to your imagination whether this updates the (very poorly defined) access time or not, but for sure you "interfere" with other processes...
If you want to get the access time, why don't you just query the access time? Which is likely the only thing almost universally guaranteed not to change it...
And I'm sure VB6 has an API for that, considering that VBA had a global API for it (FileDateTime).
(Which is, btw, yet another way to one-line check if a file exists).
OF_EXISTS is just a side effect of some actual operation. It's some related info you you get along the way. You would not use that as the way to only check the file. Holy cow. Please do continue trying to spread the wisom.
I never said, either explicitly nor implicitly, that File.Exists() modifies access time.
There is nothing there in that comment nor it's parent.
OF_EXISTS is not a thing by itself. It does not "open a file and then close it" which is a ridiculous and incorrect thing you DID actually say. OF_EXISTS is just a bitmask flag that can be returned by several functions, including ones that open files.
You have said a continuos string of incorrect things and employed invalid logic this whole time, and this yet again fits.
correction: you said opens a file and closes it about OF_EXIST the bitmask flag to tell OpenFile() how you want to open it. Slightly less ridiculous, yet still not a thing that opens a file, OpenFile() opens the file.
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.
I misread the comment first, I missed the word "it".
I thought you were saying you could use a seperate lock to guard the time between exist() and open(), which is possible but silly.
Now I'm not sure what you meant. Is "it" exists() or open()? You can use open() as a lock for other things. It doesn't need any other locks itself. You can't use exists() as a lock.
Or, I guess you are saying one process can open the file and others can merely check exists()? Yes depending on what the purpose was, what you intend to do with the results of exists(), because it isn't true any more the instant after exists() returns, only while exists() is actually running.
That makes it sound useless and therefor what is the problem that VB6 didn't have it? That might very well be why it was omitted.
But you do need some form of stat(), a way to get info about files without affecting them in any way. A process needs to be able to watch a files access time to know if it's been accessed yet, or when last, without that very observation changing the access time or making the file appear open()ed to other processes that may care about that. Even being opened read-only andbnon-exclusive is still opened. Another process may need to know that it has eclusive access or else it can't do it's thing, so it will fail it's own open() exclusive.
Even if the other process retries and open succeeds a few cycles later, changing the access time breaks the process that's waiting for the file to be accessed by it's actual consumer so it can be automatically deleted for example, or simply logged the fact that the customer has downloaded the edi file, the remote client/browser has loaded the temp file, someone somewhere has accessed super secret file, etc.
(setting aside that these days at least on *ix you frequently disable atime updates in the filesystem altogether and just do not build anything on top of that any more for performance and flash write life reasons. But I have processes that use it only in tmpfs in ram even while it's off for the real filesystem.)
I used something like that 20 years ago, so I forgot the details. Perhaps I just tried to create the file without checking if it exist(?????). The code is long gone.
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")
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.
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.
I am calling inexperienced developers inexperienced.
Are you literally suggesting that there are no inexperienced developers?
I am also saying that this thread is interesting and that inexperienced developers don't see the problem.
"very likely opens the file anyway" is not an argument.
"code smell" and "very likely wrong" are not arguments.
The reasons you need to stat a file without opening it, or do any other low level operation, are open ended and infinite. It's backwards to try to think up some specific invalid contrived example use case, and then say how you didn't need to do that specific thing that specific way, and so therefor you never needed that facility.
These are all quite bad reasoning and "inexperienced developer smell".
If you are experienced and still reasoning like this, that's unfortunate.
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.
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.
PowerBuilder too. I worked for an S&P 500 corporation from 2000 to 2006 trying to replace several business critical PowerBuilder apps in Java using a bloated commercial framework called Windchill. The original apps were written by a handful of developers over the years. The new team was fifty developers that struggled to replicate the old app functionality. We did manage to reimplement a couple of the old apps but they took a lot longer than anticipated and were incredibly slow.
The corporation chose Java/Windchill for the rewrite instead of PowerBuilder because Java was trendy. Both the original and replacement apps were desktop applications. During development of the new apps, browser based applications became trendy and some of the developers really wanted to switch to browser-based. Fortunately, that shipped had sailed. Can you imagine writing business critical apps for the browser in 2002?!
Because for the most part, you don’t need desktop applications in 2024. They are harder to maintain when used across multiple computers and you can’t access them from anywhere like web apps.
And most companies that need to build the things you mentioned can use a SaaS.
Also, those “simple apps” end up being an unmaintainable mess after a couple of years. In 2024, to a first approximation, no company should be writing software that is not core to their business.
Most problems are not special snowflakes. Someone has already solved their problem and created a customizable SaaS around it.
Yes I’m old enough to have used VB6 professionally from 2001-2008 (when it was way past its prime). But my first programming was on an Apple //e in BASIC and assembly and programming professionally in C and C++ from 1996-2008
In some context, I think desktop apps are far better than the web, and it's now super simple to roll out desktop apps using tools like Intune.
However, I'm talking about general business apps here.
The likes of Zoho, Salesforce, and, to some extent, Dynamics are covering some of this space—but again, they're expensive.
The main point of my post was that if I were 18 today and starting my first job, it'd be much harder to acquire the skills needed to grow. With VB or Delphi and a book, you could become pretty productive within a year or so, and the cost of entry was very low. The skills you learned opened the door to a whole new world for little cost. Especially, as others have mentioned, finding "DVDs lying around" :) which, of course, doesn't work for web tools in 2024! I was lucky my company provided, but i know friends who learned from the other approach.
These web based NoCode companies should provide people starting out with free, fully functional accounts—but then restrict live users to about 5. Atlassian/JIRA was always good at this with their $10 entry point. While it's not a programming tool, this approach is why it's found everywhere. It allowed someone wanting to experiment and learn to pay just $10 for access to the complete platform.
You might say there is plenty of open source out there, and this is correct, but again, in companies, this is not always used. They want the known companies.
What the generation do have today which we never did is access to high quality training beyond books - and now AI! Wish I was 18 again!
How do I roll out that Windows software on Macs? On mobile? And all computer management software especially on Windows ends up being corporate installed malware.
Besides, if you think that installing desktop software is ever easy - especially if something goes wrong - take a look at what happened with CrowdStrike.
As far as learning how to code, everyone has a web browser and can download VSCode or even Visual Studio for free. All languages are free and you can download free versions of every popular database for hobby level work.
Heck these days you can stay in the free tier of AWS forever if you stay serverless.
And software developers aren’t expensive as is maintaining software?
I was hired as a lead developer back in 2016 by a then new director. He had four mid level developers working there. After he interviewed me, he asked two of the developers to interview me while he was in the room.
They said they wanted to do address validation and they were trying to think through all of the corner cases - this was a real world issue not a coding challenge.
They asked me did I have any suggestions. I said sure, there are third party CASS solutions that are USPS approved and they shouldn’t be building that in house.
I was initially hired to modernize their homegrown Electronic Medical Records system built on PowerBuilder in 1999 using Sql server 2001 (this was 2016). It had been maintained by two other “developers” who had been at the company for 10 and 20 years respectively. I walked him through my proposed strategy if I were hired.
It didn’t take long to realize that this company had no business writing software. They were a low margin company that sent nurses to homes of special needs kids and made most of their money from Medicaid reimbursements.
I started leading the effort to do data migrations and being part of negotiations with SaaS companies as the company I worked for started buying up other companies in their vertical.
The company ended up laying off the developers who interviewed me and turning the other two into report writers and doing data analytics.
A year and half later, I had a frank discussion with the director. I told him we both know you don’t need me. I found another job three weeks later. I literally “put myself out of a job”
> providing technical support to many developers when I wasn't one myself yet!
This reminds me of my days as a Lab Tutor at the programming lab at my college. I was only one or two semesters in helping people with Advanced Java homework while taking basic Java.
I think one aspect is that business requirements for many of these apps became more complex, which is why we now often use process management or case management tools instead of smaller local programs.
Not only business. I think it's better in 2024, but as someone who lived through the browser war years as a frontend developer.. We may shit on Windows a lot, but learning the windows bits you need to write software in VB were ridiculously less complex than writing a backend AND a frontend for a webapp circa 1999-2005. Just because of all the tiny undocumented differences to make stuff look ok-ish or even quite the same. VB's layouting stuff was very good in my memory.
Being 100% serious here: half the SaaS webapp products I've ever used, both personally and at work, would be better and much more ergonomic if implemented as an Excel sheet or an Excel plugin instead.
Visual basic was the best way to build business apps ever. We just got these features in visual studio. Some we may never get (drag and drop dbs, form builders, etc etc). The closest I have seen was Flash. But if you say Flash or visual basic you are downvoted. I will let people get back to their js frameworks.
You're completely right, however the market for business desktop apps is over; not just because of the web, which is still inferior to VB in many respects, but because companies restrictions of what can be installed in a corporate desktop. It is much easier to use a web service than having permission to install a desktop app in a corporate computer. The huge Windows vulnerabilities destroyed the desktop as a viable business software platform.
Small businesses don't want to pay for simple apps. They want to pay a percentage of their sales to a large middle man who takes care of sales. It's too much for them to pay a few thousand (or hundred) dollars for a bespoke solution, but they have no problem paying tens of thousands per year to a middle man.
Almost none of those reasons are managing what are generally trivial costs for a growing business.
Small businesses remain small because they: cant scale, have a small tam, require direct labor from the founder to get the job done, the market is fairly well established but the founder has some special skills which are difficult to impart, especially in the context of the business.
Market conditions, the ability to get capital, and a lot of luck have way more to do than is your SaaS bill a little too high, you can always just use some google sheets and google docs and get 80% of what you'd need in most SMB situations.
When you deal with enough small businesses, you'll find out that they usually pay a large percentage of their revenue to middle men in order to save a pittance of money or effort which would be required to get rid of the middle man. People don't act rationally. Those who do act rationally regarding their business, generally find ways to grow it beyond being a small business. Assuming they want to. Many are happy being small.
SaaS is not a middle man. They're usually a good solution for a small business.
Pretty much everything boils down to having capital. Tech startups work because they inject capital into an idea that can be developed using technology. If you don't have capital to hire talent and sustain losses during several years, you have little chance to create a growing business in the modern economy.
I like the idea and face the same challenge. I’ve just installed it and, from my first impressions, it seemed a bit basic. Here’s what I expected:
Hundreds of recipes that I could swipe left and right through, allowing me to build up a typical selection of what I would usually eat. Instead, I was presented with only three choices, none of which I would generally consider.
A simple way to send the code to my wife — via imessage, Telegram, etc. Instead, I had to tell her in person! :)
This presents the perfect opportunity to delve into shopping lists where the wife wants something healthy, and the I crave a burger. I can think of quite a few features you could add if the app develops further.
Also, like the comment below about having a stranger over for dinner (not for dating purposes), it could involve a couple or someone visiting a new country who would appreciate a local showing them around and perhaps covering the dinner cost. Once the app learns your food preferences and interests, that could be quite exciting! There might already be an app that does this; I’m not sure. Swiping left and right on both food likes / dislikes and also general interests.
CyberStrike offers a temporary solution for crashed systems
Cyberstike has given users a potential way to fix their systems.
Boot Windows into Safe Mode or the Windows Recovery Environment (you can do that by holding down the F8 key before the Windows logo flashes on screen)
Navigate to the C:WindowsSystem32driversCrowdstrike directory
Locate the file matching “C-00000291.sys” file, right click and rename it to “C-00000291.renamed”
Boot the host normally.
Yup. Well in our case (and we are thankfully not affected), they could call IT support. But then again, if IT support themselves cannot boot their PCs...
I feel old - remember having access to Delphi 1 alpha as we were one of the first third-party VCL components. I was moving from VB3 and Delphi felt like a major upgrade and super cool!
Honestly EU doesn't have to change a single thing. All compliance exists already.
The trick is to not track good children at all, only those bad ones. I'd you leverage sanction lists (that exist already) to track the bad children, you have all cases covered.
Any Santa related contractor (Santa helpers, elves, etc) have to check a sanction list to see if they can finalize a transaction with said child.
As for lists: when a child sends a request for particular gift, it starts a formal transaction. The other entity is legally allowed to process said child's data to provide the service they agreed upon.
Kids that have not sent a letter to Santa and are not mentioned in sanction lists, can still get gifts but Santa lacks profiling metadata and can only provide generic, unprofiled gifts. Which is good as already have sufficient amount of Bluetooth speakers and Paw Patrol toys.
Wait, how would tracking bad kids be less illegal? I think putting bad children on state sanctions list might very well be deserved for some of them, but a bit overkill... Imagine not doing your homework leading to being officially sanctioned by EU governments or the UN... though I'm sure that's a pretty convincing way to make someone do their homework.
I would not optimise for performance yo early. All the building blocks are here. Let's leave "scaling issues" to the Christmas OPS team! Some cloud provider must have a North Pole region, right?
reply