everything wrong with free software

 "obedience breeds foolishness"

### the-miseducation-of-coders---part-2-of-2 *originally posted:* jan 2022 from the quote in the previous article: > I can create some basic CLI program using some basic C syntax, but not some GUI program, where I have no idea what to do and what to use in part 2 the idea is discussing solutions. this calls for collaboration between people who have some idea what theyre doing and people who dont. the goal is to better understand the latter. as said in the previous article: > programming is very simply "telling the computer what to do", more specifically "writing instructions that tell the computer what to do". it never needed to be more complicated than that. computers are glorified calculators-- not only is everything they do numeric, they only have a few simple functions. everything on top of that is supposed to be a helpful abstraction. i was talking to someone today who is a fellow bsd user, but he probably uses bash as well-- im not judging, bash is a powerful and expressive environment. i have installed it before in bsd, i even have it compiled from source on another machine, i probably never use it anymore unless its to run someone elses bash script. whats wrong with bash? for years, i coddled and massaged every line of code i wrote for it trying to get it to do what i wanted-- there are various guides on this, but i consider bash tedious and stingy about input. this is not deliberate, but it is by design. most unix shells are more lightweight than bash. a lot of people imagine this is simply for the sake of being lightweight-- sometimes it is, but often it is a side effect of a good design. the trouble with bash is that in trying to have a scratch for every itch, it makes the environment more and more complex. other gnu utilities are surely to blame in part for this as well. i spent years learning to work with bash, but no matter how much i learned it just seemed like rules on top of rules on top of exceptions on top of gotchas. worse (and this is the part that actually pisses me off) i just assumed it was the best shell out there. everybody used it... i should have known better. it turns out, when i use pdksh (it comes with openbsd, ive used it more out of laziness and a hint of curiosity) its incredibly familiar. i think bash was inspired in part by ksh, but ksh is just a great deal simpler. because of this, things i expect to work (but dont in bash) actually do! there are not so many features, thus not so many gotchas, and the overall feeling is NOT that ksh is inadequate (im quite certain it is, for something) but that ksh is PREDICTABLE and relatively EASY. what a joy. and assuming bash was as good as it gets (even if im to blame-- though i dont think its ENTIRELY my fault really, it certainly is to some extent) caused me to spend all of that time poking about with code that was already written and seems like it should work, but its ONE MORE THING, ONE MORE THING, ONE MORE THING (to add, to fix). i dont miss it at all. theres a lesson here for languages like python, which keep adding ONE MORE THING, ONE MORE THING and the result is that your code is NEVER WRITTEN-- you have to keep redoing it, because python is not a stable or standard language. its not-- each company that poaches developers from it gets to fuck with it a little more, and the result is something (i love python-- the de facto stable, simple and thus for some reason "deprecated" version) I WANT NOTHING TO DO WITH. when did they pass a law against stable language interfaces? but again, this is meant to be about solutions. alright then, heres what ive got so far. we sort the solutions out into three categories: curation, forking and creation. there are advantages and caveats to each. ### curation curation is simply looking for better languages-- this is easy enough until you try to do it. if the goal is independence from microsoft, great-- most languages you can think of that arent developed on github, already have most 3rd party libraries there. if you want lua for example... go see where most 3rd party lua libraries are. now someone is thinking, but thats not fair to the developers, they dont control where 3rd party-- right, they dont. but what, they cant even say anything? python led a campaign against all python 2 users for years, you think lua developers cant say "please dont use github?" its because they dont care, or are afraid of microsoft, or... probably one of those two. please, prove me wrong. lua has its good points. the chief gnewsance favours haskell. i guess the idea (he can correct me) is that serious math people arent going to let ridiculous treadmill people mess with their nice reliable digital blackboard. i dont think this is silly, he has a point. i hope hes right. i would prefer a stripped down python. i even promote the idea of a stripped down fork of bash-- it doesnt have to be pdksh, but it should be less ridiculous like ksh is. the size of the necessary manual is a huge hint. while curation is clearly the simplest option of the three, ive tried to hunt down another good language for years. of course everybody has suggestions, but really curation probably wont get us very far without: ### forking a lightweight fork of bash could be a wonderful thing. sure, it would break a lot of scripts. im not saying that people shouldnt support the original bash-- in fact im against a fork of bash with the same name. a really great name for a lightweight fork of bash would be "bas", because its hindi for "enough, no more" and i think portuguese "basta" is similar. both these names have practical drawbacks, bas is close to "basic" (but maybe thats NOT a bad thing-- basic is what torvalds learned first) and basta is also the first five letters of... ill let the people who fork it worry about this. i would love a lightweight fork of python thats easier to maintain and only has some relatively basic features. if i did it, i would simply choose the features most likely to be needed for my own languages written on top of it. python has a lot of nice things about it, but it doesnt need so many of them. its a very large codebase and the labour to benefit ratio could be very small. pypy is a really good way to keep python 2 alive, i would say the best way. for some reason, its a bit tricky to compile for 32bit on openbsd. i dont know what thats about. pypy (both 2 and 3) ultimately depend on python 2 to compile from source, and hopefully someday pypy sorts that out. and underneath pypy is a simplified python i believe... this option is a lot more difficult than curation, but also opens a lot of possibilities. somewhere in between the two in difficulty level, with additional advantages, is creation. ### creation to some degree, you could just teach these languages differently. since i wasnt satisfied with that and id dabbled with toy languages before, i wanted to try to make a language that was simpler than python but ultimately like it underneath. this made it easier to teach python concepts without worrying about python syntax (or indentation, for those who hate it-- for me, python is the language that made me appreciate indentation). most (not all) languages are implemented on top of other languages. the machine has a number of operations for moving numeric data around and performing operations on that data-- the main thing people do with such an interface is create other interfaces on top of it. by "interface" i mean something that connects two things together. a computer language implementation connects an abstraction (the language) with some other thing (the cpu, another language, the operating system kernel) so computer languages and really all abstractions are an "interface". i wanted to experiment with ideas id had as a coder for many years, including ideas about what basic would be or could be like if it were "more basic". and logo was partly an inspiration for this. logo works really well for simple tasks-- when you get to more complex operations, logo starts getting a bit weird. some newer dialects clean this up a bit, the drag-and-drop versions really simplify (but the actual text under those drag-and-drop gui representations isnt as friendly to code in, so you have to use the gui if you want it to be very friendly) but i wanted to cross some of the advantages of logo with the functionality of basic. and i wanted the language to be really consistent, so there were fewer rules to explain. of course you want just the right amount of consistency-- too little and its like theres a different rule for every statement. imagine trying to speak where the first line was english, the second italian, the third was hindi and the fourth was finnish. it would be a lot to learn! on the other hand, consistency that is too rigid will only require a different "workaround" to make each line of code "fit", or, it will be incredibly tedious. this is why a balance between rigid simplicity and needless rules was sought. each language will strike its own balance. if we plan our features ahead, the language will probably be better designed. languages get crazy when people bolt things onto them without thinking about what consistency or purposes existing features had. of course this can happen anyway. i was already using other languages to teach the following simple concepts, and i centred my language design around them: * variables * input * output * basic math * loops * conditionals * functions a function lets you design your own user-defined commands for the language. these used to be called "subroutines" or just "routines", and some languages distinguish between subs (which don't directly return a value) and functions (which do). since every high-level command is basically a collection of other codes with a name for calling it, you can think of every command as a function. in object-oriented programming functions are referred to as "methods", and they are combined with data referred to as "attributes", and they get defined with supersyntax called classes, but to me this is still about functions and variables. the cpu has no concept of objects either-- but routines (the name, the concept) ultimately come from lower-level coding, and these are essentially what we now often refer to as functions. the design i decided on was based on showing a friend (who was math-phobic) various things you could do with coding. nested parentheses imply math, and english tends to go only one level into parentheses (unlike lisp, python or javascript) and i was trying to design a language for bash-like pipelines without parentheses (yes, i am aware of parenthetical constructs in shell code and i quite like them). people focus too much on parsing when they design a language. if you want to write a parser yourself, write it yourself. if you want to use a parser generator, use a parser generator. if you want to use an existing parser, use an existing parser. all of these are legitimate options. most programming languages (especially the most friendly and familiar ones) work something like this: ``` multiline command command parameters parameters command parameters command parameters parameters command parameters parameters command parameters end of multiline command ``` a multiline command is like a sandwich; it has a top piece, a bottom piece (de-indentation implies the bottom piece in python) and generally things in the middle. the things in the middle are typically lines of code you might see "outside" of a multiline command as well. to make a simple language, here is what you should do: 1. open two files 2. read a line of text from the first file 3. append a different line of text to the second file 4. close the files brian kernighan (the "k" in "awk") is the father of "hello world" programs. a "hello world" program is a simple (some people say "stupid") program that says "hello world". this is meant to demonstrate basic output commands and give a first taste (or comparison) of programming languages. ive taken this idea to introduce BEGINNER-LEVEL language design, and make it as simple as possible to start on a language. a "hello world" program is a nearly useless program that only says "hello world". a "hello world" programming language is a nearly useless programming language that only lets you write hello world programs. the purpose is similar: to introduce the basics as a minimum and give a taste of designing a language. 1. open two files 2. read a line of text from the first file 3. append a different line of text to the second file 4. close the files lets apply this to to our example. we know we want a command that says "hello world". you can call it hello, hw, helloworld, or if you want to make it really easy to write (arguably somewhat contrived and unsporting) quines, you could make your hello world command "hello world". now for fun, imagine a very stupid language where everything you put in the "source code" is interpreted (or compiled) into a program that simply puts it on the screen. you could call it "meow", as the concept of this "language" is ridiculously simple to cat. i like the "hw" command personally, because if we are going to make this ridiculous language it might as well save us some typing. now, will your language put one command per line? this is the easiest to parse if you are going for an easy-to-write first language. will you be able to make it put more than one command per line? will you use a command separator? a common command separator is a semicolon; you would use it like this: ``` hw; hw hw; hw; hw hw; ``` the third line has a trailing semicolon, showing where the end of the line is. javascript requires trailing semicolons to end the line; python doesnt. the above program would (presumably) print "hello world" on the screen 6 times. but lets make this easier: ``` hw hw hw hw hw ``` very simple, print "hello world" 5 times. it works like this: 1. open two files 2. read a line of text from the first file 3. each time the line consists of "hw", append a different line of text to the second file that performs the functionality of a "hello world" program 4. close the files you can write a program to do that. and then, you have a "hello world" programming language implementation. i had some idea what i wanted to accomplish, because i had practiced doing this sort of thing before. i would have features implemented (mostly) as functions at the top, then i would call those functions with whatever parameters were in the source file. doing it this wsy (where code is output to a second file) is called compiling. if we simply ran the code immediatly, it would be an interpreter. for some very simple tasks including our hello world example, an interpreter is easier to write. for implementing a language with more complex features, particularly multiline commands like loops and conditionals, you may find writing a compiler to be a wonderful shortcut. practicing writing programs will make you better at writing programs. practicing writing programming languages will make you better at writing programming languages AND (most likely) programs. i would implement just one command, just like the above example, then get it working exactly the way i wanted before moving onto the next one. i might find a bug later, but at least it works more or less as intended. the best way to test your language implementation is to write silly little programs for it. as you start to add useful features, some of your silly little programs will get a bit less silly. i stopped at 100 commands. if each command takes 2 to 3 days (including the time not actually spent working on it) to add, you can have 100 commands implemented in less than a year. and a simple language with 100 or fewer commands is a language that people can learn in its entirety, if they want to. when you can/know the entire language, (not that you have to) there is generally less confusion about how it works. when youve written programs in a language you designed yourself, there is little question if you understand how to program in it. if you think forking a language is easier than writing a simple one, i urge you to try forking an existing language. before i wrote my favourite language, i tried modifying (changing existing features of) qb64. its a huge program. each time you change something, it takes a long time to compile. of course the more people write simpler languages like this, the greater the odds that one will fit your needs, or be easier to fork. following this (arguably ridiculous, but tested) plan will at least produce simpler languages. maybe you can simplify an existing language more easily. good luck. => https://wrongwithfreesw.neocities.org