Hacker News Reader

Comment by QuadrupleA | Hacker News Reader

Cool project! It's interesting the dichotomy in tech communities between the 'minimalists' on one hand who love to get under the hood, work their way down to the bare metal and understand how everything works, and the opposite trend, building seemingly simple web apps that sit on top of 1,000 libraries and frameworks, pack their huge dependency chains into Docker containers distributed onto clusters (probably because the app runs so slow on a single VM), etc. I wonder if it's two fundamentally different kinds of personalities at work.

View on HN

The first person you describe has to have almost endless amounts time and/or technical interest available to them. The second person you describe has a job to get done as quickly as possible and move on to the next job.

The whole reason libraries and frameworks were created is so everyone doesn't have to dig down to the bare metal to get a task completed. If my manager asked me to provision a server to run an application on and I sat down and built my own hardware from scratch and then wrote my own OS rather than clicking a single button in VMware, I'd be fired pretty quickly.

You sound defensive. I don't think the parent meant that one type is better than the other.

The fundamental difference is not amount of free time. It's just a question of interest and what you are good that. There are people who spend their endless free time making shiny web apps just like there are people who spend it designing CPUs for fun.

Depending on your line of work digging to the bare metal does help get your job done quickly. I know a number of embedded systems programmers, bare metal is their job. There are people paid to work on the Linux kernel, to program FPGAs for high-frequency trading, and so on.

And learning the low level can help doing your job quickly even if you are not a systems programmer. All abstractions are leaky and inevitably some low-level problem will bubble up into your high-level application and you will have to deal with it. If you understand the low-level it may take half or one tenth of the time to figure out and fix the problem.

There are tradeoffs everywhere. The parent made it sound like libraries and frameworks are always going to make you go faster, of course that's not always the case and I don't think the parent believes that. It's very often worth it to descend a level or two to do your job, some things can be done faster, lower, though it's rarely worth it to descend all the way to the bare metal or deeper (but sometimes necessary). Another but echoes your conclusion, sometimes a bit of knowledge at those layers will indirectly help at the layers above.

When the subject of many layered JS frameworks and dependency graphs with hundreds of mini libraries comes up I'm always reminded of Rasmus's 30 second ajax tutorial: https://web.archive.org/web/20060507105529/http://news.php.n... (And the modern equivalent: http://youmightnotneedjquery.com/) Very often libraries and frameworks are brought in because they "help us go faster [because of x,y,z]" with some x,y,zs like "we don't have to think about that problem" or "the global architecture/structure is taken care of", but the cost of dependencies sometimes outweighs the cost of thinking about the problem and doing it yourself. Libraries and frameworks are tradeoffs, you'll likely use a lot of them if you look at every layer you can actually influence, but they're not necessarily net boons.

Yeah, I can agree with that. You'll get the most value out of understanding the 1 or 2 layers below. Digging all the way to bare metal is usually not necessary or practical, though it may help once in a long while.

For example, ORMs. If you try to use an ORM without knowing SQL you will have a bad time as soon as you hit performance issues or you have to do something that doesn't fit quite nicely into the ORM model. I have yet to see a project that uses an ORM that doesn't use SQL in places.

ORMs are not necessarily net positive. They make some things simpler at the cost of an extra layer of indirection.

Going a level deeper, knowing how query planners work at a high level will help writing performant SQL queries.

Going as far as understanding how your RDMS is implemented should not typically be necessary. It would help for finding bugs in the RDMS, but that should be very rare.

You are 100% right. This project fits 100% with my personality. I like to understand in details what I'm working on, even if I need to "loose" time exploring things not directly linked to what I'm supposed to do. And I also like systems that are designed at necessary level.

Hi, this is fantastic! Thanks for sharing.

I would be curious to know what your level of proficiency was in some of these areas such as C, Verilog, writing assemblers, programming FPGAs, board wrapping, etc.

How much learning did you as you went vs how much prior exposure did you have to some of these things?

Are there any resources you found helpful or that you would recommend to others who want to undertake a similar project?

Cheers.

I started this project with only standard electronic knowledges. I had no experience of FPGAs, of writing compiler and assemblers. I learned these topics as an autodidact. It is a "learning by doing" project. And of course, I have learned tons of new things, this is a very rewarding project.

> I wonder if it's two fundamentally different kinds of personalities at work.

Not two different kinds of personalities, just two different kinds of work. Many people find ways to do both.

The minimalist role is better for learning and building for the art of it — when the purpose of the making is the making itself. The article is a great example of this.

The other role is when that learning needs to be applied to a further end. E.g. when shipping product, code is a "means," and pre-built libraries and layers of abstraction are leverage.

Give it a few years, and we will see the first ‘compile npm to FPGA’ project that still uses a thousand libraries, but does away with the CPU, the OS, the docker container, the web server, etc.

(if it doesn’t exist already. The best I can google is https://github.com/hamsternz/FPGA_Webserver, which is incomplete, misses the ‘npm to’ part, and seems abandoned)

I don't think it's necessarily two fundamentally different personalities (unless I have multiple...which I might...)

I grew up taking things apart, and I loved the courses where we build logic gates or modified compiler or interpreter code.

I now build things on the shoulders of giants.

But when I need to, I know I can dive to the deepest levels to debug something, or I can write or customise any part of the stack.

It sure is a mindset shift and a context switch. I consider choosing the right moment to switch approach to be one of the most important and hardest tasks of developing software systems.

I'm a bit of an odd duck because I do ASIC design for work (custom Digital Audio Codecs) and do web development for fun/side work. So I do the bare metal and the high level.

I have an unrelated question for you: what's the state of the art in audio codecs?

Back in college ten years ago I was told that while technically we have 24bit ADCs, it's more of a marketing stunt because the few last bits are essentially garbage since the voltage levels correspoding to some of the more significant bits are somewhat off.

You might be referring to "Effective Number Of Bits". Physically realizable ADC and DAC devices are not perfect so you can use metrics like ENOB to estimate how your system might actually perform.

https://en.m.wikipedia.org/wiki/Effective_number_of_bits

There are some DACs that claim crazy high SNRs of 130dB. But my experience is that anything over 100dB is really good. Anything over 110dB is nutty. That puts it at 21-22 bits.

It reminds me a little of people who restore old cars, yes, there's something great about it, but no, I'm not interested in driving a Model-T around myself...

You are right, but my A2Z is not like old cars or vintage computer. It's more like designing and building from only few existing parts a karting, or a small buggie, without refering to existing drawings. A very simple machine, not very advanced, but that I understand in all its details.

It's like a form of art, and this is great artistry. Thanks/merci for sharing, it's motivational to see these things reach a "finished" state.

Yes, the "finished" status of A2Z is what I am the most proud of. Lots of "CPU on FPGA" projects only deal with the CPU itself, and will never become a fully "usable" computer. I managed to work on the 3 main topics : hardware, software dev toolchain, and software itself.

Reply on news.ycombinator.com