Things That Turbo Pascal Is Smaller Than (2011)
https://prog21.dadgum.com/116.htmlFundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore, and the cost of larger projects with clear abstraction boundaries has plummetted.
There's no reason (other than laziness) why that should take more than 2k.
On the other hand, a lot of boilerplace code is repeated in each and every command. When I first learned as a kid about UNIX commands being ordinary programs, I was intrigued (there is nothing "special" about them, you can also write your own!) but also shocked about the overhead compared to an architecture in which e.g. the shell contained all (at least core) commands compiled into a single binary, which could share all the error handing, startup code, command line parsing code and so on.
Really it could have been go-lang before go-lang and I'm not sure why it wasn't other than that it wouldn't have been controllable by the folks at Google.
Though Borland had some commercial success, I remember Pascal mainly as a teaching language.
In the absence of that, Pascal’s creators and commercializers invented follow-on languages, including the most successful thread via Hejlsberg as we’re discussing here: Object Pascal -> Delphi -> C#/.NET—with a brief detour to J++, which I don’t know enough about to understand if it belongs in this sequence.
Bytes have history, meaning, context of creation, different utilities and different cost associated with creation/transfer/storage/manipulation
We could also use those comparisons to praise how complicated our current world has become and how good we are at managing such complexity
Zabbix also confuses operators at this point. I recently had to increase a cache. I chose to go from a solid 4MB to a luxurious 256MB.
I know high-performance Java, so just a little jab there, but you don't size JVM parameters like that, except maybe code caches. And before Rust comes in, we also have a Rust application running without good resource control and it wouldn't like those resource constraints.
There is truth to this article.
> zlib.h in the Mac OS X Lion SDK (80,504 bytes).
What a stupid comparison. zlib.h is probably 99% comments.That said i never finished that and ended up making another one (using tvchat as a base since it had largely working communication and session management) that acts as a server/daemon inside the container is meant to run in the background and provides a web-based UI instead.
http://runtimeterror.com/pages/iv/images/25b1d4b43bb3467e392...
Comparing to current-day stuff is kinda like comparing battery-powered bathtub toys to jetskis.