fsr help

 all because the gemhost disallows requests from http proxies

### some-talk-about-syntax syntax is the rules that determine how a language works. on the one hand, people are hung up too much on syntax when designing a language, because they think they know what they want to do but the language more often than not comes together without them realising it. theres basically the syntax you think youre designing, until you see that your features have other plans. but mostly this is about syntax that already exists and is already designed, which we can use to talk about how you wish syntax worked for your own personal use. one of the unfortunate artifacts of c development, which is pointless to blame on ritchie because its so easily fixed that c is fine actually, is the idea that we should have a semicolon at the end of every line of code; c is a beast of a language (in terms of its awesome power and immense flexibility) and i wouldnt meddle with a single bit on its legendary api. but just the fact that its tendency for semicolons carried over into javascript is unfortunate, and you can totally blame javascript for it. python at least, knew better. i dont pretend to know whats best for compiled languages used to write "serious" programs and software. on a scripting level, i like to think javascript couldve avoided this and saved the world trillions of wasted moments. but maybe the little break in coding to debug something so completely unnecessary is welcome, who knows? python gets this right, because even though semicolons are quite useful for separating commands and probably terribly useful for parsing c and similar languages (which i do realise javascript is one, so maybe for some reason they didnt want to screw up the parser but i stand by what i said) but for separating lines, newlines are better. except, and maybe this is what you wanted to tell me, that newlines dont seem to matter to c whatsoever. and javascript copied this. so the semicolon is important, actually. i dont care, python shows how to do it right for scripting. everything ive said about dogma applies here, but it cant be helped if i happen to be right. which brings me back to the silly example from the previous chapter: ``` $ 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 ``` note the use of semicolons between commands, and also the lack of one at the end of each line. its never occured to me to see if a final semicolon (after "done") would trip up the shell, but contrary to expectations it didnt. as ive explained, bash taught me to expect not only the smallest error to trip it up but the smallest bit of perfectly reasonable code to make results unpredictable as well. and though you could learn a million ways to "do bash properly" and avoid every gotcha that was actually a feature, ksh saves you the trouble by not implementing all the gotchas, even as features. i realise thats because they werent invented yet, but its a strength- even a feature nonetheless. this is ksh used for the example anyway, but i didnt show this to point out the syntax of bash (thats only an aside) but to point out the complete lack of semicolons in our single-command hello world programming language. you can actually make points about syntax with just ONE command. as another aside, i used to think of syntax as just the punctuation and formatting between commands in a programming language. i still think this is a valid usage of the word. but now i think of it as all of the "grammar" of the language, in the broadest sense of the word- not in the formal language specification sense. but for the sake of writing a "programming language" in less than two minutes, the hello world example only accepts one command per line, separated by newlines. you could in some instances, decide to make a "real" (as in usable) programming language that takes this shortcut for parsing and ultimately for writing with. most people wouldnt prefer to, for parsing or for writing, but i think i knew at least one person who did it once. just to be clear, i mean that if you want to say "hello world" 5 times you have to do this: ``` hw hw hw hw hw ``` and that also shows why loops are great, because with a loop you can say something like this: ``` loop 5 times hw pool ``` then if you want to say hello world (or do something more useful) 50 times, you can just say: ``` loop 50 times hw pool ``` without all the copying and pasting. but not only this, because of variables you can now specify the number of repeats automatically: ``` gettext n "how many loops?" loop n times hw pool ``` and now its starting to act like a real programming language, even though we havent implemented it yet. as i said earlier, implementing simple commands is easier with an interpreter design like the hello world programming language, but to implement the loop command imagined in this new example its a lot easier to do by compiling (translating, sometimes called "transpiling" when its to another language but compiling usually is these days) and running it after the whole thing is translated. however, for purposes of talking about syntax we dont even need loops, we can stick to the single hw command. it would be potentially useful in a number of imaginary scenarios to be able to put more than one hw on a single line, like this: ``` hw ; hw ; hw ; hw ; hw ``` this has practically all the disadvantages of using hw five times on five rows, but you would likely find lots of times that you preferred to put more than one command on the same line of text while coding, which would become obvious even sooner if your language didnt allow it. besides, "one-liner" programs are fun and easier to copy and paste. the main disadvantage of them is theyre not really wonderful to edit or maintain. or sometimes read. and you might think (and i would agree, most of the time) that you might not even need semicolons at all to separate commands. certainly not with hw, you could just use spaces: ``` hw hw hw hw hw ``` but getting back to the first echo example, it presents some challenges and ambiguities: ``` $ echo echo echo echo echo echo echo $ echo ; echo ; echo ; echo $ ``` which could be solved with quotes: ``` echo "" echo "" echo "" echo "" ``` at least if ksh wanted to be (it doesnt) a shell that doesnt need semicolons between commands. the good news is, if youre designing a language YOU GET TO DECIDE what you really want to parse and what you really want to type and be required to type when youre coding with it. i think for a beginner language its REALLY NICE to not have to worry about delimiters between commands, and beginner-friendly and toy languages often dont have too many parameters (its surprisingly easy to stick to a limit of 1 or 2 nearly all of the time if you try) which makes its practical for a language partly inspired by say- logo, to avoid semicolons (or colons, or even pipe syntax which is awesome) altogether. or as i would do, make them optional: ``` p 5 string colour 10 print "hi!" print print ``` and what that would do is set the variable p to 5, convert p to a string, change the text colour to lime green (dos/ibm/qbasic colours) using ansi/vt100 commands, print p, set p to "hi!" then print it twice: ``` p 5 | set the variable p to 5 string | convert p to a string colour 10 | change the text colour to lime green print | print "5" in green "hi!" | set p to "hi!" print | print "hi!" in green print | print "hi!" in green ``` but if your language is designed this way, what you might do is make it so that your parser just ignores the semicolons (when theyre not in a quoted string) so you have the option of using them for visual clarity: ``` p 5 ; string ; colour 10 ; print "hi!" ; print ; print ``` and if youre the designer of python (OR abc, which python shamelessly steals the design of but thats fine actually, its even from the same place python was invented sort of) then you make the semicolons MANDATORY because EVERYONE should learn to use semicolons! but im mostly having fun, pythons not nearly as bad about mandatory things as java (object class hello world) or javascript(); or other languages i wont even name here. besides, if youre the designer of python youve already sold out to one of the most evil megacorporations in the history of the planet, and at least python 2 wont be getting any worse. but i want to be clear that i do think optional (or even sometimes, required) delimiters ARE a good thing. except sometimes when theyre not. also, i hinted at this earlier but the more optional components your language has, the trickier (or for all i know, the more impossible) it is to use a parser generator for it. if you think parser generators are scary, i do too. ive never learned bnf or ebnf but i figure if you do, then you have the upper hand since its easier to generate a recursive parser that handles things like function calls as PARAMETERS OF function calls, which MOST people will want their languages to do at some point. and maybe youre like "okay, but what the hell is that?" to which i say, "its okay though, because this generation handwrites parsers all the time like ebnf isnt COOL anymore" and if youre writing a toy language or your first language youre probably going to do that anyway, and if youre going "all out" and learning ebnf and using a parser generator youre probably either going to make a very tedious language (this isnt the parser generators fault) or youre going to burn out, but good luck. parser generators are GOOD because without them your language can have all kinds of pitfalls that would be an issue if you were making a very sophisticated and very flexible language. you could presumably paint yourself into some sort of corner very quickly. so theres no manifesto against parser generators here. its just you probably wont need one the first time you create a language unless your design is ambitious indeed. ive written a recursive parser by hand and it was a fun challenge, but if i was better at math (and That Sort Of Thing) then i would probably be able to brag "oh, recursive parsers are EASY" and im sure they are for a number of people. you dont HAVE TO write a recursive parser. the main reason you would want to again, is that for code like this: ``` print(float(5) + (a / 2.5)) ``` or indeed code with ANY SORT OF operator order, thats where recursion is a nice thing for a parser to be able to do. but you know... there is ANOTHER WAY to manage this that DOESNT require writing a recursive parser! you just FIND a parser (which is licensed for reuse, and of course follow the license for it) that works closely enough to what you want your parser to do and edit it. or, you find (even hire) some nice person to write a parser for you. you just have to be really specific about what you are trying to parse. like you would want to know every possible detail about that before you bother someone else with the task, unless youre made of money and can just keep someone working for you on something like that. im going to recommend something even more unorthodox and just tell you to avoid a complicated parser if you want. write a simple language thats simple to parse. because if you follow shriram krishnamurthis advice you can literally just make a NEW language LATER which is exactly the same except for the parsing structure and first class functions and all that good stuff. and youll have already done all the work of finding the features you want and having a coherent idea about the language you want to design. youll just literally bolt on a different parser later, and wont that be awesome? and maybe you are just getting into languages and dont know what they look like (or do, but havent noticed many patterns yet) so lets compare a few: basic, logo, javascript, python, html: basic is archaic (even the newer versions) but its friendly. variables often specify type with "sigils" like a string variable would be p$ but modern basic coders might "dimension" their variable types instead and avoid sigils. i think at least a few dialects have dynamic typing (python does) which makes this unnecessary. for example in javascript, it has weak (but dynamic) typing so depending how its used, adding 5 to 5 can give you 10 or 55. its true of practically any programming language that adding 5 to 5 can give you either 10 or 55, but strongly typed languages make it unlikely to do this accidentally, languages with weak typing make it a little more likely to do this accidentally, well-designed languages with dynamic typing (like python) make it "just right" unless youre SERIOUS or actually need code to work on things like satellites or military or medical equipment, and then hopefully YOURE serious and using something with military grade typing like ada. no, i mean this isnt a manifesto against strong typing either. i learned to code on strong typing and javascript typing is too weak for my preferences (i refuse to use typescript though) but i always use dynamic typing when i can get away with it. i mean ksh has weak typing and no one (i know) complains because they arent using it to write something very sophisticated. basic separates commands with colons, because thats how it worked in 1964: ``` p = 5 : print p : input n$ : print val(n$) ``` it uses command PAIRS like "for" and "next" instead of more javascript (or c)-style brackets: (ksh does too) ``` for p = 1 to 5 print p next ``` basic commands only use parentheses sometimes, for some commands. like print doesnt use them, val does. screen doesnt by default, but pset does. before talking about any more syntactic design choices, i want to point out that no one learns this stuff by memorising it, they memorise this stuff by USING it. if youre not using this, you dont have to worry about it. its just a comparison, a bit of a tour to give you a bit of a feel. it would be ridiculous to a have an exam on this UNLESS you were actually writing code with these languages. the for command in python (and not only python) "iterates" through a "set" of items, including each letter in a string. so in python its trivial to do this: ``` for each in "hello": print each ``` and the output of that code will look like this: ``` h e l l o ``` if youre using python 3, youll need to put "each" in parentheses because they changed the print statement. python 2 (with the older print command) is unmaintained and not the sort of thing youd want running on your server, but if you prefer python 2 (and probably not for the print command, which is trivial) just use pypy, because ITS NOT unmaintained and shills are bastards for acting like the option doesnt exist, lying by omission to coders who strongly prefer python 2. though in fairness, its very possible that youre using a bunch of libraries that now require python 3 anyway. but only because of shills and bastards who literally encouraged them to abandon support. as ive said elsewhere, if you hate python I Feel You. you might love python (so do i, sometimes) and we might get along fine, but as for the python community in general i have no love for them or their silly cult nonsense. i assume its mutual. because the for command in python values consistency and modularity over simplicity (its really not so bad, but its true nonetheless) in order to do the equivalent of "1 to 5" with python you do this: ``` >>> for p in range(5): print p ... 0 1 2 3 4 >>> for p in range(1, 5): print p ... 1 2 3 4 >>> for p in range(1, 5 + 1): print p ... 1 2 3 4 5 ``` lets talk for a moment about what the heck just happened. first off, dont worry about the angle brackets and elipses, theyre just what the REPL environment looks like. lets clean that up: ``` for p in range(5): print p 0 1 2 3 4 for p in range(1, 5): print p 1 2 3 4 for p in range(1, 5 + 1): print p 1 2 3 4 5 ``` now the fact that range() creates a 0-based index i can understand, and before i get too annoyed about this feature (which ive been familiar with since 2009, and honestly dont think about very much) i should relax and consider that javascripts for command is probably just as terrible (worse in fact) and gee heck, if its THAT BAD you can just do it with the while command which at least will do exactly what you expect it to: ``` p = 1 while 1: print p if p >= 5: break p += 1 1 2 3 4 5 ``` but if you actually hate python, i feel you. also did you notice the colon (not a semicolon!) before print p? python uses colons (not semicolons) to mark the beginning of an indentation. it uses indenting (not commands, not braces) to delineate things like loops and conditionals. i never indented code until i used python, which makes you do it. even if i shouldnt be grateful, i am, and i still indent code when its worth the trouble, because i actually like indented code now. some people are so keen on using braces that they use them for python code anyway, which python doesnt support. then they run it through a preprocessor (a very simple compiler, basically) so that the braces get turned into indentation. i wrote one of those, i never use it. im not sure the people i just mentioned actually exist- the ones who actually USE the braces-to-indentation preprocessor they wrote (those do exist) for actual python coding. i also wrote something that translates FOR and NEXT (and some conditionals, plus function definitions) to indentation, which makes indenting OPTIONAL in python (if youre content with using way fewer features, PLUS inline- indented python where you need it). THAT i actually USE. but im odd that way. it also takes care of the range nonsense i just showed you plus i wrote it in 2015, only 6 years after learning python. so range() really doesnt get on my nerves very often. i use it pretty sparingly. but range really ISNT that bad, in my opinion. if you get into the habit of saying "range(1, n + 1)" like the first example i showed that actually does what it was trying to do, that will solve nearly every instance of range() use (with 1-based indexing) that you need it to. and i stand by what i said about the comparison to javascripts for statement, which comes from c syntax. but also, i would have designed the for loop in python differently. lets take a break from that heavy stuff (im joking, python is still much friendlier than many things, until you go looking for ways it could have been easier) and look at logo. i havent used a REAL logo dialect in forever. logo is like latin, in that its both dead and ubiquitous. dating back to the 60s like basic does, logo was designed strictly to be to be educational. unfortunately its more serious features form a sort of mangled lisp dialect. this is not a jab at either lisp (lisp is hallowed) or logo (you dont need to know anything about lisp to appreciate OR USE logo) but its why ive never written anything (other than some fun graphics) in logo. i really do not want to. logos design was (only partly) a mistake. the only part of logo that people really use are the graphical parts, and this is what has inspired several generations of logo imitators and derivatives that ACTUALLY GET what logo is really about, without doing EXACTLY the same thing. as a language, logo is really a giant family like those ones you hear about in the west. but i find the syntax (the sheer simplicity of it) inspiring. it needs to be said, that trying to take a really complex language with loads of features and shoehorning it into the sort of minimalist approach that logo graphics code allows you to enjoy would probably produce a language that is tricky to use for very much. which is perhaps why logo itself failed at exactly this. instead, the positive side of logo is that if your language has a subset (macros, lets say) which is minimalist enough, you can take advantage of that minimalism and have it carry over into the syntax also. or in plain english, if you have about 100 commands or fewer there are all sorts of ways you can become joyously lazy about how it gets parsed. which is probably the only reason i tell people "want to learn to code? design a programming language!" i also think if everyone (including people who dont know how) designed a programming language, it would be of incredible use to computer teachers who wanted: 1. to actually UNDERSTAND coding themselves... (ahem) 2. to be able to actually TEACH coding to- anyone in other words i think the surest (and shortest) path to a computer literate society is not just that everyone learn the very basics of coding but that everyone design a little programming language. including (some) teachers who dont really understand what theyre teaching (and maybe even take that out on their students both emotionally AND academically) BUT COULD, if we made it easier to actually understand how it works. but logo! i mean, there all sorts of ways to do it and its probably the easiest language to make up your own syntax (or parser) for. i wrote one in bash... it was awful. but this still demonstrates my point. you wouldnt want to write a parser for ANYTHING ELSE in bash. okay, at least i wouldnt. qbasic did logo as just a little macro language that you shoved into a string and ran using the DRAW command. you could go further and sort of "compile" things to a string command (i suppose technically speaking, that was my FIRST compiler- though i didnt set out to write a compiler at that time. you could technically write one accidentally and maybe we should create a few more DRAW macro commands so that more people could accidentally write a compiler without even realising it) and if you want to do a 3d rotating object, the draw command (using "TA", which i think stands for "turn angle") is probably the easiest way to do it. SYNTAX! ``` r 10 d 10 l 10 u 10 ``` behold a square! that uses directions, but i think if we are being more traditional it would go something more like: ``` f 10 t 90 f 10 t 90 f 10 t 90 f 10 t 90 ``` which is just "forward 10 turn 90" typed out 4 times. im taking liberties and crossing more traditional logo with the qb macro version i used far more often (but not before using a more traditional dialect) but thats just it! logo is the language youre most likely to be able to figure out what it does JUST BY LOOKING AT IT, without even LEARNING the commands and we should THINK ABOUT THAT. but with all the versions that exist today, its very possible some people are thinking about that already. either way, ill just point that out. anyway, i say that loops are easier to implement if you compile first rather than write an interpreter. an exception to this is a loop that only works if its the first statement on the line and terminates after the same line, like this: ``` repeat 4 forward 10 turn 90 ``` you can have fun writing a little interpreter with a VERY basic loop command like THAT and i know this because i did it at least once. the way traditional basic interpreters work is to compile (aha) to "bytecode" (java does too) and then i guess its much easier to zip around the compiled version and deal with things like statically assigned labels or line counts and thats too much fun for me, but i think you could if you REALLY wanted to. im just going to say that for most people ITS A LOT EASIER to just compile (translate) to some other language. ive done it. theres youtube tutorials on it. i didnt use one. i had to wait for people to come along and prove i even knew what i was talking about, because i didnt invent it (not at all) but the way i did it was still less common than it is NOW. which is to say, it was harder to find someone who DEFINITELY knew what they were talking about and say "aha! see! i told you!" its been years since i really had to worry about that. im just going to tell you that its easier to compile MOST loops than implement them in an interpreter. you dont have to take my word for it. logo is the greatest programming language ever written. strictly speaking, i never use it. less strictly speaking, i might use it a lot. want to make a REALLY cool language? cross logo with basic. just try. id be interested in seeing what you come up with. you dont even have to implement it, just use your imagination and write it down somewhere. im not pretending this isnt a little self-serving. that doesnt have to be my motivation for saying it though. this is still my advice to the world about programming languages. finally, regarding logo, there is no law (and if there is, logo breaks it) that says you cant have punctuation in your logo syntax. some dialects of logo are designed to be PARTWAY closer to the syntax of their implementation language. there are python logos and theres a logo for openoffice (and libreoffice). logo is the EASIEST language to remove punctuation from. it makes it possible to see what a language WITHOUT semicolons or parentheses or colons or any of that would look like and still DO something. as such its a really fun thing to implement a really easy parser for, and THATS something to think about. the hello world programming language? whos to say it ISNT a dialect of logo? though i didnt intend it to be. but the more complex your feature set gets, the more times you might (even as a minimalist) decide you actually WANT some punctuation here and there, optional or otherwise. this isnt a manifesto against punctuation in syntax. i would like to see people be more conservative with it, but this is far from the only thing to consider when making a language simple to learn, simple to teach, or simple to parse. i admire compromises (design decisions, tradeoffs) in even shell code (especially ksh) and sometimes awk regarding these things. tcl takes this to the next level, its very interesting but its not ultimately my thing. i spent maybe a week getting into tcl, then went for a walk. it has fans and probably deserves them. its got more fans than anything i ever wrote. even so, i already said that "people are hung up too much on syntax when designing a language" and i didnt mean you NEVER SHOULD be, but people overdo it. there are no REAL laws about this. i want to encourage people to be more critical and less dogmatic about it. and have some fun. and maybe (this is the tricky bit) try to make programming more accessible to beginners again. i know, pythons probably easy enough for most people. but seriously, have another look at logo- and think about it. now javascript (ugh!) and html. theres nothing terrible you can say about javascript SYNTAX that you cant say about c. before you get the pitchforks and torches, i think c is a GOOD language and javascript... IS SOMETHING ELSE. actually thats probably not good enough, just saying "c is a good language" will probably piss off enough people. but im not going to throw something that important under the bus (like some kind of rust moonie would). okay, now thats everybody. no, seriously though. i didnt write this stuff to piss ANYBODY off. and certainly not to start any fights. im the most opinionated (and trollish) about crap ive been on the RECEIVING end of too many times, and i wasnt the one who picked those fights. im only saying this stuff to walk away from the fight A VERY SAFE DISTANCE (like, years) and then yell: ### OH YEAH????! so... there! except for the rust people. you need to fight them, right now, before things get worse. my good deed for the day. theres an old joke, oh right, its attributed to churchill (like so many things are to oscar wilde) that says democracy is the worst form of government except for all the others. theres a variant about capitalism which is of course, bunk. and you look that up and (i love this, so much) theres a headline on forbes- ON FORBES! which says "capitalism isnt just bad, its broken". its from 2019 and im sure they retracted it (or didnt mean it) but i agree. i would say "it isnt just broken, its bad." but it would be a lot of work to say something original about it. getting to the point though: ### javascript is the WORST possible language, except probably quite a few of them. to be fair, its pretty bad. even the author knows its pretty bad. one of the things i ADMIRE about javascript is that someone wrote a compiler, IN javascript, which compiles to javascript but GET THIS: it adds some features and fixes some things about javascript that suck- and javascript (or ecmascript, or whatever is most relevant here) actually USED THAT to make javascript suck a bit less. thats pretty cool. at least thats what i think they did. either way, the language was coffeescript and i prefer the syntax of coffeescript BY FAR but not enough to actually add another layer (which i dont maintain myself) to javascript, i dont use coffeescript. but i love the idea. also "javascript" is one of the most shameless bait-and-switch trademark SWINDLES in the history of trademarks and just a complete scam in that regard, except that i have no sympathy for java at all, but on principle shame on javascript and netscape, REALLY. im more offended by google creating something called gemini. its really low when big corporations do stuff like that. i dont think netscape was ever that big, at least not until they were technically part of aol. but you can tell how much i love talking about javascript syntax... i didnt even notice. whats to say? the syntax is basically c. oh, i know- javascript has the most inconsistent, random and haphazard (but mandatory!) capitalisation of any language i can think of. python is "bad" about this on rare occasions, javascript does this like its trolling. a big pet peeve of mine is when object-based langauges cant even tell you if(today(will(be(like(this))))); or().if().its().going().to().be().one().of().these().days(); choose a lane! but this is what i mean (or what i like to imagine krishnamurthi meant) about syntax being something that happens while your features are coming together on their own terms. i continue rewording it. hes said a number of things about this, none of which ive quoted properly, but the closest i can come to doing justice to it without actually going to youtube is when he said that its better to write a programming language deliberately, because otherwise you might write one accidentally. and i like to think that javascript is like that accidentally, because the alternative is that they did it on purpose. even so, the bigger your language gets, the more compromises youll find yourself making. thats mostly unavoidable. this also means that if you want to make a perfect language it will probably have to be small. hey, i dont make the rules. ``` also() {theres this;} ``` but you cant blame that on javascript. and i wont talk shit about c because very few languages are as important. which, im not saying its literally sacred. theres nothing wrong with making a language that improves on c. good luck. i dont even use it really, but telling everyone dont bother trying to improve on c is sort of like telling the wright brothers to stick to bicycles. so ill just say "good luck" instead. not to mention that c is probably chock full of lovecraftian nightmares, but thats to be expected when it holds the cosmos together. maybe i should go easier on x86 too but... haha, no. i dont think theres anything fundamentally hideous about c syntax. its fair to say its a little bit fugly and javascript probably makes it worse, but that brings me back to javascript is the worst possible language, except probably quite a few of them. what is best about javascript is the document object model (which i believe isnt actually javascript and yes, thats sort of the point) but also this is why people actually use javascript, no, whats node.js? it sounds awful. and that brings us to html. also known as css. it took me years to stop hating on css. i mean i never did make peace with it, just look at this AMAZING website design will you? even funnier if this is being read from gemini. but html, what i actually LIKE about html, is that even though they killed basic (and i dont want it, not the way it was and not the way they invariably take it when they try to revive it) is that- everybody learns html. its not even a programming language (javascript is, or close enough- no i mean really, how long until someone writes an operating system in javascript- even if it is impossible, that wont necessarily stop everybody) but html LOOKS like a programming language and ACTS like a programming language (sort of) and it certainly counts as coding, even though i do feel bad for people who learn html and they like- wish they could write something FUN. im not ever going to be a snob who knocks the fact that some hobbyist loves html so much that they learn more of it than i ever did or ever would. the love of coding is GOOD actually and html plays an important role. i dont really want to use html, its a love/hate thing, css made it SO MUCH worse (the love/hate thing, plus arguably the language itself) but i DO (sort of) get the appeal (of both html and even css, but its disgusting) and even if i dont want to use it, i will admit thats its interesting. html is based originally on sgml, and in its simplest form consists of "tags" with "attributes" and many of the tags (i would say most of the tags) have an "opening" and "closing" tag to mark the beginning and end of a portion of data (generally and originally but certainly not exclusively text) to say WHAT TO DO to that data: like you would have these brackets <> and one might say b for bold, and then you would close it by having a similar tag with /b in it. of course b stands for BANNED now, because youre supposed to use css for that. im being deliberately melodramatic about it, but i did hate it at least that much. it was SO simple. but i do get the idea of like, using span tags (or something better) and then just assigning some identifier of some kind so you can turn it on and off somewhere else. i mean, to be entirely fair to css (not the syntax, of html and js and css its the worst, but html syntax is actually pretty awful it was just Beautifully Simple to learn, which i admired) refusing to use css is a bit like having a place where EVERY LIGHT (including the ceiling ones) have the switch ON THE LIGHT itself, so we just CANT go to the door and turn it on and off THERE. ### and that, i suppose, justifies the existence of css. but certainly not the implementation. but then in the opening tag, after the name of the tag you would have "attributes" and these would follow the form of: name="attribute" name="attribute" and i DO think thats sort of elegant. but it turns out i was wrong, because i used to think "HEY! SOMEDAY IM GOING TO WRITE A LANGUAGE LIKE BASIC BUT ITLL HAVE HTML SYNTAX AND THEN YOU CAN BE LIKE GUESS WHAT! IMAGINE IF THAT HTML CODE ACTUALLY DID COOL STUFF AND HERES A PROGRAM IN IT"- and i could actually do that now. ive got everything i need to make that project pretty trivial. so why havent i unleashed THAT on the world? simple, the w3c PROVED ME WRONG and created xml, which IVE USED (for example, to configure my window manager- not anymore, i mean years ago) and ### OH NO, I AM DEFINITELY NOT GOING TO BE THE AUTHOR OF THAT PARTICULAR MONSTROSITY its not that i actually think it would be THAT bad. in practice. as an option. most likely it would be like python with braces- a fun and silly and yes, terrible idea, but like most niche languages, a non-threat in that- its a niche language. the REAL problems from programming languages are the ones that affect LOADS of people, not a handful of quirky hobbyists. its just- i used to edit the config of my window manager, in xml, and i dont want to put any coder through that who is trying to edit a basic-like program coded with freaking xml tags. thanks w3c, i hate it. xml was a mistake and its the only proof i have that we should never base another language (formatting, configuration or programming) on html (or xml). but i would have, until xml showed me what that would ACTUALLY be LIKE. in fairness, the worst thing about xml (like with appinventor) IS IN FACT not the syntax or the visual design, but the MILE LONG strings (or with appinventor, whatever the heck you would call the equivalent) of countless attributes. sometimes its NOT the syntax but the "information design" of the language that is the most horrible and bolted on, and horrible, aspect of the language. like a few angle brackets never hurt anyone. which is surprising, as they look like they would actually be quite painful. but A LOT of angle brackets probably means its html or xml, and thats more than enough of that, thank you. those are the chapters mostly about code, lets talk a bit about: => hardware.html hardware => 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. ```