Chisel/Scala hardware description language: why?

[james_s]

The verbosity is one of the things I like about VHDL, I find it much easier to read, while Verilog looks like abbreviated gibberish. I can type much faster than I can think so the extra typing is a non-issue.

I've noticed though that some people make VHDL more verbose than necessary, including all the component declarations rather than just instantiating them from the default "work" library. The component declarations are only really needed when integrating a Verilog module.

[tggzzz]

I find VHDL to be aweful. I find it is endlessly verbose and that is what I think Chisel aims to remedy. I looks (from a great distance) to be a more abstract language. Usually learning the syntax of a new language is not the problem. It is learning the paradigm and mindset (and their libraries and tools) that take real time. Ultimately the goal is to be more productive.

I did some (hobbyist) VHDL but my next project will indeed be in System Verilog. To me that looks like the best blend of abstraction, conciseness and readability. Not perfect but the best we have - not looked at other languages due to lack of knowledge of their existence and sometime lack of available tools.

Frequently the productivity depends on the scale and duration of a project.

For a short-duration project completely done by a small team, verbosity can seem a drag. For a longer-duration project, or one where there are multiple teams maybe in different organisations (e.g. libraries), then verbosity can reduce the implementation time.

In most "interesting" projects, implementation is a very small fraction of the total project time. Requirements elicitation and validation, and implementation verification are often the tail that wags the dog. Key question: what percentage of time is spent typing vs designing/compiling/place&route/testing?

In the software domain there is a cycle that I've seen repeated several times:

• start with a non-verbose lanuage with many implicit features (e.g. one or more of variable declarations, dynamically typed variables, control constructs); think C and Basic and Excel(!)
• find applications become brittle and unmaintainable
• move to strongly typed languages with explicit variable declarations and comprehensive control constructs; think Java, C#
• applications become larger and more robust
• new young developer mistakenly thinks the extra typing slows you down
• (re)invent new language with fewer keystrokes; think Ruby and others

... go back to the beginning.

[hans]

There are also "competing" language suites to Chisel, like for example Clash. They both share a similar concept, as Scala has some remedies of functional programming. Clash uses Haskell, which IMO fits even better.

For example, here is a FIR filter:

Code: [Select]

fir coeffs x = dotp coeffs (window x)
  where
    dotp as bs = sum (zipWith (*) as bs)
Function fir takes a vector of coeffs and a value x, of which it calculates the dot-product (defined in "where") of the coefficients and a windowed version of x. The window function can figure out it's depth purely on types, as the function dotp will dictate it (not explicitly shown here).

There is no need to specify the types of the inputs that exactly (e.g. signed, unsigned, or float), as Haskell has kinds which allows for truly generic type programming. The "generics" in VHDL are mainly just some constants you can change manually of a module. The type system of a language is very important, "verbosity" is annoying, but purely lack of correctness-enforcing features is a worry if you want to build working modules.

Both tools are somewhat academic still. These RISC and other projects are proof of concepts, and part of the process of finding design patterns in these tool suites. I think it will takes a long time before any such higher level, more abstract capable, languages will "take over". I think it's the exact same discussion that C is the language for embedded systems (or perhaps some 'older' folks will say it's assembler). Meanwhile in C programs will quickly grow into structs-based data organization, but with the apparent lack of marrying methods to them.

[Nerull]

Exactly the same reason you might write a program in C instead of in assembly language.

Well, NO!

Talking about my paid jobs, VHDL is *THE* language to design HDL stuff, and I have collected a lot of job-experiences for this, as well as professional tools for this.

Now RISCV appears and when you look at the code, a lot of projects come written in another HDL language for which I have to start from the beginning.

It's not like Assembly vs C, it's a matter of reasons and purpose. Now, or this new language has valid points, or I will avoid spending my time (and probably money) on it.

If there is anything the history of programming teaches its that there's never one "*THE* language" for very long.

Then again maybe if you were doing financial computing you'd still be using COBOL, since it was *THE* language for a while, and its not possible for this to ever change.

[mac.6]

There is not need for gigantic fonts.

Paid jobs will always be using the old tools, of course. But the question "why you need new stuff then", is invalid.

And at my paid job, Chisel is the old HDL that all the legacy hardware was designed with, and the question of the moment is whether SpinalHDL is enough better (it clearly is better) to be worth converting everything to .. or whether Chisel can reasonably be enhanced to match Spinal (probably).

Interesting, I was involved in RISC-V effort in my company and Chisel was not seen "good" enough by HW guys due to critical issues with it (mainly at the time the single clock domain was a big no-no). I found SpinalHDL quite interesting and can solve most of Chisel issues, but the lack of adoption is also a big no-no when there is only one guy behind it.
Having SiFive converting to SpinalHDL would be a big accelerator for it.

[filssavi]

There are a bunch of new HDL that look pretty cool, chisel, spinalHDL, etc, they all solve a really important problem, verilog and VHDL are too low level, they are basically whay assembly is to modern x86_64 CPU's,
shure you can program with them, and if you are good the end product will be blazing fast and small, however the productivity is really really low, after all who would want to write a modern application (think of  compiler like gcc or llvm) in assembly?

Moreover testing and verification support in the languages themselves are almost non-existant, and the support for the few features we have is spotty at best, without paying hundreds of thousands of $/€ to the big 3 for their expensive tools.

Unfortunately nothing is going to change in the near future, as there is no competition whatsoever between tool vendors, the big 3 (Cadence, Synopsys and Mentor graphics), are not only producing tools but also definign verilog and VHDL standards and have no incentive to produce a better more modern language, that requires less and simpler tooling as that would considerably reduce the ammount of tools they can sell, and significantly reduce the barrier to entry for new tooling producers that might want to compete on price, forcing them to reduce prices

The only hope of a modernization (revolution) in this field (even though the chances are slim) is for the symbiflow effort to succeed becoming the GCC/LLVM of hardware, a de facto open source standard tool that everyone supports

[FrankBuss]

Interesting answers here

I don't think the answer were interesting. If I didn't missed it, nobody who answered has actually used Chisel. They only say it is a good idea to learn and try new things, which is like a horoscope, always true.

I have tried Chisel, at least some of the tutorials, and I like that it is less verbose, and that it is much easier to write testbenches for it. Of course, if only one clock domain is possible, this would be a show stopper.

Are there any real users in the industry here who uses Chisel, SpinalHDL, or MyHDL? What is your experience? Looks like from the answers in this thread, at least one company uses SpinalHDL. I like Scala (learnt it 6 years ago at Coursera, got a Statement of Accomplishment, with distinction, from Martin Odersky himself) and would try SpinalHDL then. Why is it better than Chisel?

[legacy]

What is your experience?

I work in the avionics field. We only use VHDL on large ModelSim test benches and Cadence software. We have recently spent a lot of time on the ARINC 429 products that require FPGA on the hardware, as well as products with the "voter" unit. There are also AFDX products that require FPGAs for data transfer on aircraft avionics. Nobody has ever complained neither found VHDL too verbose etc.

We usually spend 10-20 months on a product, that must be guaranteed for the next 10 years.

Recently we have also been evaluating VHDL-AMS models for analog/mixed-signal blocks and verify their functionality and performance using the Virtuoso AMS Designer simulator. Two managers still have to take a decision about the final purchase of a couple of new licenses.

Anyway, on my personal laptop, I have my own copy of ModelSim with a license in my name. I am not mixing the analog with the digital. For the analog stuff, I have also a license for Tina professional (sort of PSPICE). But it's more used for designing filters and to check their probable response before I can physically touch the hardware, because, as you can imagine, the hardware is usually not available for me ( I am a freelancer) so I have to ... wait for my turn ... and this might take weeks, so with the experience of the last task, I speculatively anticipate a part of my next task in order to be ready once the hardware is ready


in short, I am working like the branch prediction in the RISC-ish CPUs

(the TINA/Pro software is really helping a lot in this  )

[brucehoult]

Are there any real users in the industry here who uses Chisel, SpinalHDL, or MyHDL? What is your experience? Looks like from the answers in this thread, at least one company uses SpinalHDL.

I'm not a hardware designer, I'm a programmer doing a lot of work with compilers and system software and also (along with the hardware guys) help design new CPU instructions for the hardware guys who sit a few feet away to implement.

I sometimes open a Chisel file and check something, or make a trivial mode, but I'm sadly absolutely not competent to comment myself on the practical differences between writing large things in Chisel vs Verilog.

All CPUs in our company are currently designed in Chisel. This includes at present three different microarchitectures (2-series, 3/5-series, and 7-series) of which both 2-series (2 stage pipeline) and 7-series (8 stage dual-issue) were completely created from initial design to customers using them in SoCs during 2018.

All three microarchitectures are highly parameterized in one source code base (and indeed there is a huge amount of sharing between them). Some of the switches available in all three are (at least!):

- 32 bit or 64 bit
- pure 32 bit instruction opcodes or 16/32
- no integer multiply/divide, or a choice of several speed/area tradeoffs
- speed/area tradeoff in integer shifter
- no FPU, single precision FPU or double precision FPU
- no memory protection, or a configurable number of Physical Memory Protection regions
- no MMU, or MMU
- machine mode only, or User+Machine, or User+System+Machine modes
- private L1 data and instruction caches independently: none, L1 cache or SRAM scratchpad.

Well, there's a lot more, but you get the idea.

The processors generated by this system work, run faster than competitors' processors in the same semiconductor node, are smaller, use less power. Some of this may be due to Chisel. Some of it may be due to the RISC-V instruction set. What I can say for sure is that neither Chisel nor the instruction set gets in the way.

I'm pretty sure that using Chisel (or something similar) is a *major* factor in being able to develop new and competitive processor cores quickly. Both 2-series (Alex) and 7-series (Andrew) are essentially the work of *one* engineer each as far as the HDL goes. Building, of course, on the work that went before in Rocket and 3-series and 5-series, and supported by several dozen other people doing everything from simulation to physical design to writing software to ...

[Bassman59]

A quick web search brings up the Chisel page at Berkeley, and followed links to a user's guide of sorts.

Now, I do VHDL daily, and I've done Verilog in the past, and as a hardware/FPGA engineer I looked to see whether Chisel supports the usual constructs. I also looked to see how it works as a simulation/verification language. Also, I've noted in this thread that many people assume that writing VHDL (or Verilog) is somehow akin to writing in assembly for a processor. That's really not true at all. (If you want an example of VHDL-as-assembly-code, look at the Xilinx PicoBlaze code, which is nothing more than instantiations of the LUTs with INIT values and flip-flop primitives.)

My current work involves data paths from multiple ADCs, with some processing on samples, and pushing those samples into block RAMs for re-organization prior to being shipped out over a communications link. There is also a lot of "other" stuff required, such as a command/data uplink, a command parser, a mechanism to store parameters in off-FPGA non-volatile storage, SPI control of DACs for setting biases and control of ADCs for housekeeping. I think this sort of design is where FPGAs excel, and it's probably the most common sort of FPGA design. There is no sequential-execution processor in this part of the design. (Sensor data go to and commands come from a remote box with a processor, but that's because the processor is well-suited to managing an Ethernet interface.) A current design has three clock domains.

So, with that. I looked at examples for describing synchronous logic, since that's the basis of digital logic design. We're all familiar with VHDL's process and Verilog's always blocks, both of which make clear which signal is the clock, which is an async reset, and so forth. The examples here are, honestly, baffling. None of the examples seem to make clear which clock and which reset are used. Maybe I'm missing something, maybe there's a mechanism to indicate "all of these signals are clocked by this and reset by that," but I can't find it.

I assume that it can infer adders and multipliers, based on operators.

There appears to be a very simply method of instantiating memories, with both synchronous and asynchronous reads.

It has a mechanism similar to a VHDL generic that allows one to pass a, well, generic, down to an instantiated entity where it can be used as a constant or as a thing to select.

There is a thing called BlackBox which allows the designer to hopefully instantiate device-specific hardware, such as high-speed serializers and deserializers or input and output DDR registers and clock PLLs and DLLs, all of which are necessary for real designs. It might be useful to see an example of how Chisel would handle the instantiation of a Xilinx DCM and how it can use that module's outputs to clock various logic parts.

That Chisel seems to think tristates are not important is puzzling -- sure, inside an FPGA we cannot use them, but at the I/O they're used all the time.

That I can't tell what logic is synchronous and what is combinatorial strikes me as somewhat dangerous. You know, the whole Cliff Cummings "Styles that kill" thing, where you can write Verilog with blocking and non-blocking assignments. Hell, looking at the Chisel examples, I can't tell if there's any sort of delta timing model involved.

They admit that for non-trivial test benches you should use Verilog.

OK. That there is a RISC-V implementation written in Chisel is interesting. But what I want to understand is: why is Chisel "better" than VHDL or Verilog/System Verilog? It looks simultaneously verbose yet

Part of what makes VHDL "Verbose" is that you have to specify things like the clock and the reset and which edge of the clock is used for the logic and all of that. A person looking at the code wants to know that stuff. And then we can hide it all by putting it into an entity and verifying the entity is correct, and then instantiating the entity where it is needed.

Chisel has software-based concepts such as inheritance and classes (there's an example which starts with

Code: [Select]

class StackPointer(size:Int) extends Module { ) but are those useful in hardware designs?

Anyways, these are just my first-order thoughts. There are things about the standard HDLs that work well, and things that can be annoying, and we all know the line about "the languages were originally for simulation and modeling with synthesis an afterthought." But, sheesh, it's been over 30 years for VHDL and likely that same amount of time for Verilog, and it is obvious that both languages have evolved to the point where they that "original" concept is obsolete. A competent engineer can write correct descriptions of the intended synthesizable logic and then turn around and write comprehensive test benches (that take advantage of non-synthesizable constructs) in either language.

Or, tl;dr: tell me why Chisel (or, really, any potential new HDL) is significantly better for hardware design and verification than the incumbents, and please don't bullshit me.

[tggzzz]

Useful, apparently sane, review omitted for brevity.

Or, tl;dr: tell me why Chisel (or, really, any potential new HDL) is significantly better for hardware design and verification than the incumbents, and please don't bullshit me.

Too often it comes down to "I don't know the history, so have reinvented the wheel", which implies they are unaware their explanations are bullshit.

The same is true, in spades, for most computer languages. Realising that has enabled me to skip learning many languages-du-jour (e.g. Delphi, D, C++, Modula, Ruby, C#) and concentrate on learning significantly different ones (e.g. Algol, C, Smalltalk, Java) along with knowing the principal benefits of other paradigms so I can implement them in the "trad" languages (e.g. FSMs, various rules-mechanisms).

I'll also note that a traditional pitfall is to develop a higher level language that implements one paradigm very well. But if your problem doesn't fit into that paradigm, you're sruffed and there's no escape route.

That's similar to you noting that Chisel (etc) stumbles badly over vital abstractions like digital clock modules, SERDES i/o blocks, and probably asychronism/metastability.

[Bassman59]

After some more poking around, I found the SpinalHDL documentation, which seems to be an extension (?) or clarification (?) of Chisel, or possibly a fork? Whatever.

All of the examples I saw for sequential logic assumed a clock was defined somewhere but I could not find out how that might happen. I found this page, which discusses the concept of "clock domains," which are applied to the entire design or to individual modules, in a way I haven't quite understood.

What the clock domain concept attempts to do is to wrap up everything necessary for your flip-flops into one instance of a class, and then that instance is sort of hidden away somewhere. By "everything necessary" I mean it indicates the active clock edge, reset type (async or sync) and level, a possible additional synchronous reset, and a clock enable. Why this is preferable to having all of that information right there in front of you in the form of a process which specifies everything is not clear to me. It saves typing?

SpinalHDL has a built-in check to warn you if your signals cross clock domains without a special tag applied to the signals. Crossing clock domains is not an error, we do it all the time, and the competent engineer will handle that appropriately (and put comments in the code indicating such).

Possibly the biggest thorn in the rose here is that there is zero native synthesis support for this language. Whatever you write gets boiled down to synthesizable Verilog or VHDL. So you have to trust that the boiler does the right thing and doesn't generate stupid VHDL. Experienced FPGA design engineers know to check what the synthesizer actually implements from the source code; sometimes the synthesizer makes baffling choices. With Chisel/SpinalHDL there's an added step -- is the resulting hardware wonky because of the SpinalHDL description, or the SpinalHDL-to-Verilog conversion, or the Verilog synthesis that you should probably constrain in the usual way?

So, again, I ask, why is SpinalHDL "better" than the incumbents? I realize that's a purely rhetorical question as nobody on the language definition team is reading this.

And that last sentence brings up a good point. "People" like to complain that VHDL and Verilog were "designed by committee," with the implication that the reason the languages are "suboptimal" is because of the committee. But why is a new language designed by a couple of guys at a university better? The language committees exist for good reasons. How else can you possibly get significant input from experts from all over, with different points-of-view and different experience? No single person, and no small group, can possibly have the breadth of experience needed to do this sort of language definition.

[Marco]

Why this is preferable to having all of that information right there in front of you in the form of a process which specifies everything is not clear to me. It saves typing?

Also screenspace and it prevents copy paste errors.

[brucehoult]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

[tggzzz]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

It strikes me Chisel is in need of a decent whitepaper, along the lines of Gosling's 1996 Java whitepaper. That stated, with admirable brevity and clarity, what the key features were, why those features were chosen, where the features had been successfully used in anger, and why all of the features played well with each other. Plus which features were omitted and why (that's important; consider C++ ).

A standard problem of organically-grown DSLs is that they do one thing well and cover 80% of the requirements. Provided your application is within those requirements, the DSL can be very productive. But when you go outside the 80%, you fall off a cliff. I would like to see a statement of what's outside the design objectives.

Finally, that article states "Due to language features and libraries, the real utility metrics become: How many lines of code do I need to describe some component? Does the language enable writing and reusing code?".  That's a typical non-professional hacker mentality. Professional think a useful metric is "how quickly can I get a demonstrably working solution". Bugger the number of lines of code and code reuse; they are secondary.

[NorthGuy]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

[tggzzz]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

I am coming to that conclusion, too.

I've seen too many such attempts in this arena and also mainstream computer languages; not following them has saved me years going up blind alleys.

[legacy]

In short: I will go on with VHDL & my commercial tools until something will convince me that I'd better consider Chisel/Scala.

Chisel/Scala requires Java (it's in its dependency), and the procedure to compile the tool is ... a bit long and complex, so ... frankly, I don't like to deal with Java on PowerPC/POWER, which is my daily development platform.

for this turn, I am out 

[Bassman59]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

From a comment on that article:

The synthesizable subset of Verilog, VHDL, etc. share qualities of both procedural languages (C) and low-level languages (assembly). This makes them poorly matched to solve classic hardware design problems: design re-use (we write the same modules over and over) and specialization (targeting different FPGAs, ASIC toolchains, VLSI technologies).

For the assertion about design re-use, has the commenter never heard of modules? Every FPGA engineer I know has a "kit" full of proven modules ready to be reused in new designs. We don't "rewrite the same modules over and over."

As for specialization, nothing in the description of Chisel appears to actually deal with the differences in device families -- they have an out and say, "just black-box the chip-specific thing."

Regarding toolchains, that's actually a separate issue from the design entry (which is, after all, what Chisel is all about). I write the VHDL and then use a synthesis tool to build a netlist ready for the place-and-route. The VHDL doesn't care* which synthesis tool is used. Nothing I've seen in any of the Chisel documentation addresses constraining designs, whether for timing or for placement, which does make sense -- the logic design doesn't really care about timing (up until you have to reconsider your design so it meets timing, that is). But to complain that VHDL and Verilog are ignorant of toolchains while Chisel itself is ignorant of toolchains doesn't make any sense.

* well, to the extent that we use synthesis pragmas to direct the operation.

[brucehoult]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

I really can't say. I'm a software and instruction set design guy, not a hardware designer. I've never done anything serious in any of Chisel, Verilog, or VHDL.

What I *can* say is:

1) the guys who sit a few desks away from me designing CPU cores and SoCs in Chisel are very happy with it, and are knocking out new and competitive designs at an astounding rate considering the small number of people in the company

2) no one is trying to sell you Chisel. No one except you is going to make more or less profit depending on whether you use it or not. You've been made aware of it, investigated, and made up your own mind. Great!

[legacy]

Next week we will meet a salesman of the ensilica group. They have an interesting Configurable Embedded RISC Processor, covered by a full development tool.

So I was said. I am curious to see the environment 

[NorthGuy]

What I *can* say is:

1) the guys who sit a few desks away from me designing CPU cores and SoCs in Chisel are very happy with it, and are knocking out new and competitive designs at an astounding rate considering the small number of people in the company

2) no one is trying to sell you Chisel. No one except you is going to make more or less profit depending on whether you use it or not. You've been made aware of it, investigated, and made up your own mind. Great!

Perhaps you *can* do more. Ask those happy guys what's the single most important quality of Chisel which puts it ahead of other languages, and post their answers here.

[legacy]

LOL

for me the premium point for staing on VHDL ....  is ... hey, oh? I spent 14 months at designing and developing a stand-alone beautifier, from the lexer to the parser, and then from the parser to AST used to the semantic action (which does nothing, it's not a translator, it's just a code beautifier, but it's cool when you exposer your project to people because having an AST opens the door to more features .... eventually a translator from VHDL to Verilog? maybe)


Oh, so: should I have to start again from the beginning for a new language?!?!? 

I want a "n", and a "o", say NO

[ataradov]

People should not stop working on stuff just because you don't need it. Just leave the thread if you don't have anything useful to contribute.

It is not a Scala author's problem that you developed some tools for VHDL. I don't think anyone here cares.

I too would like to hear from those developers at SiFive.

[brucehoult]

Perhaps you *can* do more. Ask those happy guys what's the single most important quality of Chisel which puts it ahead of other languages, and post their answers here.

I asked them and they gave me the link I posted here yesterday.

Chisel is just one part of a hardware creation pipeline that works a lot like LLVM in software.

With LLVM you have various programming language compilers including clang (c/c++), go, rust, fortran all producing LLVM IR (Intermediate Representation). You can then run a variety of machine-independent and machine-dependent optimisations over the IR. Then you feed the IR to a code generator for x86 or ARM or RISC-V or whatever. If someone writes a new optimisation it will work with every language and every processor. If someone writes a new processor back-end it will work with every programming language. Etc.

In the case of Chisel, it's a high level language for humans to specify not just some particular item of hardware, but generators for families of hardware designs.  Chisel outputs firrtl. There are general optimizers for firrtl that clean up the design. There are optimizers for firrtl that mold the design to fit better FPGAs (or to better fit LUT4 or LUT6 FPGAs), or better fit SoC. There are "optimizers" for firrtl that obfuscate it so you can give synthesizable HDL to someone and it will work but they hopefully won't be able to figure out how it works or change it. Then there are back ends for firrtl that produce Verilog or other traditional HDLs to feed into a physical design workflow.

In addition to being able to parameterize modules with Chisel, there is a tool called Diplomacy that works out the constraints on parameters between instantiations of different modules, doing things such as finding the best bus width between two modules, or deciding whether some control signal is necessary or not given the options chosen.

Not everyone needs all this stuff. If you're doing one fixed design that will only be implemented in one way then you might be just as well off using traditional tools. It's like trying to explain to someone who is perfectly happy writing ARM assembly language why they might want to use C instead (so their code works on x86 and PowerPC and RISC-V as well) or why they might want to use C++ templates, or why they might want to write a program in Perl or Lisp or Haskell that generates some of the C++ code for them.