41–50 of 269 posts
Hilarious quote (notwithstanding the fact that bus drivers usually have to work shifts, also on weekends): > Almost all Visual Basic 6 programmers were content with what Visual Basic 6 did. They were happy to be bus drivers: to leave the office at 5 p.m. (or 4:30 p.m. on a really nice day) instead of working until midnight; to play with their families on weekends instead of trudging back to the office. They didn't la…
Earlier quoted context omitted.
:) we probably crossed paths, good times
Checking in. I learned OSCAR and YMSG before HTTP. I recently tried to find a modern vb6 type setup that wasn't DOM (electron style) based and works cross platform. Best I found was javafx and scene builder.
VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with. In VB you could slap together a CRUD app in days, with VBXs (later renamed OCXs). I worked for a company where a bunch of programmers turned up their nose at VB and insisted on using C++, and then they got canned when the VB prototype functioned perfectly…
So? Why HASN'T anyone built Visual Basic for the web?
An enormous thing that has changed since the 1990s and those halcyon days of Visual Basic is the central role of design. Back then, overall consistency was a pillar of desktop UI. If your app's buttons looked like Windows buttons and you could use Tab to move through input fields, that was usually good enough. VB provided that kind of usability out of the box. The PC platform was fairly homogenous: you could assume that your user has at least a 800*600 screen, so you'd just make your application window that size and the MVP can ship.
Today's UI designs must deal with an enormous variety of physical form factors and display resolutions. But even if your no-code tool is able to deal with this and provides a consistent UI that scales from phone to desktop, it's not nearly enough. Commercial visual branding has replaced consistency as the central pillar of UIs. Now your buttons must never look like default buttons, and your UI must use a custom font even though the OS standard font would be more readable. This is simply what customers believe they want.
Unfortunately the web is a very poor platform for expressing UI designs in a consistent way, so literally everyone has their own haphazard UI framework. Basic components like pop-up menu buttons are commonly written from scratch. Nobody can agree on how to style a button. Et cetera ad absurdum. Your no-code tool should somehow integrate into this customer-specific private universe. On top of this mess, your primary input is visual designers who draw static pictures of applications in Figma and expect those to be translated into code. Often these designs are entirely lacking in structural thinking. (These designers typically come from a graphic design background, so they are very interested in fonts and padding widths but have never read the Apple Human Interface Guidelines or any other UI fundamentals. Hence they're mostly concerned with making sure any prototype application looks exactly like their Figma document.)
In my experience, the only reasonable way out of this trap is to focus on applications that are not of interest to the designers, i.e. internal business tools. Retool seems to be very successful here. I also use Retool in my day job and appreciate its no-nonsense design.
Ryan and David and team, I am so happy to see this posted! I'm quoted a few places in it. Yes, the story about the origin of the phrase "fire an event" is true and correct. I could even tell you exactly where I was sitting and which way I was facing when that event fired. Some things stick in your mind, doobies or not. Also mentioned is the VBX. In some ways, this may have been the worst API I ever designed. It was s…
I feel like my path was so much better because I started from laying out a UI and then learning code as a way to make it do stuff instead of the "lets learn complicated goop with no clear purpose first".
To this day I'm amazed by how ok devs are with not being able to get instant satisfaction from achieving things that should be simple.
There's a generation of programmers that fell into software development through Visual Basic. Maybe you could say the same about the Apple II/Commodore/ Sinclair/ BBC Micro generation of computers that booted up to a BASIC prompt.
It was surprising to us (here at Retool) that visual programming has never taken off, despite countless attempts over the past few decades. (That's why we started Retool, after all.) But Visual Basic is probably the product that came closest, and that's why we wrote this homage to it. It, along with Filemaker, Hypercard, are products that we loved. And we always wished that they had flourished, since then we wouldn't…
I feel like the whole idea of visual programming comes from some fundamental idea that the hard part of programming is learning the syntax, which I just don't agree with at all.
Ryan and David and team, I am so happy to see this posted! I'm quoted a few places in it. Yes, the story about the origin of the phrase "fire an event" is true and correct. I could even tell you exactly where I was sitting and which way I was facing when that event fired. Some things stick in your mind, doobies or not. Also mentioned is the VBX. In some ways, this may have been the worst API I ever designed. It was s…
I'm just here pumping web api's for my corporate overlords. I feel so bored.
Hilarious quote (notwithstanding the fact that bus drivers usually have to work shifts, also on weekends): > Almost all Visual Basic 6 programmers were content with what Visual Basic 6 did. They were happy to be bus drivers: to leave the office at 5 p.m. (or 4:30 p.m. on a really nice day) instead of working until midnight; to play with their families on weekends instead of trudging back to the office. They didn't la…
For what it's worth, I am a bus driver these days; a real one, no metaphor involved. And I sufficently disliked and mistrusted Visual Basic that already in the mid nineties I instigated a complete ban on any vb**run.dll on all computers under my jurisdiction. Mainly a heuristic: VB applications tended overwhelmingly to not being worth the inevitable trouble. I have proudly carried this curmudgery into the present cen…
(Not clear if you moved away from it or not)