5 ms·

The BASIC cause of death is written that it was seen as a lesser, kids language. That sentiment may be true to some extent, but fails to mention all of the pro

The BASIC cause of death is written that it was seen as a lesser, kids language. That sentiment may be true to some extent, but fails to mention all of the problems of the BASIC language that made people look into alternatives, none of which were snobbiness. If that were a real reason, Python would have suffered a similar fate.

forinti 4y ago
BASIC was very practical for 8 bit machines. You didn't even need an editor, because you could just retype a line. It was also very straightforward for a complete novice (as most people were with those machines). In any another environment, it really doesn't make sense.
- alwillis 4y ago
  True. One feature that was missed about BASIC on those early computers: you’d turn on the Apple ][ and you were greeted by the BASIC prompt and you could just start typing your program. This was before floppy disks… you could load a program from cassette tape.
- timbit42 4y ago
  In Atari BASIC and Commodore BASIC, you didn't even need to retype a line. You could cursor up and edit it right on the screen. This saved a ton of typing.
analog31 4y ago
BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. The one-screen problem is how I explain to beginners the value of things like subroutines with named arguments, local variables, and the like. Languages that survive, have to work for the size of programs that people want or need to write.
- deleted 4y ago
  [deleted]
- zozbot234 4y ago
  > BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. Python has the same problem though, as do "scripting" languages in general. The limit may be some low amount of "screens" as opposed to a literal screenful of text, but either way it's quite impossible to program "in the large" with it. Even Go is hampered in this domain by its limited abstractions.
  - swayvil 4y ago
    That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and classes or whatever, is news to me. What are other methods for slaying this complexity? And what are the languages that use it?
    - pornel 4y ago
      I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity. e.g.: • Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't. • Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler. Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.
      - analog31 4y ago
        Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system. That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.
ghaff 4y ago
QBasic (actually QuickBASIC; QBasic being the IDE) fixed some of the more glaring deficiencies of the original BASIC and I think was pretty popular for quite some time. I tried it and didn't like it--as I recall, I found things like error handling awkward. But it was from Microsoft and stayed around for quite some time. Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.
- dragonwriter 4y ago
  > QBasic (actually QuickBASIC; QBasic being the IDE) QuickBasic and QBasic both included IDEs; QBasic was the later revision (1991, vs. QuickBasic in 1985). (Weirdly, perhaps, Microsoft released Visual Basic the same year as QuickBasic.)
layer8 4y ago
Visual Basic was very successful, until Microsoft turned it into a mere alternative syntax for C# [0]. There is a parallel universe in which classic Visual Basic would have continued to thrive as a win32 glue language. (It still does to a minor extent in the form of VBA.) [0] http://catb.org/jargon/html/V/Visual-Fred.html http://catb.org/jargon/html/V/Visual-Fred.html
- bsder 4y ago
  I agree. VB6 was actively executed by Microsoft. VB6 didn't have to die. I'm still surprised to this day that nobody stepped into that vacuum and created a VB6 clone. There should have been a ton of money for doing so--I wonder what prevented it. I still have clients who are struggling to upgrade millions of lines of VB6 code base into something more modern (generally Python). GUI construction sucks in every single language since VB6. The nice part is that they are unanimous in not choosing a Microsoft language ever again.
  - linknoid 4y ago
    I've done some porting of VB6 into C# with WinForms. It's actually a pretty direct mapping. I wrote a converter, and then spend a few minutes cleaning up the converted code per form. Took me a couple weeks to convert a 500KB program, which mostly involved going through and converting VB6-isms that failed to auto-convert into C#. I can't imagine trying to translate something like that into such a different language and UI environment as Python. Unfortunate that they'd reject such a thing just because C# came from Microsoft.
dragonwriter 4y ago
> The BASIC cause of death is written that it was seen as a lesser, kids language. Nah, its more that: (1) The standardized, broadly compatible subset was a mostly unstructured, imperative language with very limited features, only global variable scope, named custom functions limited to a single expression (and a syntax that sharply limits what can be in a single expression), variables limited to numbers and strings, that was very tightly adapted to systems without modern capability (“line numbers” seem baroque now, but it really was a great way to have a simple, line-oriented text environment that worked as both REPL and simple dev environment.) (2) While there were plenty of nonstandard versions with more modern features, they were mostly proprietary, often tied to very specific other pieces of software, and not particularly interoperable between them. (3) Plenty of more modern, just as easy to use for simple cases, languages became available that had broad cross-platform compatibility (sometimes, not always, with formal standardization) without the limitations of BASIC’s broadly-compatible subset. (4) Almost no computers came with “power on BASIC” anymore, so the unique role the ubiquitous use of BASIC in this way in the 8-bit home PC era gave it and which provided a support for its overall popularity went away.
- alwillis 4y ago
  > variables limited to numbers and strings Not true. When I learned Applesoft BASIC in 1978–79 on an Apple ][+, it had arrays.
  - dragonwriter 4y ago
    Correct, numbers, strings, and arrays of each of those would have been more accurate.
  - xxs 4y ago
    defined via 'dim'

forinti 4y ago

BASIC was very practical for 8 bit machines. You didn't even need an editor, because you could just retype a line. It was also very straightforward for a complete novice (as most people were with those machines). In any another environment, it really doesn't make sense.

alwillis 4y ago
True. One feature that was missed about BASIC on those early computers: you’d turn on the Apple ][ and you were greeted by the BASIC prompt and you could just start typing your program. This was before floppy disks… you could load a program from cassette tape.
timbit42 4y ago
In Atari BASIC and Commodore BASIC, you didn't even need to retype a line. You could cursor up and edit it right on the screen. This saved a ton of typing.

analog31 4y ago

BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. The one-screen problem is how I explain to beginners the value of things like subroutines with named arguments, local variables, and the like. Languages that survive, have to work for the size of programs that people want or need to write.

deleted 4y ago
[deleted]
zozbot234 4y ago
> BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. Python has the same problem though, as do "scripting" languages in general. The limit may be some low amount of "screens" as opposed to a literal screenful of text, but either way it's quite impossible to program "in the large" with it. Even Go is hampered in this domain by its limited abstractions.
- swayvil 4y ago
  That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and classes or whatever, is news to me. What are other methods for slaying this complexity? And what are the languages that use it?
  - pornel 4y ago
    I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity. e.g.: • Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't. • Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler. Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.
    - analog31 4y ago
      Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system. That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.

ghaff 4y ago

QBasic (actually QuickBASIC; QBasic being the IDE) fixed some of the more glaring deficiencies of the original BASIC and I think was pretty popular for quite some time. I tried it and didn't like it--as I recall, I found things like error handling awkward. But it was from Microsoft and stayed around for quite some time. Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.

dragonwriter 4y ago
> QBasic (actually QuickBASIC; QBasic being the IDE) QuickBasic and QBasic both included IDEs; QBasic was the later revision (1991, vs. QuickBasic in 1985). (Weirdly, perhaps, Microsoft released Visual Basic the same year as QuickBasic.)

layer8 4y ago

Visual Basic was very successful, until Microsoft turned it into a mere alternative syntax for C# [0]. There is a parallel universe in which classic Visual Basic would have continued to thrive as a win32 glue language. (It still does to a minor extent in the form of VBA.) [0] http://catb.org/jargon/html/V/Visual-Fred.html http://catb.org/jargon/html/V/Visual-Fred.html

bsder 4y ago
I agree. VB6 was actively executed by Microsoft. VB6 didn't have to die. I'm still surprised to this day that nobody stepped into that vacuum and created a VB6 clone. There should have been a ton of money for doing so--I wonder what prevented it. I still have clients who are struggling to upgrade millions of lines of VB6 code base into something more modern (generally Python). GUI construction sucks in every single language since VB6. The nice part is that they are unanimous in not choosing a Microsoft language ever again.
- linknoid 4y ago
  I've done some porting of VB6 into C# with WinForms. It's actually a pretty direct mapping. I wrote a converter, and then spend a few minutes cleaning up the converted code per form. Took me a couple weeks to convert a 500KB program, which mostly involved going through and converting VB6-isms that failed to auto-convert into C#. I can't imagine trying to translate something like that into such a different language and UI environment as Python. Unfortunate that they'd reject such a thing just because C# came from Microsoft.

dragonwriter 4y ago

> The BASIC cause of death is written that it was seen as a lesser, kids language. Nah, its more that: (1) The standardized, broadly compatible subset was a mostly unstructured, imperative language with very limited features, only global variable scope, named custom functions limited to a single expression (and a syntax that sharply limits what can be in a single expression), variables limited to numbers and strings, that was very tightly adapted to systems without modern capability (“line numbers” seem baroque now, but it really was a great way to have a simple, line-oriented text environment that worked as both REPL and simple dev environment.) (2) While there were plenty of nonstandard versions with more modern features, they were mostly proprietary, often tied to very specific other pieces of software, and not particularly interoperable between them. (3) Plenty of more modern, just as easy to use for simple cases, languages became available that had broad cross-platform compatibility (sometimes, not always, with formal standardization) without the limitations of BASIC’s broadly-compatible subset. (4) Almost no computers came with “power on BASIC” anymore, so the unique role the ubiquitous use of BASIC in this way in the 8-bit home PC era gave it and which provided a support for its overall popularity went away.

alwillis 4y ago
> variables limited to numbers and strings Not true. When I learned Applesoft BASIC in 1978–79 on an Apple ][+, it had arrays.
- dragonwriter 4y ago
  Correct, numbers, strings, and arrays of each of those would have been more accurate.
- xxs 4y ago
  defined via 'dim'