21–30 of 32 posts
Earlier quoted context omitted.
You’d have thought the author would have kept a lookup table of the full variable names. Maybe they did, but that was lost.
I searched but I couldn't find out who this author is/was. Lines like " The author of TASC was very proud of this optimization. " makes me think that Raymond Chen is the author, is this right?
Earlier quoted context omitted.
I searched but I couldn't find out who this author is/was. Lines like " The author of TASC was very proud of this optimization. " makes me think that Raymond Chen is the author, is this right?
Back of the manual states: Microsoft TASC was developed by James Peck and Michael T Howard
I’m confused about deleting comments and renaming variables unless TASC itself written in Applesoft. Which seems crazy. > As the author added features, he kept hitting the Apple ][‘s 48KB RAM limit There was a language card that could replace the upper 16KB of ROM with RAM, but of course, you’d still need to have the interpreter somewhere. I’ve never heard of TASC before, but Beagle Bros also had an AppleSoft compile…
> All three passes were written largely in Applesoft Wouldn't this explain it? But it seems odd that they wouldn't at least save a LUT relating the shortened and expanded variable name.
BASIC implementations based on Microsoft BASIC store tokenized program lines. A keyword takes 1 byte. Comments, variable names, spaces between tokens, etc take up memory on a character-by-character basis.
I didn't use Apple BASIC, but I spent too much time on various flavors of Commodore BASIC which shared this heritage. Changing a variable from "ACCUMULATOR" to "AC" to "A" saved memory and made the program run faster. The problem of not being able to make sense of your own program after was very real.
Earlier quoted context omitted.
> All three passes were written largely in Applesoft Wouldn't this explain it? But it seems odd that they wouldn't at least save a LUT relating the shortened and expanded variable name.
> But it seems odd that they wouldn't at least save a LUT relating the shortened and expanded variable name. BASIC implementations based on Microsoft BASIC store tokenized program lines. A keyword takes 1 byte. Comments, variable names, spaces between tokens, etc take up memory on a character-by-character basis. I didn't use Apple BASIC, but I spent too much time on various flavors of Commodore BASIC which shared thi…
On a side note, early Microsoft’s business strategy seems to be licensing half-baked software written by independent programmers and then making a product out of it.
The article doesn't ever explicitly say so, but Chen expects the reader to understand from his words that TASC was written in Applesoft BASIC ! Further, TASC's coverage of BASIC keywords is almost entirely complete, going by chapter 7 of the manual. Any given Applesoft program has a very high chance of successfully compiling out of the box, and the very few differences with the interpreted language can be easily work…
It's part of the manual quote at the top of the article, 2nd paragraph of the quote (5th of the article):
> All three passes were written largely in Applesoft, and TASC was used to compile itself.
On a side note, early Microsoft’s business strategy seems to be licensing half-baked software written by independent programmers and then making a product out of it.
[0] Microsoft's own source control product that it replaced was Microsoft Delta. Believe it or not, Source Safe was a major improvement over Delta.
Back in the early 2000s, I worked at EA on Madden Football. I was working on a project to replace the old system Madden used for the game's UI (HUD, menu screens, etc.) with a new one based on Flash. A very smart engineer out of EAC in Vancouver wrote a custom ActionScript bytecode VM that could run on consoles and I was integrating it into Madden's game engine.
I was a lowly tools and UI engineer. In EA's culture back then, that placed me near the bottom just above QA on the prestige totem pole. One of the lead engineers on Madden wanted to talk to me about how much memory the new UI system was using.
I explained that part of it was that we needed RAM for all the variable names. He looked at me like I was an absolute idiot and condescendingly explained that compilers for programming languages don't keep the name of the variable around. The name is just used to identify a storage location and you only need memory at runtime for the value. He may or may not have hinted that this was something I was expected to understand if I ever wanted to become a senior engineer like he was.
So I sat down at his computer and tapped out this bit of ActionScript and ran it in our VM:
var someVariable = "its value";
var some = "some";
var variable = "Variable";
trace(eval(some + variable)); // Prints "its value".
The look of confusion and anger on his face was priceless.
(You might rightly wonder why in the hell EA picked a dynamically-typed scripting language with eval() that required keeping variable names around in memory for consoles that were incredibly resource constrained. The answer was that they struggled to hire UI artists who were willing to use the previous weird proprietary tools. They figured if they moved to Flash, they could hire Flash artists. Also, it meant they didn't have to maintain a custom UI editing tool.)