4 ms·

Funny, my current job involves a lot of coding in BASIC (BASIS and ProvideX commercial flavors) and I'm trying to wedge in some Racket where I can. I got my sta

Funny, my current job involves a lot of coding in BASIC (BASIS and ProvideX commercial flavors) and I'm trying to wedge in some Racket where I can. I got my start typing in listings from Rainbow magazine at age 10. (I never thought I'd be writing BASIC for a living though, life took a turn at 35)

byron_fast 7y ago
Pretty sure my life would have turned out differently if I'd seen some Lisp listings in Rainbow. I do recall William Barden Jr. making fun of parentheses once.
zozbot234 7y ago
> BASIS and ProvideX commercial flavors Looks like these are both "business" BASIC variants. Wiki has some information about ProvideX, nothing about BASIS (either the company or the BASIC product). What's the point of coding in these sorts of languages at the dawn of the 2020s? Do you still have a lot of legacy code around that can't be forward-ported for some reason? Do you have non-technical folks surveying the code, or even contributing to it?
- deleted 7y ago
  [deleted]
- velcrovan 7y ago
  You said it, legacy. Our ERP is essentially a folder of three hundred or so programs that all `RUN` each other and operate on flat files. The coding is mostly maintenance, but we sometimes need to add new programs/modules/menus due to changes in the business. We will be replacing it at some point, hard to say when. I won't miss trying to understand a 30-year old program with line numbers and two-letter variables, but I will bet money that whatever the new system is will be slower and more cumbersome for users.
  - zozbot234 7y ago
    Does 'RUN'ning a program keep global variables and the like around (like CHAIN)? If not, then those pieces of code are self-contained and could be replaced gradually by something saner.
    - reaperducer 7y ago
      Only if "sane" === zero cost. Outside of the SV bubble, it's not common for companies to migrate working systems to something new unless the benefits clearly outweigh the costs, and there's nothing better on which those those costs could be spent. There are a number of stories online, in HN, and in the business press where companies "upgraded" from legacy systems to something "saner" and it ended up costing more time, money, and customers than it was worth.
    - velcrovan 7y ago
      I wish! No, frequently programs will rely on variables defined in previously-run program. Believe me, I've had the same thought.
- bitwize 7y ago
  Business BASIC was all the rage in the 1970s, especially for small to medium-sized businesses, and for good reason. It provided business functions like forms and database access in a manner that was much, much easier to work with than the dominant business language of the time, COBOL. It also had sophisticated programming constructs. For example, while it didn't have structured exception handling like Java, it did have Go-style mandatory error handling; every command that performed I/O had to be passed, as required parameters, the line numbers of where to branch under various error conditions. Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration. The languages themselves also haven't remained stagnant; they have approximate feature parity with Visual Basic. Both are derived from the MAI Basic Four dialect that was popular in the 1970s. And yes, some large complicated business software, including the MAS 90 and MAS 200 accounting systems, was built using Basic Four. Porting such a complicated code base would be cost-prohibitive compared to porting the Basic Four dialect of Business BASIC to new environments and just running it as is -- so Business BASIC is COBOL-like in that regard also.
  - reaperducer 7y ago
    Business BASIC was all the rage in the 1970s, especially for small to medium-sized businesses The first piece of software I ever wrote and sold commercially was in Business BASIC. It was what we would call a CRM these days, though massively scaled down compared with what we have today. I did it for a limousine company. This was around 1982, IIRC.
  - velcrovan 7y ago
    > "Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration." I'm aware of this evolution. However, the software at my company was not maintained to keep pace with it. Instead it was endlessly customized within the constraints of the original interpreter. At this point, updating the software to use newer variants even by the same companies would take roughly the same effort as rewriting it in Python, for far less reward.
- JackRabbitSlim 7y ago
  Provided the interpreters(/compilers) are still being updated and maintained; What disadvantage would writing in BASIC have? ProvideX sounds like it's now Sage Group's ERP extension/plugin language. Like SAP's ABAP, Microsoft's "AL", etc.
  - zozbot234 7y ago
    > Provided the interpreters(/compilers) are still being updated and maintained That's a big question. And how much is that ongoing maintenance going to cost you, when you're critically reliant on it? It's just a single point of failure that will ultimately have to be addressed.
  - velcrovan 7y ago
    The flaws are in the language itself. Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. A modern language would have functions, objects and modules with descriptive names, scoping, and, you know, white space. OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. (I do have something jury-rigged in place for this but it's very ugly.) Additionally the data is stored in flat files. So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. (Often you are better off defining a new file and cross-referencing it with the others.) There is no relational aspect; what would be a two-line SQL query becomes 40-100 lines of BASIC code where you zip through the whole file record by record, often involving building an intermediate temporary sort file and then zipping through that. In essence: BASIC, especially this older flavor, is such a "simple" language that using it for anything non-trivial is little better than writing in assembler.
    - zozbot234 7y ago
      > OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. In some BASIC implementations, it was quite possible to 'LOAD' and 'SAVE' programs as plain ASCII text by adding the appropriate incantations somewhere, even though the default representation was tokenized. I'm not sure if the "Business" BASICs you're using can do this. > Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. Well, I'd say less "difficult", and more like "impossible absent a tedious reverse engineering effort". Figure out all the jump targets and all the subroutines, and document the globals that each relies on/modifies. Then you can treat your subroutines as something a bit closer to plain functions. (They'll still be non-reentrant however. Meaning that subroutines cannot recurse in general, not even indirectly.) > So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. The really old BASICs had their own notion of "record"-based file that was essentially the only kind of file that could be randomly accessed. "Sequential" files were entirely separate and only supported appending, absent language extensions.

byron_fast 7y ago

Pretty sure my life would have turned out differently if I'd seen some Lisp listings in Rainbow. I do recall William Barden Jr. making fun of parentheses once.

zozbot234 7y ago

> BASIS and ProvideX commercial flavors Looks like these are both "business" BASIC variants. Wiki has some information about ProvideX, nothing about BASIS (either the company or the BASIC product). What's the point of coding in these sorts of languages at the dawn of the 2020s? Do you still have a lot of legacy code around that can't be forward-ported for some reason? Do you have non-technical folks surveying the code, or even contributing to it?

deleted 7y ago
[deleted]
velcrovan 7y ago
You said it, legacy. Our ERP is essentially a folder of three hundred or so programs that all `RUN` each other and operate on flat files. The coding is mostly maintenance, but we sometimes need to add new programs/modules/menus due to changes in the business. We will be replacing it at some point, hard to say when. I won't miss trying to understand a 30-year old program with line numbers and two-letter variables, but I will bet money that whatever the new system is will be slower and more cumbersome for users.
- zozbot234 7y ago
  Does 'RUN'ning a program keep global variables and the like around (like CHAIN)? If not, then those pieces of code are self-contained and could be replaced gradually by something saner.
  - reaperducer 7y ago
    Only if "sane" === zero cost. Outside of the SV bubble, it's not common for companies to migrate working systems to something new unless the benefits clearly outweigh the costs, and there's nothing better on which those those costs could be spent. There are a number of stories online, in HN, and in the business press where companies "upgraded" from legacy systems to something "saner" and it ended up costing more time, money, and customers than it was worth.
  - velcrovan 7y ago
    I wish! No, frequently programs will rely on variables defined in previously-run program. Believe me, I've had the same thought.
bitwize 7y ago
Business BASIC was all the rage in the 1970s, especially for small to medium-sized businesses, and for good reason. It provided business functions like forms and database access in a manner that was much, much easier to work with than the dominant business language of the time, COBOL. It also had sophisticated programming constructs. For example, while it didn't have structured exception handling like Java, it did have Go-style mandatory error handling; every command that performed I/O had to be passed, as required parameters, the line numbers of where to branch under various error conditions. Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration. The languages themselves also haven't remained stagnant; they have approximate feature parity with Visual Basic. Both are derived from the MAI Basic Four dialect that was popular in the 1970s. And yes, some large complicated business software, including the MAS 90 and MAS 200 accounting systems, was built using Basic Four. Porting such a complicated code base would be cost-prohibitive compared to porting the Basic Four dialect of Business BASIC to new environments and just running it as is -- so Business BASIC is COBOL-like in that regard also.
- reaperducer 7y ago
  Business BASIC was all the rage in the 1970s, especially for small to medium-sized businesses The first piece of software I ever wrote and sold commercially was in Business BASIC. It was what we would call a CRM these days, though massively scaled down compared with what we have today. I did it for a limousine company. This was around 1982, IIRC.
- velcrovan 7y ago
  > "Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration." I'm aware of this evolution. However, the software at my company was not maintained to keep pace with it. Instead it was endlessly customized within the constraints of the original interpreter. At this point, updating the software to use newer variants even by the same companies would take roughly the same effort as rewriting it in Python, for far less reward.
JackRabbitSlim 7y ago
Provided the interpreters(/compilers) are still being updated and maintained; What disadvantage would writing in BASIC have? ProvideX sounds like it's now Sage Group's ERP extension/plugin language. Like SAP's ABAP, Microsoft's "AL", etc.
- zozbot234 7y ago
  > Provided the interpreters(/compilers) are still being updated and maintained That's a big question. And how much is that ongoing maintenance going to cost you, when you're critically reliant on it? It's just a single point of failure that will ultimately have to be addressed.
- velcrovan 7y ago
  The flaws are in the language itself. Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. A modern language would have functions, objects and modules with descriptive names, scoping, and, you know, white space. OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. (I do have something jury-rigged in place for this but it's very ugly.) Additionally the data is stored in flat files. So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. (Often you are better off defining a new file and cross-referencing it with the others.) There is no relational aspect; what would be a two-line SQL query becomes 40-100 lines of BASIC code where you zip through the whole file record by record, often involving building an intermediate temporary sort file and then zipping through that. In essence: BASIC, especially this older flavor, is such a "simple" language that using it for anything non-trivial is little better than writing in assembler.
  - zozbot234 7y ago
    > OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. In some BASIC implementations, it was quite possible to 'LOAD' and 'SAVE' programs as plain ASCII text by adding the appropriate incantations somewhere, even though the default representation was tokenized. I'm not sure if the "Business" BASICs you're using can do this. > Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. Well, I'd say less "difficult", and more like "impossible absent a tedious reverse engineering effort". Figure out all the jump targets and all the subroutines, and document the globals that each relies on/modifies. Then you can treat your subroutines as something a bit closer to plain functions. (They'll still be non-reentrant however. Meaning that subroutines cannot recurse in general, not even indirectly.) > So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. The really old BASICs had their own notion of "record"-based file that was essentially the only kind of file that could be randomly accessed. "Sequential" files were entirely separate and only supported appending, absent language extensions.