I just skimmed over this, and was rather bothered by the fact that they just jump directly into syntax. There's essentially zero discussion about simulation or design.
Writing VHDL isn't programming. If you treat it like it is, you might get something that works in simulation, but it's going to be horribly inefficient at best, and will more likely not work at all in hardware.
I don't think it's helpful to refer to VHDL as "not programming". It is programming, just in an inherently parallel, declarative fashion rather than an imperative one. My favourite metaphor for programming in an HDL is to think of it as building a computer or writing a program using expressions in a spreadsheet.
I have a background in Electrical Engineering, and when coding in a hardware description language, I feel that instantiating and connecting entities is like drawing a hierarchical schematic but in text mode. And writing the RTL implementation of an entity is like giving requirements to the synthesis tools that I need a bunch of gates and flip flops that implement this functionality. When coding in some programming language, I have a completely different mindset.
Programming usually means coding in some language that will be compiled to machine language, and hardware description is so different kind of "programming" that I think it's dangerous to call it programming at all.
I agree, but, in that case, someone will need to combine teaching digital design along with a HDL.
I believe the authors assume that the reader is actually familiar with architecting digital systems or learning it concurrently from some other source.
Writing VHDL isn't programming. If you treat it like it is, you might get something that works in simulation, but it's going to be horribly inefficient at best, and will more likely not work at all in hardware.