sguav

I'm probably getting older, but this gives me a speck of hope. Maybe some teens will rediscover or reinvent the pre-social 2000s web.

> Also I still haven’t figured out how to combine a mechanical and digital solution. Like I want light switches that match my server state for my lights. If I change the switch via my phone, I want the switches to change as well so that the physical switch is always the true state of the light.

For the lights that I want to "keep mechanically in sync" I replaced the switches with buttons and used a re-flashed (ESPhome) sonoff-mini which conveniently has a button input for the relay. Everything is synchronized no matter the operating interface.

Yes, Ada not ADA, my mistake which ironically Ada's case insensitivity wouldn't have caught :)

Any recommended resources to get up to a sufficient comprehension of functional programming for an EE who didn't get to study functional programming?

> The hardware industry can't benefit from rapid iteration because every iteration costs a mask set.

Before tapeout there are steps which could benefit I suppose. But as a functional-programming n00b I don't see how that could be the solution. I would argue that improving place and route algorithms to the point that deploying to a (large) FPGA is almost as quick as compiling software would be a huge step forward.

VHDL springs off of ADA, so I wouldn't say it was specifically developed. Anyway, ADA and VHDL are strongly typed, which incidentally works well with critical applications development such as hardware design.

You have high-level-synthesis tools on many FPGA vendors tools, using C/C++ or even Python for hardware description. I personally don't think they are superior than typical HDLs, the thing that makes the difference is to think about the circuit you ought to describe, the language you use then is not as important IMHO.

True, I directly answered the syntax-related question, but talking about implementation this would be a bad description - be it FPGA or ASIC.

As the parent's-parent comment said in other words, think circuit first.

HDL (hardware description languages - Verilog and VHDL the most representative ones) do actually work like that.

They give you access to structural descriptions for bitwise control, but also and mostly behavioural descriptions which allows hierarchies of modules (the blocks you described) and abstraction up to anywhere basically. This last part is generally referred to as RTL (register transfer level) design.

To make a circuit from this RTL description you usually need more steps: synthesis (where RTL gets "compiled" into the actual gates and flops to be used) and implementation (where the logic gates of the previous step are actually translated in the "fabric" you have available - FPGA logic blocks, a foundry's standard cell library ...).

always @(posedge clk or negedge clk)

> One of the biggest problems with being indispensable and announcing that you feel stuck, is that the business will take steps to get you even more stuck, through more money, shinier titles and stock options.

This worries me, as I'm experiencing it right at this time. No idea how to get unstuck either.

But can you imagine the adblock activated by the "flip off!" (or more colourful) thought?

Nice article, I didn't know this iterative process could trace back to Feynman.

Anyway, I suppose it would benefit the article if the title was to reflect the original as per HN guidelines