3 ms·

Agreed. Skill comes with practice, but the on-ramp is steep today, and seemingly getting steeper. Even while todays tools can do so more, I remember my first 1

Agreed. Skill comes with practice, but the on-ramp is steep today, and seemingly getting steeper. Even while todays tools can do so more, I remember my first 16k microcomputer with nostalgia. It booted immediately and into a simple known state. If you got onto trouble you could switch it on and off again. It booted into a REPL, a ROM-based BASIC. The language was simple, immediate, and with accompanying manuals discoverable. It could immediately let you program things that seemed to matter to you; text, simple sounds and graphics where all easy. The first way to use it, and the first entry point it gave was programming it. You could load programs from disk, but it was obvious that they were things that could be made - and taken sometimes taken apart (although some where understandable, some weren't. And that was a prompt to learn more). The hardware was easy to get to, even if it wasn't easy to understand, some of it was visible (like the memory mapped display). I help juniors without a lot of technical background today and there seems to be books of lore to digest before getting to something tangible.

commandlinefan 5y ago
It makes me wonder if attempts to simplify programming have actually made it harder. I remember Visual Basic: you couldn't ask for simpler than that. Want a button? Drag a button onto your form. Want tabs? Drag tabs. Want a list that contained entries from a database? Drag the list and specify the database. VB made trivial projects trivially trivial. But whenever you tried to apply it to any real-world scenario, you'd get stuck trying to infer all of the "hidden state" that the too-simple interface was trying to shield you from. I had the misfortune of working with the original no-code too, Salesforce, for a couple of years - in spite of the name, it's not all that "sales" focused; it's actually more a "VB for web-based enterprise applications" with a sales instantiation implemented in it. It had the same problems as VB, too - it was too simple for any actual problems. Simplicity was obtained by hiding details... that turned out to be crucial for basic business functionality (and don't even think about performance).
- bsder 5y ago
  > Salesforce, for a couple of years - in spite of the name, it's not all that "sales" focused; it's actually more a "VB for web-based enterprise applications" with a sales instantiation implemented in it. You know, this is the first time anybody has ever been able to explain to me what Salesforce actually does.
- perl4ever 5y ago
  I wonder if you are confusing Visual Basic with something else. As far as I know, VBA, VBScript, and VB.Net are "regular" Turing complete programming languages that can access anything on a Windows machine and not some sort of visual programming as such. The VBA editor is not up to modern standards, but it's pretty nice from the perspective of someone who started out in the 1980s with various MS Basics. The various forms of the language are not simpler than old fashioned Basic, but have a fair amount added. What fits your description more, in my experience, is Microsoft Power Automate, which is a sort of low/no code environment that is only slightly better that Malbolge IMO. It makes it incredibly difficult bordering on impossible to reuse logic.
  - sokoloff 5y ago
    I’m more in agreement with GP. Legacy Visual Basic had a substantial use case of visual editing of forms and form elements with a programming language behind it so you could attach actions to events. What they said resonated with my unfortunate experience working in VB for around 6 months back in the mid to late 90s.
  - squeaky-clean 5y ago
    My first programming class at a school was Visual Basic (Maybe 5 or 6.0?) and it was definitely very drag and drop GUI based. Drag buttons and text fields onto a panel, click them and edit their Metadata in the sidebar, doubleclick them and Visual Studio would open a file with an auto generated OnClick() handler with an empty body and a bunch of comments surrounding it saying something along the lines of "do not edit anything before/after this line." You'd run it by clicking the big green arrow button and I got an A in that class without ever knowing how to actually build and share an executable. I made a blackjack game and tried sharing it with some friends but it only ever ran on my machine (because only I had Visual Studio installed). A better teacher would have helped too, haha. Nothing against him, from what I understand he was the business class teacher and taught 1 period of intro to programming because the school couldn't find a replacement for the previous years' teacher.
  - mftb 5y ago
    He's not confusing it with something else. He's describing ~VB4-6. https://en.wikipedia.org/wiki/Visual_Basic_(classic) https://en.wikipedia.org/wiki/Visual_Basic_(classic)
- philipswood 5y ago
  Just for the flavour of the experience I'm describing: "REPL": https://youtu.be/X-5gZwfFPVM https://youtu.be/X-5gZwfFPVM What it actually looked like: https://youtu.be/z_jWcgwgmwg https://youtu.be/z_jWcgwgmwg (Not my videos, just pulled of the internet)
- BearfootCoder 5y ago
  Having had a range of early programming experiences, including BASIC and assembler on a ZX Spectrum,Pascal on an ICL mini and PL/1 on an IBM Mainframe,nothing I had seen or worked with up until that point came close to Visual Basic for hitting that sweet spot between power and ease of use. I never got a chance to use Delphi in any serious way,so that might have been an alternative contender,but certainly VB was orders of magnitude easier than building Windows apps in C++ and Microsoft Foundation Classes, which was the other main alternative offering at the time VB3 appeared. Non-programmers could use it to put together something that looked reasonably good and would work reasonably well without having to fill up their heads with a hideous morass of technological complications,and if you did have past development experience then it took away immense amounts of the pain and frustration which had previously been an inherent part of programming for Windows. Having worked for two separate companies which managed to create serious long-lived applications and make quite satisfactory amounts of money using VB5 and 6, I'd also reject the idea that the language was inherently incapable of giving you the kind of control needed to do serious real-world work. The default solutions which the UI toolkit pointed you towards often ended up as dead ends (the data control bound to an ADO or RDO database was a particularly terrible way of managing business processes and yet it was the one which Microsoft seemed obsessed with pushing people towards) but the language offered plenty of ways to do things which weren't terrible if you took the time to work out how to do so. Yes, if you pushed things far enough the limitations of the environment's abstractions, the fundamental sloppiness of its language design,and the choices which it decided to make for you would start to really hurt in terms of performance or ongoing maintenance. And version control was a joke, and testing and release integration were worse,and DLL hell was something which bit you on an all-too-regular basis.But you could get a pretty long way before that hurt became acute,and in the meantime you could do much that was useful and productive with much less up-front effort than you'd need to do the same thing in any current .net language,or even in something as supposedly friendly and accessible as Python.
chrisco255 5y ago
As a kid the REPL was always intimidating to me. I never liked it and was always frustrated trying to get it to work whenever I was dropped into DOS. I loved GUIs and gravitated to them as a user. It wasn't until much later that I developed an appreciation for the terminal.

commandlinefan 5y ago

It makes me wonder if attempts to simplify programming have actually made it harder. I remember Visual Basic: you couldn't ask for simpler than that. Want a button? Drag a button onto your form. Want tabs? Drag tabs. Want a list that contained entries from a database? Drag the list and specify the database. VB made trivial projects trivially trivial. But whenever you tried to apply it to any real-world scenario, you'd get stuck trying to infer all of the "hidden state" that the too-simple interface was trying to shield you from. I had the misfortune of working with the original no-code too, Salesforce, for a couple of years - in spite of the name, it's not all that "sales" focused; it's actually more a "VB for web-based enterprise applications" with a sales instantiation implemented in it. It had the same problems as VB, too - it was too simple for any actual problems. Simplicity was obtained by hiding details... that turned out to be crucial for basic business functionality (and don't even think about performance).

bsder 5y ago
> Salesforce, for a couple of years - in spite of the name, it's not all that "sales" focused; it's actually more a "VB for web-based enterprise applications" with a sales instantiation implemented in it. You know, this is the first time anybody has ever been able to explain to me what Salesforce actually does.
perl4ever 5y ago
I wonder if you are confusing Visual Basic with something else. As far as I know, VBA, VBScript, and VB.Net are "regular" Turing complete programming languages that can access anything on a Windows machine and not some sort of visual programming as such. The VBA editor is not up to modern standards, but it's pretty nice from the perspective of someone who started out in the 1980s with various MS Basics. The various forms of the language are not simpler than old fashioned Basic, but have a fair amount added. What fits your description more, in my experience, is Microsoft Power Automate, which is a sort of low/no code environment that is only slightly better that Malbolge IMO. It makes it incredibly difficult bordering on impossible to reuse logic.
- sokoloff 5y ago
  I’m more in agreement with GP. Legacy Visual Basic had a substantial use case of visual editing of forms and form elements with a programming language behind it so you could attach actions to events. What they said resonated with my unfortunate experience working in VB for around 6 months back in the mid to late 90s.
- squeaky-clean 5y ago
  My first programming class at a school was Visual Basic (Maybe 5 or 6.0?) and it was definitely very drag and drop GUI based. Drag buttons and text fields onto a panel, click them and edit their Metadata in the sidebar, doubleclick them and Visual Studio would open a file with an auto generated OnClick() handler with an empty body and a bunch of comments surrounding it saying something along the lines of "do not edit anything before/after this line." You'd run it by clicking the big green arrow button and I got an A in that class without ever knowing how to actually build and share an executable. I made a blackjack game and tried sharing it with some friends but it only ever ran on my machine (because only I had Visual Studio installed). A better teacher would have helped too, haha. Nothing against him, from what I understand he was the business class teacher and taught 1 period of intro to programming because the school couldn't find a replacement for the previous years' teacher.
- mftb 5y ago
  He's not confusing it with something else. He's describing ~VB4-6. https://en.wikipedia.org/wiki/Visual_Basic_(classic) https://en.wikipedia.org/wiki/Visual_Basic_(classic)
philipswood 5y ago
Just for the flavour of the experience I'm describing: "REPL": https://youtu.be/X-5gZwfFPVM https://youtu.be/X-5gZwfFPVM What it actually looked like: https://youtu.be/z_jWcgwgmwg https://youtu.be/z_jWcgwgmwg (Not my videos, just pulled of the internet)
BearfootCoder 5y ago
Having had a range of early programming experiences, including BASIC and assembler on a ZX Spectrum,Pascal on an ICL mini and PL/1 on an IBM Mainframe,nothing I had seen or worked with up until that point came close to Visual Basic for hitting that sweet spot between power and ease of use. I never got a chance to use Delphi in any serious way,so that might have been an alternative contender,but certainly VB was orders of magnitude easier than building Windows apps in C++ and Microsoft Foundation Classes, which was the other main alternative offering at the time VB3 appeared. Non-programmers could use it to put together something that looked reasonably good and would work reasonably well without having to fill up their heads with a hideous morass of technological complications,and if you did have past development experience then it took away immense amounts of the pain and frustration which had previously been an inherent part of programming for Windows. Having worked for two separate companies which managed to create serious long-lived applications and make quite satisfactory amounts of money using VB5 and 6, I'd also reject the idea that the language was inherently incapable of giving you the kind of control needed to do serious real-world work. The default solutions which the UI toolkit pointed you towards often ended up as dead ends (the data control bound to an ADO or RDO database was a particularly terrible way of managing business processes and yet it was the one which Microsoft seemed obsessed with pushing people towards) but the language offered plenty of ways to do things which weren't terrible if you took the time to work out how to do so. Yes, if you pushed things far enough the limitations of the environment's abstractions, the fundamental sloppiness of its language design,and the choices which it decided to make for you would start to really hurt in terms of performance or ongoing maintenance. And version control was a joke, and testing and release integration were worse,and DLL hell was something which bit you on an all-too-regular basis.But you could get a pretty long way before that hurt became acute,and in the meantime you could do much that was useful and productive with much less up-front effort than you'd need to do the same thing in any current .net language,or even in something as supposedly friendly and accessible as Python.

chrisco255 5y ago

As a kid the REPL was always intimidating to me. I never liked it and was always frustrated trying to get it to work whenever I was dropped into DOS. I loved GUIs and gravitated to them as a user. It wasn't until much later that I developed an appreciation for the terminal.