[jbjb]

Originally Posted by Quoth

I'd didn't list HDLs, because although those are "languages" and describe a design, it's not creating a program.

Technically, probably not programming languages (at least by some definitions), in that they don't (necessarily) produce code to be executed by a computer, but there's much overlap in the skill sets required, and some implementations will blur the boundaries somewhat (e.g. Verilator, which will convert SystemVerilog (and others) to C++).

HDLs do require some different ways of thinking, when compared with normal programming languages (consideration of timing, heavy emphasis on parallelism, and a clear understanding of the hardware that will be generated etc. etc.), but many of the elements of the programming craft are also very relevant to HDLs.

I'd also argue that exposure to HDLs makes a better programmer, even if that programmer never actually designs any hardware. Understanding of the hardware that will run your program is one of the biggest weaknesses of most programmers, in my experience).

That's my objection to Verilog; it looks too much like programming.

Speaking as someone who spent too many years designing chips at gate level, or below ("polygon pushing"), "looking like programming" is a good thing - it raises productivity massively.

I'd argue that, in many ways, HDLs are programming languages, the only difference is that they compile to hardware rather than machine code for some processor or VM.

In terms of the way logic is expressed, I'd say something like SystemVerilog is *more* similar to a traditional programming language like C than something like Prolog is.

Similarly while Javascript is really nothing to do with Java, and that name was Netscape stupidity, it's as much a programming language as Basic or VBA

Agreed. Personally, I have no problem with Javascript (or ECMAScript). Java itself, on the other hand, annoys me enormously (just my opinion!).

A programming language is executed by a defined architecture of "processor" (which could be cogwheels and cams) and as a minimum has:

• A test with jump or skip based on a flag or boolean expression. One state can jump or skip and the other doesn't. If - Then -Else, Case/Select and all kinds of loops (While, Until, For) can be built from that.
• Assignments, which can be the result of a boolean or arithmetic expression.
• Variables
• Literal constants.

Apart from "being executed by a processor", HDLs like SystemVerilog meet all those requirements.

Being able to do arithmetic to addresses ought to require a special directive and be limited to a few device drivers or very low level assembler in some very simple microcontrollers that have no high level language.

Depends what you're writing - if you're writing highly optimised high-performance code (maybe for DSPs, but not necessarily), or OS kernels, or memory management code (will often happen in userland code, not driver-level), or many other scenarios, address arithmetic is entirely appropriate. C has been successful for a reason! Admittedly it can go horribly wrong, but if you know what you're doing it's very powerful, so you just have to be careful about who you allow to do it. (And horrible, dangerous code can be written in any language - there's no C monopoly on that!).