Unix Supported Paradigms
1. Event driven programming
2. Asynchronous programming
3. Data Flow – pipes
4. Parallel programming – fork, threads
5. Exceptions – signals
6. Modular programming – dlopen, plugins via dlls
7. Message Oriented Programming – sockets
1. Generic Programming – void* , preprocessor, varargs
2. Generative / Macro programming – preprocessor, lex-yacc, autogen, m4 which generate C code
3. Object oriented programming – custom vtables which favours composition over inheritance, also see this
4. Automata programming – gotos and arrays of labels
5. Stack programming – inline assembly
6. Higher order programming – function pointers and libcello
1. Actor model – zeromq
2. Literate programming – noweb
3. Logic programming / Databases
4. Garbage collection – use gcc builtin defer and external garbage collector
5. Array programming – C memory model, numpy
6. Audio programming – LV2, openal, puredata
7. Graphics programming – opengl
8. Differential programming
While C++, Java, Objective-C may claim to be descendants of C they really are more like PL/I and multics in spirit because of too much centralised planning and perfectionism; techniques which have persistently been shown to be disasters is software projects. Why C over C++, Java, Objective-C, C# ? Well …
1. The other communities have shown a profound lack of integrity and sleazy sales tactics (snake oil, fud, us vs them, eee) in their marketing. The adoption was forced on programmers in a top down way by non-programmers than by voluntary adoption by teams or natural market competition
2. Other languages are complex, difficult to explain to beginners
4. Other communities are obsessed with superficial and subjective arguments – code cleanliness as opposed to code reliability
5. Completely failed predictions … 0 modern operating systems are written in C++ and Java. Their success lies in using XML based guis which you can also do in C.
6. Better programmer happiness. More hobbyists pick C than any other language.
7. Code longevity, portability and less API/ABI breakage
8. Mono-thinking cultures are simplistic and inherently less creative, innovative while suffering from philosophical hammers
9. C and programming languages written in C dominate the web, embedded space and performance metrics while others are slow
10. A large open source codebase. Extremely rich tooling.
What can C programmers improve ?
1. Better naming conventions
2. Use garbage collection for non critical tasks
3. Use namespaces and nested functions
Much like how exercise easily fatigues the muscles, too much focus or flow drains the working memory. It is critical to take breaks every 10 minutes to regain balance otherwise while the first day might be productive the next few days will not be.
If a task is already done the estimate is 0!
My biggest regret in my programming career is not sticking to just C. I should have avoided OO / FP and all the framework snake oil that promise to cure everything. If you are a beginning programmer don’t waste time in any of that, develop knowledge about applications, databases, operating systems and games. C + Lua should be enough.
To date C is the only language with which you can have a complete stack
2. CLI / GUI Apps
4. Games (all 8bit, 16bit games)
5. Embedded controllers
without a single line of any other language.
Assembly too is wonderful!
Pointers > Lexical Scope
Function Pointers > Closures
Gotos > Exceptions
Tables > Objects
Co-routines > Monads
And because assembly instructions have a fixed format, it too is easy to parse – just like Lisp.
Black and White thinking
This style of thinking is nothing short of delusional. The open source community has too much of this and too little pragmatism. The split between free software and open source happened because of this reason and we have been paying for it, ever since. Much like the creative commons community, FOSS could have settled on multiple styles of licenses.
Not anticipating tivo, cloud
Unix is a timesharing system used in routers everywhere. Not anticipating patents, tivo and cloud from the day one is nothing short of embarrassing.
FOSS can not exist in isolation. Firefox and Ubuntu both failed in mobile. Corporations have successfully screwed over FOSS by locking them up in hardware; which is clearly anti competitive and monopolistic. Instead of having general hardware and consumer choice for software we have the opposite. The open source world has never really addressed this issue nor did it forge broader alliance with the open hardware and other open movements.
Open Source as a certification
Instead of having legal requirements for a business entity to call itself “open source” any corporation can pretend to be open source now, when they are in-fact mixed source. This is a drastic failure. No only could such a legal requirement be profitable for the certifying authority, it would also increase consumer visibility and trust. Now many consumers think they are buying open source when they are just using mixed source products.
Allowing the press to win the GNU / Linux naming battle which was a smear campaign in disguise. Also the usage of the word hacker in media. Being identified with communism and not with indie movement seen in music and elsewhere. The FSF has taken a half assed approach to this instead of using all legal measures to fight the press. No one really knows where FOSS stands. Every sane minded person should be vary of communism and M$ easily played on this fear in the 90s. On a side note, software is not a scarce commodity.
Appropriating funds and time for vanity projects and trifles like Firefox vs IceWeasel
The FSF has diverted more than enough funds on vanity projects like GNU Hurd. Early in the 1990s, Scheme was chosen as the language for scripting FSF projects on the insistence of Richard Stallman. Even now a number of major projects like GIMP are forced to use scheme. You can’t have compulsion and free in the same sentence. It is deeply hypocritical for FSF to dictate language choice just as it is immoral for a business entity to dictate how you should use your phone. The reasoning is here is nothing short of tyrannical. PHP has done more for free software than Lisp. Lisp is a slow, unfriendly language with a toxic community. The goal of FSF should be broader, safer choice in consumer software as opposed to any constraints and pointless forks. Customer support, user happiness, developer happiness, safety, transparency and ease of use are more important than crazy architectures and mere openness.
Why scheme ? Why not vala ?
Not building a business model around complements
This is also applicable for the *BSDs. Could FSF have funded itself by offering hosting solutions like digital ocean, selling books and hardware like Amazon, source management like gitlab and so on ? Instead of the D.I.Y attitude FOSS community relies on begging. Instead on yapping on and on about “free” and “open” software money could have the done all the talking. This is how profitable independent labels operate in the music world. Linux could have had an AppStore long ago with payment integrations, issue tracking and what not! Most open source projects don’t even collect email addresses of people who download and use their software. Only paid users getting priority ticket fixes could easily solve open source developer burnout.
Allowing redistribution and commercial use
The biggest achilles heel of open source is allowing redistribution of software as opposed to merely source available software available for private use. There are too many freeloaders on open source. It is also deeply unethical for someone else to make money out of your free contributions. Plenty of open source contributors are screwed over here when project owners get investor funding and contributors don’t see any of it. Github also did this cleverly by associating itself with words like open and community but never really had open source. This is nothing short of fraudulent. Open source developers need to understand contributor agreements before they commit a good chunk of time to work on open source. Money flows need to be transparent in open source.
1. Quit smoking
2. Cut down on coffee
3. Invested in back support, neck support and wrist support
4. Using vitamin D supplements, L-Theamine for anxiety and detox
5. Exercise for 10 minutes everyday
7. Quit twitter, netflix, HN, reddit, news after being addicted to them for 6 months
I guess I am finally old.
1. Nixos, Unikernels, Docker
2. CSS from scratch – tailwind, basscss, button shadows
3. vdom, svelte, pjax, websockets, caddy
4. ActorDB vs Rqlite vs Couchbase vs Custom Sqlite / JSON store
5. Wrote a blog engine in hylang, go, crystal, perl6
6. Moving away from google – WordPress, Goat Tracker, maddy mail server
7. Learnt a bit about Ethereum
8. Completed three projects
Also learnt more about mixing and remastered all my old songs.
1. Quit day dreaming
2. Better emotion management
3. Use RSS for everything
4. Reduce media consumption even more
More future learning
2. Better writing
Regrets – should have bought some Ethereum!
1. Programming deals with perfection more than any other discipline, what is not perfect does not work
2. We are not paid to use every feature of the language, we are paid to write programs that work well and are free of errors
3. You should not take unnecessary risks to write code
4. Responsibility hierarchy … user > developer > manager
5. Time taken to type the code is not a good way to estimate. Time taken to make code work right can be very long
(Bad) Arguments against good parts
1. It is not a matter of opinion if there is economic cost in terms of errors and delays
2. Reduce my keystrokes is not a good argument (programming is not typing)
3. It is an insult to suggest that I would ever make a mistake (thats silly)
4. There is a good reason those features were added (nope)
New Good parts in ES6
4. Let / Const
7. String literals
8. Regex literals
Bad Parts is ES6
1. Proxies ( I disagree)
2. Generators (I disagree)
6. arrow functions (returns undefined)
Good Parts Reconsidered
8. Don’t use new
9. Don’t use Object.create
10. Don’t use this
11. Don’t use null
12. Don’t use falsiness
13. No for
15. Prototypes are bad. Memory conservation is a bad idea. Compilers can’t optimise.
“It takes a new generation to use good ideas”
I disagree with this part of the talk. Goto is a great idea when used with dispatch tables and it is much better than exceptions. Objects are a horrible idea – extends is comefrom. Closures > Objects. You don’t need objects when you can roll your own vtable with maps. If you don’t know what a vtable is you should NEVER write classes.
1. class-free programming / functional inheritance with closures as an alternate to classes and prototypes.
2. Better number type – Dec64
1. Advices against types (you still have to test)
2. Actor based language could be the next
4. System testing over unit testing