Hacker News new | past | comments | ask | show | jobs | submit login
BANCStar: Financial Programming Language (esolangs.org)
65 points by _fnqu on Oct 3, 2021 | hide | past | favorite | 10 comments



BANCStar was never intended as a programming language, rather as a bytecode for a programming language VM. What happened though, is the vendor shipped the product to customers, some customers found the VM and started writing code for it directly, which the vendor never intended them to do. That is why it was such an awful programming language - it was never meant to be used as one. Imagine if people wrote JVM bytecode directly, without even using assembler mnemonics - that would be equivalent to BANCStar.

If the customers were more skilled, they would have written a disassembler/assembler to convert it to more reasonable syntax. This is the kind of thing that “too smart by half” people do - smart enough to rip off the covers and start tinkering with the internals, not smart enough to build some tools to make it easier for themselves. (It appears some of them eventually did do that, but others just stuck with writing the stuff by hand.)


The general progression is one writes:

1. machine code

2. assembler

3. macro assembler

4. high level language

At each stage, the effort required to produce the tool is justified by increasing usage of the machine.


I wonder how viable it was to write it by hand and still be able to use the editor to modify the simpler parts of the file.

"Not being able to mix and match" has always been where I've got stuck (from both directions before now) with other environments.


I think it was pretty valuable to people who did write bancstar by hand. The value came from either job security or consulting fees


Back in the day -- like way, way back before Adobe Illustrator -- the go-to vector illustration program for professional workflows was Zenographics Mirage. Mirage ran bit-identical across platforms including the VAX and PC -- because it was based on a virtual machine. Its constituent applications (called Chart, Ego, and Autumn) were implemented in terms of this machine. I found this out by examining some example scripts; beneath a "you are not required to understand this" type comment in one of the scripts were commands in Mirage's scripting language that consisted of the word "do" followed by some integers.

Using both these scripts and the included "Op Code Monitor", which flashed opcodes and their meanings as they were executed, I partially reverse engineered these bytecodes and used them to add new Mirage commands. One of them was a rectangle command for Ego that drew polylines instead of rectangle objects, so the rectangles could be rotated.




Looks a lot like the interpreter used by the Scott Adams (not Infocom) adventures.


This is a joke? How does one bright enough to grasp that thing can come to the conclusion that this is a good idea


You wouldn't have to be an exceptional programmer to figure this out. Your average user was much more accustomed to operating software like this at that time and may have been writing the software out of sheer necessity; most of them probably didn't understand what they were getting themselves into.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: