4 ms·

From the write-up: "BANCStar actually came with a "screen generator" that was supposed to be used to construct applications. But the 5.1c version of the genera

From the write-up: "BANCStar actually came with a "screen generator" that was supposed to be used to construct applications. But the 5.1c version of the generator was so limited that experienced programmers soon began to pry off the covers and modify directly the intermediate code that the run-time module actually executed." All of the numbers you're looking at are an object code for a VM that (apparently) allowed for user-defined screens in the BancStar product. Programmers found themselves reverse-engineering the meanings of the different numbers and began to build the text-format object-code by hand. This doesn't appear to have ever been intended to be a programming environment in this form.

shmageggy 13y ago
I feel like this is an important point. One could easily say "omg look at this horrible programming language I have to deal with -- 30001000: 55 30001001: 8b ec 30001003: 6a ff 30001005: 68 90 10 00 30 3000100a: 68 91 dc 4c 30" When it's just x86 and nobody is supposed to be using it directly. Of course, we have workable tools that sit on top of machine code so we don't have to, and apparently that wasn't the case for OP, but I think that's more of a statement about their inability to do the one thing makes progress in computing possible: create abstractions.
- jrochkind1 13y ago
  There was certainly a time that people wrote assembler, and even machine code, directly. People of course still do write assembler directly (but not as much as they used to!), but I don't think many have written machine code directly for a while. (Maybe for some specialized hardware?). But yeah, it's good to note that this underlying sort of vm code wasn't intended to be written by humans... but I wouldn't say the customers were wrong, exactly, to successfully use it to do high business value things with the product they were locked into, that they couldn't otherwise. It does make one think how happy the customers would have been if the vendor had provided an actually intended fleible scripting or 'macro' language, and then to think about the aspects of the market that still didn't lead to the vendor doing so.
dsed 13y ago
Yup, I believe there was both a text and Windows GUI for actually creating these programs, and it was indeed a VM. Source: I know someone personally who worked at NFCS on BancSTAR.
- jloughry 13y ago
  There was a text-based GUI but the application programmers never used it. It was too limited and wouldn't let them accomplish what they needed to do, at least through the GUI. That is an interesting point: the underlying VM mechanism was more capable than could be exploited through the GUI. The method of working with text files described here had been established prior to my arrival. I was given training on the GUI, and then advised not to use it.
  - mikeash 13y ago
    Why didn't anyone ever write a compiler for a saner (probably custom) language that targeted this VM for its output? Certainly that would be my first thought if the only choices were a GUI that was insufficiently capable or writing a bunch of comma-separated integers by hand. I assume either the transition was too gradual so nobody quite realized the absurdity to a sufficient degree, or everyone was too busy running around with hair on fire getting the day's tasks done to spend any time on long-term improvement, or management forbade it as a waste of time. I'm curious which it was, or if it was something else.
    - jloughry 13y ago
      You correctly identified the causes. Mostly, it was lack of time; keeping up with compliance changes is a full-time job at any bank, and there wasn't time for 'science projects'. What tools did get written were done to scratch a personal itch, and were done late at night and on weekends, outside of work hours. I think, as I said in an earlier comment, that there was a general lack of awareness amongst the programmers on the team that anything better was possible. Most were not computer science graduates. Professional programmers they were. But I'll bet money that most had never heard of trees. Management interest evolved over time from indifferent to actively hostile. The first generation LIST annotator improved productivity of the team and reduced errors probably at least fifty percent. Management took no notice at the time. Improvements to the tool, also developed out-of-hours, finally met with angry demands from management to stop and bury the results. Shortly afterwards the entire team was laid off.

shmageggy 13y ago

I feel like this is an important point. One could easily say "omg look at this horrible programming language I have to deal with -- 30001000: 55 30001001: 8b ec 30001003: 6a ff 30001005: 68 90 10 00 30 3000100a: 68 91 dc 4c 30" When it's just x86 and nobody is supposed to be using it directly. Of course, we have workable tools that sit on top of machine code so we don't have to, and apparently that wasn't the case for OP, but I think that's more of a statement about their inability to do the one thing makes progress in computing possible: create abstractions.

jrochkind1 13y ago
There was certainly a time that people wrote assembler, and even machine code, directly. People of course still do write assembler directly (but not as much as they used to!), but I don't think many have written machine code directly for a while. (Maybe for some specialized hardware?). But yeah, it's good to note that this underlying sort of vm code wasn't intended to be written by humans... but I wouldn't say the customers were wrong, exactly, to successfully use it to do high business value things with the product they were locked into, that they couldn't otherwise. It does make one think how happy the customers would have been if the vendor had provided an actually intended fleible scripting or 'macro' language, and then to think about the aspects of the market that still didn't lead to the vendor doing so.

dsed 13y ago

Yup, I believe there was both a text and Windows GUI for actually creating these programs, and it was indeed a VM. Source: I know someone personally who worked at NFCS on BancSTAR.

jloughry 13y ago
There was a text-based GUI but the application programmers never used it. It was too limited and wouldn't let them accomplish what they needed to do, at least through the GUI. That is an interesting point: the underlying VM mechanism was more capable than could be exploited through the GUI. The method of working with text files described here had been established prior to my arrival. I was given training on the GUI, and then advised not to use it.
- mikeash 13y ago
  Why didn't anyone ever write a compiler for a saner (probably custom) language that targeted this VM for its output? Certainly that would be my first thought if the only choices were a GUI that was insufficiently capable or writing a bunch of comma-separated integers by hand. I assume either the transition was too gradual so nobody quite realized the absurdity to a sufficient degree, or everyone was too busy running around with hair on fire getting the day's tasks done to spend any time on long-term improvement, or management forbade it as a waste of time. I'm curious which it was, or if it was something else.
  - jloughry 13y ago
    You correctly identified the causes. Mostly, it was lack of time; keeping up with compliance changes is a full-time job at any bank, and there wasn't time for 'science projects'. What tools did get written were done to scratch a personal itch, and were done late at night and on weekends, outside of work hours. I think, as I said in an earlier comment, that there was a general lack of awareness amongst the programmers on the team that anything better was possible. Most were not computer science graduates. Professional programmers they were. But I'll bet money that most had never heard of trees. Management interest evolved over time from indifferent to actively hostile. The first generation LIST annotator improved productivity of the team and reduced errors probably at least fifty percent. Management took no notice at the time. Improvements to the tool, also developed out-of-hours, finally met with angry demands from management to stop and bury the results. Shortly afterwards the entire team was laid off.