4 ms·

> (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in compute

> (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in computers, we all step on decades old legacy and nothing is truly built by us alone.) I mean something like this for example [0], which I just built for experimentation. It's a little GUI basically without dependencies (apart from the actual GUI code it's only some Win32 junk to paint colored rectangles and some text... this stuff is easy to replace with SDL or whatever backend works). The GUI has moveable / resizable windows, buttons, sliders, a simple layout method... The logic is super easy to extend, not the typical message handling mess that is seen in traditional GUI toolkits. Each widget is basically a 0-1 structs and 0-2 functions. This approach does have value. Not only does it make me happy - it gives me performance, flexibility, portability, modularity, build speed, control - each and every pixel coded on my own ... so much good stuff. As for the rest, consider belittlery as a hobby. [0] https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934fc2f34 https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934...

pdimitar 5y ago
I get the appeal for coding something with minimal dependencies. I do however consider it a hobby and I don't dare imposing that approach in my paid work, which inevitably has a number of limitations -- mostly time / schedule. That makes coding dependency-minimal projects a rare luxury since they often require love and care that don't conform to tight schedules. If you are in a position where you can do that for money then it's quite the privileged position! And you should be a very happy guy having it. I keep hoping that such projects will eventually find their way into the mainstream and show the rest of the world how wrong it gets a lot of things. Here's to hoping that it will still happen one day.
- jstimpfle 5y ago
  For better or worse, I do in fact get paid to do these experiments. One of my employers has this huuuge mess of MFC C++(98) code, with a lot of redundancy and repetition in the code. It's unmaintainable and we are in fact in need for better architecture. And while much of the problem is due to historical accidents and lack of experience from some former team members, a lot of the problem I ascribe actually to MFC itself and more generally to the traditional GUI approach - Widgets in classes, code sharing using inheritance / method overriding and using other approaches as well. The main issue lies in the premature objectification (compartmentalization) of things, which prevents sharing data => it's hard to share handlers, which means there will always be a huge overhead from communication and bureaucracy and duplicated implementation efforts. So here you have it, one example where a "feature" (OOP syntax) leads to bad choices (making up "messages" unnecessarily, using methods to implement per-message handlers), leads to an excess of "fibers" and in general of badly aligned structure in the application, and that leads to long term pain. While with the write-from-scratch approach and mindset, there is a certain upfront cost, but an actual chance to acquire a deep understanding of the problem domain and to avoid the long term pain from ill-suited structure. In the end, to get the architecture right, the syntax doesn't matter almost at all. Once a problem is thoroughly understood and a suitable data architecture devised, computer programming is only a question of simple data copies and adds and multiplies. For example, in my code, there is basically no dynamic memory allocation, and there are no messages and no callbacks. C is a good language to program simply, it provides a lot of incentive to do so. The issue described above is more general, it doesn't only apply to OOP syntax. Many language features are just canned solutions to do memory allocation, ownership tracking, message passing, threads organization, polymorphic dispatch... The problem is always, eventually, that one size does not fit all. And in fact, most language features seem to be optimized not for the most common situations but for small tutorial examples. The particular code I linked above cost me 2-3 days of work (I had prior experience in the domain), which is miniscule compared to the time that is otherwise spent in a project on business logic / features.

pdimitar 5y ago

I get the appeal for coding something with minimal dependencies. I do however consider it a hobby and I don't dare imposing that approach in my paid work, which inevitably has a number of limitations -- mostly time / schedule. That makes coding dependency-minimal projects a rare luxury since they often require love and care that don't conform to tight schedules. If you are in a position where you can do that for money then it's quite the privileged position! And you should be a very happy guy having it. I keep hoping that such projects will eventually find their way into the mainstream and show the rest of the world how wrong it gets a lot of things. Here's to hoping that it will still happen one day.

jstimpfle 5y ago
For better or worse, I do in fact get paid to do these experiments. One of my employers has this huuuge mess of MFC C++(98) code, with a lot of redundancy and repetition in the code. It's unmaintainable and we are in fact in need for better architecture. And while much of the problem is due to historical accidents and lack of experience from some former team members, a lot of the problem I ascribe actually to MFC itself and more generally to the traditional GUI approach - Widgets in classes, code sharing using inheritance / method overriding and using other approaches as well. The main issue lies in the premature objectification (compartmentalization) of things, which prevents sharing data => it's hard to share handlers, which means there will always be a huge overhead from communication and bureaucracy and duplicated implementation efforts. So here you have it, one example where a "feature" (OOP syntax) leads to bad choices (making up "messages" unnecessarily, using methods to implement per-message handlers), leads to an excess of "fibers" and in general of badly aligned structure in the application, and that leads to long term pain. While with the write-from-scratch approach and mindset, there is a certain upfront cost, but an actual chance to acquire a deep understanding of the problem domain and to avoid the long term pain from ill-suited structure. In the end, to get the architecture right, the syntax doesn't matter almost at all. Once a problem is thoroughly understood and a suitable data architecture devised, computer programming is only a question of simple data copies and adds and multiplies. For example, in my code, there is basically no dynamic memory allocation, and there are no messages and no callbacks. C is a good language to program simply, it provides a lot of incentive to do so. The issue described above is more general, it doesn't only apply to OOP syntax. Many language features are just canned solutions to do memory allocation, ownership tracking, message passing, threads organization, polymorphic dispatch... The problem is always, eventually, that one size does not fit all. And in fact, most language features seem to be optimized not for the most common situations but for small tutorial examples. The particular code I linked above cost me 2-3 days of work (I had prior experience in the domain), which is miniscule compared to the time that is otherwise spent in a project on business logic / features.