-- Leo's gemini proxy
-- Connecting to gemini.exoticsilicon.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
Here at Exotic Silicon, we develop a lot of in-house software for internal use.
Writing your own software gives you complete control over it's capabilities and behaviour, but this ultimate flexibility starts to be eroded away as soon as you begin relying on third party libraries and other third-party software that you didn't write.
Unskilled programmers often rely heavily on other people's code, up to the point where their work is effectively just a thin layer of glue to, hopefully, hold together scraps of programming gleaned from random sources on the internet.
For a highly skilled programmer, analysing, understanding and debugging somebody else's code is usually more time consuming and tedious that simply coding your own implementation from the ground up.
> UNLIKE THIRD-PARTY SOFTWARE, YOU CAN BE FULLY AWARE OF THE QUALITY OF CODE THAT YOU WRITE YOURSELF.
Two excuses are often passed around to justify the lazy approach. Firstly that programmer time is valuable and that by extension, code re-use helps to conserve it, and secondly that even simple programming tasks often include edge-cases and unusual situations that have been covered in existing code, but might be missed by your new implementation.
This, honestly, is pure rubbish. Time is certainly valuable, but programmers who are skilled in the art work quickly. They have years or decades of experience working with boolean logic, have long memorised the syntax and functions for their chosen programming language, and know instinctively the best ways to approach novel problems because they can easily visualise them in terms of smaller building blocks. An hour spent writing code achieves more than an hour spent trying to understand somebody else's code, and unlike third-party software, you can be fully aware of the quality of code that you write yourself.
The concept that edge-cases might exist that you code needs to handle is effectively a concept invented by inexperienced programmers. To a skilled programmer, there are no edge cases, it's all just part of getting the algorithm correct. Edge cases are just a uncommonly occurring part of the core problem, not something special. A real programmer writing code from scratch should be able to look at a problem to be solved, be immediately aware of any details that might need special handling, and then, critically, fully understand the implications of this. If they are writing code for a particular use-case where the edge-case will never occur, code to handle it can be left out, and performance increased. Comments explaining this decision will be added, so that another programmer looking at the code, or maybe the same programmer in twenty years time, will know immediately why the decision was taken.
In this series, we'll look at how to take a concept, develop algorithms to compute it mathematically, and finally implement it in `C'.
If you want to improve your low-level core coding abilities, and see how to implement algorithms yourself rather than simply reaching out for somebody else's code, the material presented on this page should help you make a start.
This is not in any way a beginner's introduction to the `C' programming language. Knowledge of the fundamental syntax of `C' is assumed - our goal is to explain how to implement arbitrary algorithms from first principles.
The choice of `C' as a programming language is not arbitrary. `C' has a long history and is well established in the IT industry, despite attempts to displace it. Used correctly, the generated binary code is excellent in terms of performance and reliability.
The example code on these pages was developed and tested on OpenBSD, using the clang `C' compiler. It should be broadly portable to other systems. Where we do make use of a few optional OpenBSD specific features to demonstrate their use, this will be made clear.
In case anybody feels like contacting us and claiming that we're not really coding entirely from scratch because we're using the `C' standard library, and other system libraries, or that we should really be coding in assembler, we'll point out here that this is intended to be a guide with a practical end use. In fact some of the projects do include notes about using inline assembler within the `C' code. If there is sufficient interest in this series, and we receive positive feedback, we might consider producing further material covering even lower-level coding.
The source code presented on these pages is made available exclusively under the Exotic Silicon Academic Study Software License, (ESASSL). The full license text can be found on the ESASSL license page:
We encourage you to read it before using this material. The ESASSL is a permissive license, similar in spirit to the original BSD software license agreement, but not identical to it. Please note that this license applies only to the source code presented on these pages that reference it, and that all other content on the Exotic Silicon website is subject to our regular copyright policy.
A very simple project to introduce the series. We'll write a basic starfield simulation that outputs a sequence of ppm files, suitable to import into almost any animation or video editing program. Sounds trivial, maybe, but we'll do it in pure `C' with just the system standard libraries, and note some interesting tweaks that might be difficult to produce with an off-the-shelf piece of code.
Building on the graphics creation theme of the previous project, we'll create a faithful simulation of the tape loading sequence from a ZX Spectrum home computer. We'll then use a bit of artistic license to bring the effect into the 21st century. More complicated than it seems, since we have to take audio and video timings into account. See how to do all of this in about 500 lines of pure `C' code right here.
One last graphics project before we move on to something different. Video tape rewind effects often look fake and lacklustre, but we can create a realistic effect ourselves in a few hours, with just a few hundred lines of `C'. Find out how in this project!
Copyright 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023 Exotic Silicon. All rights reserved.
-- Response ended
-- Page fetched on Sat May 11 07:37:37 2024