380 karma · joined November 21, 2016
There are shelves full of different varieties of chocolate bars, and each of those wouldn't be there if people weren't buying them. Yet if you look at how many people are in the store at any given time, and how many of those people are buying chocolate bars and extrapolate then it _feels_ as if it shouldn't be worth anyone's while to carry so much stock.
I remember watching it and ended up in awe of how something that we take for granted took a journey of several thousand years to be get invented.
While I'm thinking about it, his recent video about the development of blue LEDs [2] is very interesting as well if you haven't seen it.
[1] https://youtu.be/RQYuyHNLPTQ [2] https://youtu.be/AF8d72mA41M
I started with a notes.txt file for the system I maintain. I found myself gradually adopting Markdown syntax because I need bulleted lists and headings to separate different sections. I also needed hyperlinks to documentation or StackOverflow answers.
So one day I just added the Markdeep tags to the bottom of the file and renamed it to notes.md.html
I still keep it open in a text editor for day to day use, but it looks really nice when you open it in a browser.
The more I use it, the more I love it: Everything I need is readily available through the package manager. There are no interruptions and no nag screens. There is an unobtrusive icon at the top telling me that an update is available, but I get to install it on my schedule.
I've resisted the urge to sign into Google for Gmail and YouTube and my other social media accounts and I'm actually amazed at how little I miss it (though I still use those services from my phone, but I've been using them less)
Also, it being a home-built computer it comes with a couple of quirks: Its fan is extremely noisy, when you scroll the mouse wheel you hear a crackling noise on the speakers and the keyboard is very uncomfortable, but all of these gives it a "personality" that only endears it to me.
I remember that the DrDobbs' Journal once featured a stereogram program that ran excruciatingly slow. I wonder how Bullfrog got it performant on the hardware of the era
I was fascinated by the Amiga when I was young, but they weren't widely available in my country.
Lately I've had an itch to do some retro programming work and was looking at the Amiga specifically. I tried Aztec C natively in UAE and VBCC as a cross-compiler, and got some command-line and hello world Intuition programs working.
But going beyond that has proven somewhat difficult. Documentation seems to be scattered all over the internet. I found a bunch of books on archive.org, but they mostly seem to focus on Intuition applications or beginner programmers.
The technical wizardry that went into making it fast went way beyond the raycasting graphics engine. There were all kinds of tricks used to speed up the engine:
One that comes to mind was compiled scalers - they basically JIT-compiled the code of an unrolled loop that drew each scaled vertical strip of a wall. That was why the game had to do some slow processing when you resized the view area.
Another one was that if two vertical strips were the same, they could be sent to the VGA card at the same time.
There were also a couple of tricks to speed up drawing sprites if they contained lots of transparent pixels.
I vaguely also recall seeing the "fizzlefade" effect discussed here a while back: When you die the screen is faded to red through a linear feedback shift register that touches each pixel on the screen once in a seemingly random way.
Kids today have it so easy with their Unitys and their Unreals... :P
The Black Book on Doom is also worth a read for comparison - it is quite remarkable how much the PC improved when 16-bit real mode was replaced by 32-bit protected mode and how different the design of Doom was from Wolf3D.
How on earth would you create syntax highlighters and other tools for this language?
The problem with this argument is that if it wasn't for Bitcoin, those renewable energy sources could've been used for other activities.
Back in 2016 I briefly worked at a old, large corporation that was still using CVS.
During that time management decided that company policy was now to be hip with the younger generation. One very senior manager actually used the expression "we must strive to be the Uber of [our industry]"
This also led to a mandate that we should switch to Git because it was new and shiny.
You can just imagine the how steep the learning curve was for all the old hands, especially as some of them joined the company in the previous century as COBOL programmers.
We were also pulled in to team building sessions where we were encouraged to "think outside of the box" and be "innovative". During one of those sessions I suggested that "you know, we should just use SVN instead" and was promptly shot down.
I've been reading a lot about retro gaming lately, so I'm just thinking in the context of bedroom coders of the 80's that learned to program in BASIC, then moved on to assembly to get more performance, and then later moved on to C and C++ as projects became more complicated. They all seem to have turned out okay.
I suppose what I'm getting at is you can write bad code in any language.
I always assumed it was just a thing among my parent's friend group
I recall Tcl being described as a Lisp without the parenthesis many years ago, which I still think is somewhat apt.
Antirez' article "Tcl the Misunderstood" [0] is well worth a read if you want to know more.
He also has an interpreter, Picol [1], in 500 lines of C code that is very easy to read and to understand.
Lord Nikon's Laptop [1] is really what I consider a true _Cyberdeck_.
P.S. Hackaday is running a Cyberdeck competition [2] if you're into that kind of thing.
[1] https://youtu.be/uxY6CUimZ9M
[2] https://hackaday.io/contest/186672-2022-cyberdeck-contest
I've played some of them on my phone and it worked really well.
This is the way.
The idea behind the stick was that you'd have a decoder next to your TV that would contain all the movies ever made encoded in a special format, and if you wanted to watch a particular one, you just needed a specific key that told the decoder how to decompress it.
It didn't really work, as you'd imagine.
* Fizzlefade by Fabien Sanglard [0] that explains the fade to red effect in Wolfenstein 3D
* How Pitfall Builds its World [1] that explains how the original Pitfall on the Atari 2600 managed to have 255 unique screens despite severe constraints on the storage space available (it used a maximal length 8-bit LFSR that was also invertible so that you can go back to previous screens).
[0]: https://fabiensanglard.net/fizzlefade/index.php
[1]: https://evoniuk.github.io/posts/pitfall.html
edit: formatting
https://archive.org/details/cambridge-university-press-illus...
I've been feeling nostalgic lately and playing around with Turbo C in DOSBox, so I'll definitely check it out.
[0] https://archive.org/details/1.-expert-c-programming-deep-c-s...
I was in need of a simple garbage collector for a toy project of mine and settled on a copying collector based on Cheney's algorithm at first [1]. The author's mark compact code is so easy to read that I was able to grok it immediately and replace my original GC without trouble and save half my memory.
[0] https://github.com/munificent/lisp2-gc [1] https://en.wikipedia.org/wiki/Cheney%27s_algorithm
(*) my script strives for compatibility with GitHub-flavoured markdown, so you could do things like extract the markdown in your code comments to, say, a GitHub wiki, and the markdown flavour stays the same between your README.md and your code documentation.
YMMV on whether this is actually a useful quality
Many years ago, I had this idea of creating a documentation tool for my hobby projects that was based on Awk.
I liked Doxygen, but it was a bit heavy duty for a small C library with only a handful of functions. You could almost guarantee that Awk would be available on the system where you might be compiling the project, so you could just bundle the awk script with your sources, add two lines to your makefile and have HTML documentation ready to go.
Now I had never heard of Markdown at this time; It was before StackOverflow or GitHub was a thing (perhaps they existed, but I haven't used them yet). Therefore my syntax was a crude markup scheme that was difficult to explain and didn't always work correctly.
Skip forward a couple of years and I had the bright idea to rewrite the script to rather use a Markdown syntax. This ended up being one of those hobby projects that you never really finish, and it grew organically to include all sorts of Markdown features. The result of that effort is now on GitHub [1].
Where does Markdeep fit into all of this? Sometimes when I stumble upon a project on GitHub that I find interesting, I click on the author's name to see what other repositories they have that looks interesting. One day I browsed GitHub like that and stumbled upon user r-lyeh's `stddoc.c` file [2].
It is a C program that simply extracts the comments from your source file and appends the Markdeep tags to the end. If you save the result to a HTML file, you achieve the same result as my script, except the implementation is much much simpler.
I nearly fell off my chair when I realised that all the effort I put into my own script was basically made useless(*) by Markdeep. Instead of parsing the markdown, I could rather have had Markdeep do all the heavy lifting, and it comes with a bunch of very nice features that I doubt I'd ever be able to implement in my own script.
[1]: https://github.com/wernsey/d.awk [2]: https://github.com/r-lyeh/stddoc.c
20 years ago I would've opened up VB6 and knocked out a quick GUI for that kind of work, but I never got on to the VB.NET train.
So I spent some time that evening looking at modern VB6 alternatives, but nothing satisfied me: Lazarus might be something I'd look to in the future, but I'm not too keen on Pascal, Gambas is not really suitable for Windows, then there is this and RADBasic that are incomplete.
In the end, I found a nice Tkinter tutorial [1] and managed to get the GUI I envisioned up in an hour.
I've played with Tkinter many years ago, but I basically had to learn from scratch. The speed at which I was able to get up and running led me to conclude that this is how I'll approach these types of requirements from now on.
The GUI didn't even look as bad as I remember Tkinter looking.
Not too long ago I had a project that was implemented as a complex state machine where the requirements kept changing, and keeping the documentation as an ASCII diagram in the source code had a couple of benefits: * It meant that the documentation could be updated when the code had to be changed * I didn't have to hunt for the diagrams on the project wiki when I made these changes. * The diagram was kept in version control with the rest of the code. Each commit/branch had a diagram that accurately reflected its state.
I could then use Ditaa to convert the diagram to a more appropriate format when updating the project's wiki or emailing the customer
[1] https://web.archive.org/web/20130813045206/http://www.asciif... [2] https://github.com/stathissideris/ditaa
I do however prefer to do this kind of thing through bookmarklets, so here's one I found in a quick search: https://github.com/zedeus/nitter/issues/451#issuecomment-946...