fsr help

 all because the gemhost disallows requests from http proxies

### writing-your-own-programming-language so at this point i doubt theres anyone left reading this who doesnt think its some sort of enormous troll, because any time ive read something This Involved and also deadpan ive reached the same conclusion, and i make no denial about a peculiar sense of humour and for what its worth, my favourite comedian of all time is suzy izzard. i think the most natural thing that computers lend themselves to is the creation of programming languages. and someone might think thats self-serving, and it sort of is, because they were invented in the first place very much to do math. but i cant relate to that as much, so the very next thing they were used for is developing programming languages. and it goes all the way back to charles babbage, who invented a computer and ada lovelace, who figured out it could do so much more. and they were reincarnated (i mean, it stands to reason but maybe they werent) as the inventor of the mark i and grace hopper, who decided to write cobol. (actually b-0, but cobol was very much inspired by and similar to it). and as such, the programming loop was invented (by lovelace) before the computer was even built. developing a programming language IS a thankless task, because all that it accomplishes is everyone telling you that you did it wrong. this goes back to ada lovelace, and also to grace hopper, the latter of whom built a programming language compiler which DID use words instead of symbols, only to be told after the fact that it was impossible to do that and why would anyone even want to? and if you have the misfortune of knowing someone who studied computer science formally (particuarly someone from umass) then they already know every single way that a programming language has ever been or could ever be created, and you dont, so it just stands to reason that of course you did it wrong, because to do it right youd have to know how. and to know how, youd have to know every way it ever has or could possibly be done. all of which is of course, nonsense. what a programming language implementation actually does is accept code as input and produce code as output. thats the whole of the law, the rest is commentary. now, i fully expect someone to play diogenes, and produce some mockery of this claim and say "behold, a programming language!" but im way ahead of them. whatever people have come to believe is a requirement for a programming language, theyre not talking about definitions or implementations or specs but confusing those with EXPECTATIONS. and theyre the ones getting way ahead of themselves. there is one person whose opinions on programming language design i appreciate the most, partly because of the number of things we agree on and partly because he made so many youtube videos about it (or someone uploaded them to youtube) but shriram krishnamurthi has videos on programming language design that you Do Not Need but would benefit from anyway, if you want to know what programming language design "really" is. im going to try to make it MUCH easier than that. but hes a real computer scientist who makes it into a true art form. i used to hang out with a lot of people who would work on, or worship the authors of, various programming language implementations which focused on math or game production or emulating other languages. and in my opinion, no one knew when to quit or what they were doing until they got there. which is fine, in and of itself. the problem was when they burnt out or started thinking they had the gospel truth as a result. heres what i think of gospel truth among coders: ``` $ up="down" $ echo $up down $ ``` i mean, thats just semantics. its literally a joke, arguably less than a joke. but everyone who acts like theyre a scientist should have a degree of humility that outweighs any sort of dogma. otherwise its nothing more than scientism. this is no call to ignore the many lessons of many years of scientific progress. its just to say that newtonian physics still work in most contexts, which is why we still teach them. but im being overprotective, worrying too much about someone bothering you about trying something when all you really have to do is try. remember the hello world program? on the shell it looks like this: ``` echo hello world ``` echo is the command, the parameter is hello world. you can put it in quotes like this: ``` echo "hello world" ``` and this makes it clearer that its a single parameter, because the single parameter is in quotes. now ill say something that could easily be taken as a joke, but its a joke with a serious point to make: if a hello world program can be called a program, then a hello world Programming Language can be called a programming language. oh, no... but wait, thats not my "real" point and its not what i want you to take away from this. i promise, thats only the start of it. (i said i was way ahead of our computer scientist diogenes, and i certainly meant it). the reason im being this way is, so many people will "try to learn programming" and never realise theyre doing it, because their (imaginary) definition of programming is based on some unobtainable goal. this is pandemic. programming languages are so sophisticated that people will spend months or years learning them and not knowing if theyre "really programming" or not. this is not the fault of the programming languages. its what happens when you have people who think they know what computing is explain computing to people who will never know IF they know what computing is. these people havent SEEN a simple computer, or they did and missed the lesson of it: => https://en.wikipedia.org/wiki/File:Minivac_601.jpg# thats a programmable machine, its digital, its capable of doing math and displaying binary output. we can have LOADS more fun than that (ive implemented logo using only the bash shell- that was fun, but if i ever had to do it again i would prefer to use python- also i prefer using ksh to bash for most tasks) but the fun will be spoiled if our baseline for "real coding" is in the stratosphere. its a straw man that im demanding we stick with either the archaic or the mundane. what im suggesting is that we dont take the carrot we lead ourselves with and launch it into orbit, never to be recovered. keep it within reach, and the farther you get the farther out you can move the carrot. nor am i advocating mostly for PATIENCE. run wild, but dont (like every know-it-all coder ive ever spoken to) forget where you came from. if you wonder what a hello world programming language is, i can lead you step by step through it. but it isnt that tricky, its a program that accepts a command (i use the example of "hw" because its easier to type, but you can be silly and make the command helloworld and it still works) and then DOES SOMETHING. the point of a hello world program isnt what the code does, but the code itself. the point of a hello world programming language isnt what the programming language does, but the programming language itself. ``` $ date Mon Mar 23 22:10:33 UTC 2026 $ while [ 1 ] ; do read p ; if [ $p == "hw" ] ; then echo "hello world" ; done ksh: syntax error: `done' unexpected $ while [ 1 ] ; do read p ; if [ $p == "hw" ] ; then echo "hello world" ; fi ; done hi hey hw hello world hw hello world hw hello world ^C $ date Mon Mar 23 22:12:08 UTC 2026 $ ``` ### BEHOLD A PROGRAMMING LANGUAGE! now technically speaking, this is an interpreter (they seem easier to write and arguably are, for the simplest features at least) and doing this in THE SHELL truly IS perverse, but the shell is familiar to so many people already. it would be more of a bother to do this in javascript (ive also done it in javascript). and your first programming language almost certainly wont have enough features to be useful to you or anyone else, ONE of the first ones i made simply made it easier to produce (animated, colour) ascii art. it was written ("implemented") in basic but if i did it again i would much prefer to use python or MAYBE javascript (a language i really dont like very much, it has its uses) or even implement it using my own language as the implementation language. but the interpreter (this is pretty typical): 1. loops 2. accepts input 3. Does Things based on that input which, you might notice, describes nearly all interactive software. making it difficult to distinguish (by this definition) a programming language from say, a text editor or video game. they both fit this description. if you want a very useful language, its probably easier to make a compiler. a compiler simply takes code as input and returns code as output. so does an interpreter technically, its just that its running the code it returns and contines to run until the program or the user quits, while a compiler translates the entire program and TYPICALLY doesnt run it. ive made a "comterpreter" which compiles the entire input and then runs THAT, but to do this youre still basically writing a compiler. the fact that you call the code when its ALL compiled still makes it more of a compiler than an interpreter. my point is again that these are two sides of the same coin, and there are useful reasons to distinguish the two (you cant run interpreter code WITHOUT the interpreter, so anyone who wants to run it has to have a copy of the interpreter TOO- and compiled code is generally faster than interpreted code, but its relative) but when youre implementing loops and functions and structural features (even if you only want a couple of them) its typically easier to do that by Compiling output than Interpreting it. everything non-structural? avoiding even loops (which isnt that much fun, imo) then it IS easier to write an interpreter if youve never done it before. which is why the quick and silly "language" implemented in this chapter is in fact an interpreter. ### so what sort of features does a programming language actually need? ive done graphics, ive done utilities, i really dont have any love for game design because im really not into gaming, but the good news (if you want to make games) is that every "user friendly" language that tries to be "general purpose" the way basic was (the "a" in basic actually stood for "all-purpose", even though it had VERY few features compared to say, logo) ends up being taken in the direction of a language for making video games. which kind of sucks if you actually wanted it for making utilities. the reason i prefer ksh to bash is that i learned bash first, but it has too many features. with a programming language, the basic command set is known and assumed (because its included) and the boundaries of commands and parameters are typically well defined. this is NICE when you want to write a line of code and have predictable results. shells are different, their primary purpose is to run OTHER PROGRAMS and the command set is thus a list of all executable binaries IN THE PATH variable, it is neither included (except as a "distribution" but still not known to the shell authors Per Se) nor known, and each command may have entirely different syntax, let alone parameters. so in the shell you have echo, which kindly works like this: ``` command, parameter or parameters ``` and in python 2 you have print, which kindly works like this: ``` command, parameter or parameters ``` except when it doesnt, or in python 3 where its command(parameter or parameters) plus in each of these examples, you can have ZERO parameters if you just want to print a blank line. and in both python and the shell, if for example your first parameter uses 'single quotes' or "double quotes" then most of the text you would think of putting between those quotes would bring predictable results. the difference between ksh and bash is in the number of features, but the way those features are parsed are also features, and parsing lines of bash is not only WAY more involved for bash than ksh but SO IS anticipating what the shell WILL DO with what its parsing. which to put in plain english terms, is that with bash i spent more time getting it to do what i expected it to do, and stopping it from doing things i didnt want it to do, and with ksh that isnt even implemented so i dont have to worry about it. its more predictable. sure, bash has a couple features i miss with ksh, but it has a LOT MORE features im GLAD to be rid of. they actually get in the way. and you can avoid most of that by devoting yourself to the orthodoxy of bash shell writing, but id rather put that energy towards learning a language that is better organised. im not saying this as a snob, im saying this as a coward. i want ksh to do simple things that just arent simple with bash. and since ive actually designed a programming language or two, and i LOVE simple fun languages, ill tell you what i recommend implementing: 1. variables you can have a language with only constants, but it wont be much fun and it wont generally be as useful as a language with variables. of course with variables come state and all the advantages of pure functional programming are out the window. thats ok though, because imo pure functional programming isnt much fun either. this is just an opinion. 2. input this one you can fudge a bit. its amazing how many langauges only accept the most rudimentary (rudimentary as in getting back to the teletype!) input unless you call a library. theres actual logic to that i know, but the outcome is kind of sad. you can still fudge it a bit, because even the original basic implementation had DATA statements, which are (stretching the boundaries of truth a little bit, but nonetheless in some very practical terms) technically SORT OF input? i mean, if youre willing to put the "input" IN THE PROGRAM ITSELF you can skip implementing input routines. but for the record, if you at least make your language able to open files and get input from the keyboard (thus technically, also piped from other programs) this is way more fun. 3. output a program that doesnt have output of some kind is generally pretty useless. even the hello world programming language has output- its only command is an output command. while it appears that the hello world interpreter has an input command, it really just accepts input as a route to getting the "program" itself. you can write a program and "pipe" the "source" to the hello world programming language interpreter. hw is an output command- it outputs "hello world", and thats it. it is almost always more useful to have an output command that accepts at least one parameter, for the thing that you want to output. an exception is a cls command, which in bsd and similar operating systems tends to be called "clear" and is often called cls in basic (and dos). but different basic dialects call it different things. if you think its more useful to have a cls/clear command in your programming language than a "hw" command, i strongly agree. you can implement cls using those old screen emulator commands in python using stdout.write("\x1b[2J\x1b[1;1H") or by editing the "\x1b" part to produce ascii 27 (esc) in the implementation language of your choice, for example ksh and bash like octal 33 (which is 27 in decimal) like so: ``` echo "\\033[2J\\033[1;1H" ``` but if that doesnt work, try adding -e after "echo" (before the first quote and with a space between the two) because SOME implementations of the command wont run these codes without it. you can also use codes like this to change foreground and background colours, and you can use foreground and background colours to simulate graphics (even some really elaborate graphics if you set the font small enough) but these are just ideas. it would be silly to implement an entire programming language in this chapter when ive already done so as an entire programming language. 4. basic math you want to be able to add, subtract and multiply and divide at least. but especially to add and subtract. even if you hate math, if you can add and subract and output codes that move the cursor, you can do things like make something move around the screen. you can do basic (very basic) animation. you can also do that without math, if youre willing to do every frame by hand. but if you have basic math functions, then you can just add and subtract and avoid doing every frame by hand. you can also use basic math to do things like rotate colours. which again, you can do that by hand. sort of like you can type "hello world" by hand. but the more you do everything "by hand" on a computer and never let a program automate anything for you, the less its like programming and the more its like- just work, just extra work. practical programming (and more generally, practical computing) is a balance between how much you do "by hand" and how perfectly you implement the alternative to that. because implementing it a bit can save you loads of work, but implementing it perfectly takes more work than just doing it by hand. i think someone calls that the zen of python, but theyre giving python way too much credit. i think the zen of python was obsoleted when google (then microsoft) purchased the author. there is no "zen of capitalism", capitalism is about maximising resource extraction until people are dead. thats not zen, thats nihilism. 5. loops loops are the greatest thing in programming. a well designed loop can be used to "simulate" or "replace" a conditional, and a perfectly designed loop can only run a specified number of times, or until the break command is called. python for example, lets you do whatever you want. but to use it properly, you use "while" and make the conditional True or better yet 1, and use "break" to stop it. but the for command is also correct. what i said about gospel truth in coding earlier still applies here. the only reason im siding with correctness on this is to make potentially years of coding easier. you can also do loops a lot of other ways. 6. conditionals a conditional is a simplified/applied loop that runs for 0 or more iterations (but typically once or not at all, per call) and is probably easiest to understand or code in terms of if / then / else. as with loops, conditionals are formed typically by putting some code at the "top" of the conditional, some code below it, and then the code between those two lines runs if the condition of the conditional is either "true" or "non-zero". for example, a "word" (like "apple") or phrase that is 0 characters long is false, and a word with at least one character is true. this is a convention, not a law of physics. 7. functions functions are traditionally subroutines (if you like, just "routines") that return a value. in python and javascript, you can create functions that DONT return a value and arent called in a way that returns a value. meaning that in javascript and python, functions can also be subroutines along the traditional distinction, if there really even is one. functions and subs are basically the same thing now. but some languages distinguish between them. if youre happy with goto and conditionals, you can technically avoid functions and subs altogether. long programs will be incredibly messy, and probably very awful to maintain, but, this is overstated. its also mostly true, but very overstated. nonetheless, the best implementations of function definitions make it very, very easy to CREATE YOUR OWN COMMANDS using the language itself, and as such functions are very cool. theyre absolutely cooler than goto, they can be used to simulate loops and find the limitations of the call stack for fun, but secretly theyre all really jmp commands as far as the cpu is concerned. thats probably not true anymore, but its something to think about. in a way, every command in every language is LIKE a function call. if a program is a page or chapter, a function is like a paragraph and a library is like a reference book, maybe. but you CREATE a PROGRAMMING LANGUAGE by getting some functions together and THEN creating some parser to translate syntax. okay, you can do it either way. or a third way. but i agree with krishnamurthi that doing the parser first is a mistake. people put wayyy too much emphasis on the parser as the language. on the syntax as the language. if you do the features first like he suggests, you can simplify the syntax and parsing or even have more than one parser. more than one syntax. more than one target language for output, people actually do that sometimes. but most people (probably you too) are thinking, i cant write a parser. thats impossible! thats why i suggest making it as simple as possible. do it and be done. if you hated it, you learned something, you didnt try TOO hard, dont worry about it. if you loved it, you learned something, you still didnt try TOO hard, be happy. maybe do it again someday, even better, based on what you learned. i can easily point you to the simplest tutorials on youtube for creating your own language. i would definitely recommend python for this, better yet i would recommend pypy (and gladly irritate virtually every python user on earth) because i spent many years looking for a fun, easy language to replace basic with- thats why i learned javascript (its not as much fun, its not a great first language, the book "javascript for kids" is hilarious and gets returned so often- but its an okay second language if you already enjoy basic or python) and its why i moved to python. but python 3 gets too serious, it ditches simplicity a bit too often, and you CAN twist it back into a "simple language" but no one will ever use it as one, it will always be somewhere between basic and javascript (or even worse than javascript, the way the culture around it is) so imo, youre better off ignoring python culture (google-tainted culture, microsoft-tainted culture) and just making your own fun tools instead. ive even toyed with implementing things in lua, but luas error trapping commands (error trapping is a conditional that runs only when something Goes Wrong and its incredibly useful) are... awful. theyre so awful that for me, i just dont want to work with lua. but if they had error trapping closer to what python has, lua might be one of the best languages to implement something else with. its still more work than doing it with python, but the culture isnt as tainted. there are tradeoffs. overall, its a cool language. i already mentioned the only thing i truly hate about it. maybe someday theyll fix that one feature (i couldnt guess). if i was clever enough, i could fork (haha) or implement what i wanted on top of what theyve done. ive done a few clever things, but nothing like that. whats missing from every programming language development tutorial is how to know when its a programming language. its either missing entirely, or worse, sets you up to fail with ridiculous (and arbitrary) expectations. put your expectations at the other end of the spectrum- dont have expectations. just create a language with FIVE commands. if thats fun, do more, or do it better, or something. what most people will do though- which you really shouldnt do- is try so hard to make it So Good that you climb straight up into the clouds, stall and never recover. i dont know why people do that, but i watch them do it. its not just a lack of humility, its a sort of self-punishment. its comparable to other things that are similar where its a lot harder to avoid trying too hard and setting yourself up for disappointment- but with designing a programming language, it REALLY SHOULD be easier to avoid. each command should do one, at most two things. generally one, one-ish. people add way too many parameters and its not fun to use commands like that when you dont have to. with a shell command, you can string all sorts of nonsense about formatting and filenames and options because thats an entire application, youre using command options (which are basically parameters) to provide All Of The Input for that program to do what it does. its normal for an entire application (which we might call a shell command, because it is) to have several items of input. a programming language command doesnt need SO MANY options. not usually. NOT for a simple language. not when its for fun. people STOP having fun because they stop TRYING to have fun, they try to be serious until its not fun anymore, and then the next week or next month theyre like "this isnt working, i dont want to do this, im abandoning the project". dont get me wrong, its ok to abandon projects. i do that too when its gotten to be too much work and no fun, and whatever reason i was doing it just doesnt apply now. but you dont (ever) have to make a programming language that way. one of the best reasons to abandon a project is you end up creating something you like more that accomplishes similar goals. ive done that, too. it was still fun to try other ways, it boosts my confidence when i find a way that i like more than what i did previously, but i learned that by Trying Things and not taking it too seriously or trying Too hard. i kept it simple and fun, and the tutorials will not tell you how to do that. they generally wont even warn you against it. because if you let fun be just ONE of your guides and dont stray too far from that inclination, if when youre tired and in danger of burning out you RELAX and take it easy or choose a gentler path for a while, youll have more fun that way. youll keep learning, or keep exploring, or just- you know, enjoy yourself. which, i mean, sometimes its frustrating to get stuck on a problem. sometimes its incredible to find your way past that, and a challenge is ok. what causes burnout is challenges that are too steep and too many. and when people get a little knowledge, they tend to jump onto enormous inclines, like climbing a hill and then saying "ill tackle everest now! its just a bigger version of this!" im not going to tell you not to tackle everest. im just saying, if you want to get there and survive, you should keep practicing on stuff in between. do more hills. do slightly bigger hills. or just go for a nice walk if thats what you prefer, i dont know why so many people wouldnt do that. the fact that mount everest exists doesnt make a nice walk any less nice or less worthwhile. its pretty obvious when you think about it, with but with computers, most people seem to forget this. it ought to be common sense. people get into computers and forget that it can be extremely satisfying to just put one foot in front of the other. then again, it probably is an education problem. we dont usually teach people to put one foot in front of the other. we tell them to run, and act like the world is at stake if they take a day off. you get to choose which inclinations serve as your guides on this journey. i mean, you may have to learn to go easier on yourself. that may not be one of your strong suits, just like i continue to suck at math. so if you find its truly impossible to let yourself enjoy learning as an inclination, then youre off the hook. but i encourage you to at least try to think about it another way. a hello world programming language is a completely useless programming language. but it still teaches something i hope people will learn. and you can probably do better, and thats good, and you should try that. and you can absolutely adapt the youtube tutorials to give you some hows and whys and whats in that direction. if that leaves you wanting more, you can check out the brown university courses (these are real course lectures, the brown university ones) as well. but most youtube language development tutorials are aimed at hobbyists or toy languages, and the university courses will take you on an actual mountain. ive created a useful language, maybe two, but ive never been on that mountain. its not an ambition of mine to create something "real professional", just something Useful and Fun. and absolutely useful. but it was no mountain, it was just a nice big hike in the woods- not my first, ive done smaller hikes before and im advocating something that worked. so i do feel like it would be more fair to you to touch on syntax just a little bit, so its not as foreign or arbitrary, and then maybe what, some general stuff about hardware? but this chapter has rambled enough i think: => some-talk-about-syntax.html some-talk-about-syntax => https://fsrhelp.envs.net/ (back to the main page) => https://portal.mozz.us/gemini/fsrhelp.envs.net/ (it wouldve been cooler to do it this way instead) license: 0-clause bsd ``` # 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025, 2026 # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ```