Design a better "C"

[tggzzz]

I write code generators occasionally. Yep.

That was sort of my point about Haxe earlier. Really in 90% of cases it’s better to build stuff in a language you can get any staff in.

Ditto, and add off-the-shelf tools rather than custom tools.

It is rare, IMNSHO, that a Domain Specific Language is better than a Domain Specific Library.

But wannabe computer scientists want to create languages in the way wannabe digital engineers want to create processors.

[cfbsoftware]

The main issue on those sorts of decisions is staff turnover. You are basically pushing a training requirement on all new staff and adding a hiring and staff egress risk. I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones. Conversely people tend to leave if this is forced upon them.

In my 40+ years of professional software experience in several different industries (engineering, university, aerospace, defence, plant maintenance and health) I have not found this to be the case. I have not had one job in my life where I haven't had to start using a new programming language as my primary development tool. A competent programmer should be skilled in several different languages and can readily adapt to a new one. If the old dogs in the company can't learn new tricks then it is time to move them on.

An-entry level programmer straight out of school or university is keen to get a job of any sort - all he is looking for is the two-years work experience that many companies require before they even look at you. The more languages they are skilled in the more employable they will be.

There is always a training requirement and issues involved with hiring new staff, but the requirements of application domain knowledge, previous work experience and how the people will fit with the teams they are working with swamp any considerations of what might be their favourite language.

[SiliconWizard]

The main issue on those sorts of decisions is staff turnover. You are basically pushing a training requirement on all new staff and adding a hiring and staff egress risk. I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones. Conversely people tend to leave if this is forced upon them.

In my 40+ years of professional software experience in several different industries (engineering, university, aerospace, defence, plant maintenance and health) I have not found this to be the case. I have not had one job in my life where I haven't had to start using a new programming language as my primary development tool. A competent programmer should be skilled in several different languages and can readily adapt to a new one. If the old dogs in the company can't learn new tricks then it is time to move them on.

An-entry level programmer straight out of school or university is keen to get a job of any sort - all he is looking for is the two-years work experience that many companies require before they even look at you. The more languages they are skilled in the more employable they will be.

There is always a training requirement and issues involved with hiring new staff, but the requirements of application domain knowledge, previous work experience and how the people will fit with the teams they are working with swamp any considerations of what might be their favourite language.

I do agree with you there. But I understand bd139's point within context... and that's why I said context matters a lot here.

There's IMO a big difference depending on if you consider a pure software company - a company that develops and sells software, either stand-alone products, or contracts for others - or any industrial company that happens to write software as part of their product development.

In the former context, I think bd139's view is more usual. If a company's main activity is writing software, and in particular contracted software, it's more usual to favor the "industry-standard" languages of the moment, and it's also usual to have relatively high turnover, thus quick replacement and short training periods are required.

In the latter context, it's less relevant, and the skills people acquire while doing their job are more centered around the specific domain of the company, and a lot less around the programming languages and tools they use.

[brucehoult]

I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones.

What? I'd more than happily do that. Assuming it's a decent language I'm unfamiliar with, not something awful. Though I'll do "awful" for danger money. Having to use a weird OS on my dev machine (I care much less about the deployment machine) would be far more likely to make me refuse. Or having to clock in and out and spend defined hours in an office.

[DiTBho]

If you want a job with eRlang, you need to find a company affiliated with Ericsson.
Amazon, Yahoo, WhatsUp; maybe also Mark Zuckerberg is interested to see a CV.

Otherwise, it's just for personal fun and interest 

I have to learn Ocaml, anyway 

[bd139]

Actually we've got a lot of Erlang in production (fintech). It's fairly everywhere. I am not an Erlang person though

[tggzzz]

I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones.

What? I'd more than happily do that. Assuming it's a decent language I'm unfamiliar with, not something awful. Though I'll do "awful" for danger money.

Your caveat is important. Most home-grown domain specific languages fail that test.

Too often they are the result of lazyness (don't know what we want so we'll insert a scripting language), or bad development practices (it is only a small piece of code, so we don't have to rebuild and retest the entire application), or wannabe language creator syndrome. Usually the DSLanguages are expanded incrementally until not even the creators understand everything that can happen (with conventional languages that takes decades to happen!).

DSLibraries are in every application, of course. They can suffer the above problems, but at least there are tools available and the skills are transferrable to your next user of human resources (and are spotted by "AI" CV filters).

[brucehoult]

I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones.

What? I'd more than happily do that. Assuming it's a decent language I'm unfamiliar with, not something awful. Though I'll do "awful" for danger money.

Your caveat is important. Most home-grown domain specific languages fail that test.

Too often they are the result of lazyness (don't know what we want so we'll insert a scripting language), or bad development practices (it is only a small piece of code, so we don't have to rebuild and retest the entire application), or wannabe language creator syndrome. Usually the DSLanguages are expanded incrementally until not even the creators understand everything that can happen (with conventional languages that takes decades to happen!).

I didn't think you mean N was so large it wasn't even *on* the usual lists.

That's probably better, to be honest. It means the source code is probably easily available (if not already part of your check-out), and the person who made it and understands it is a co-worker. That spells a change to improve it -- perhaps reimplement it compatibly on top of a proper language, with better performance etc.

[DiTBho]

Actually we've got a lot of Erlang in production (fintech)

what does the company do with eRlang?
fin-tech aka fin-ancial-tech-nology? 

There are financial languages out of there, some are written in Ocaml.
I guess the C language is definitively a "no go" for those fields.

[DiTBho]

But, can you write a firmware entirely in Ocaml? or in eRlang? 

[tggzzz]

I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones.

What? I'd more than happily do that. Assuming it's a decent language I'm unfamiliar with, not something awful. Though I'll do "awful" for danger money.

Your caveat is important. Most home-grown domain specific languages fail that test.

Too often they are the result of lazyness (don't know what we want so we'll insert a scripting language), or bad development practices (it is only a small piece of code, so we don't have to rebuild and retest the entire application), or wannabe language creator syndrome. Usually the DSLanguages are expanded incrementally until not even the creators understand everything that can happen (with conventional languages that takes decades to happen!).

I didn't think you mean N was so large it wasn't even *on* the usual lists.

That's probably better, to be honest. It means the source code is probably easily available (if not already part of your check-out), and the person who made it and understands it is a co-worker. That spells a change to improve it -- perhaps reimplement it compatibly on top of a proper language, with better performance etc.

Run away, run away!

Such "reimplementation" often implies that the original team has disappeared, together with the specification. The marketing team is clueless and afraid of ailienating the installed user base, so insists that you duplicate the functions (which implies including the bugs).

[bd139]

Stop describing my job 

[bd139]

Actually we've got a lot of Erlang in production (fintech)

what does the company do with eRlang?
fin-tech aka fin-ancial-tech-nology? 

There are financial languages out of there, some are written in Ocaml.
I guess the C language is definitively a "no go" for those fields.

We use C too. Although I’ve replaced most of that with Go now for architectural reasons.

Erlang sits firmly in the messaging space so trade and integrations mostly.

Go is starting to win there too as well though as it has some idiomatic constructs for concurrency which are easier to reason about. I’m actually working on a rough implementation of Tandem/Hp’s nonstop architecture in Go at the moment which leverages that.

[tggzzz]

But, can you write a firmware entirely in Ocaml? or in eRlang? 

Who cares?!

Can you design an X completely in Y, where X/Y are
transitors/gates
gates/asynchronous FSMs
asynchronous FSMs/registers
registers/synchronous FSMs
synchronous FSMs/HDL
HDL/assembler
assembler/RTOS
RTOS/C
C/FSMs
C/business rules
etc/etc

The point is to choose the abstraction which best matches your problem's description, and ignore all the irrelevant abstractions underneath that.

[DiTBho]

The point is to choose the abstraction which best matches your problem's description, and ignore all the irrelevant abstractions underneath that.

Ocaml comes with debug-mode, but it has no support for ICE, and without an ICE I am more fried and fried chips 

To have eRlang running as kind of "bare metal", I had to embed kernel support for "shebang", plus an eRlang virtual machine. It works, but it's an abominable thing that doesn't allow you to write a firmware for - say - a pocket calculator.

When I think about the Demiurge as the entity responsible for fashioning and maintaining the physical universe, well it's mathematically interesting the Babylonians invented "water games" similar to the modern conceit of "full binary adders". They didn't know anything about the Boolean logic neither how to use the invention, and it was just entertainment, and it's interesting because it demonstrates that it is potentially possible to use *water* instead of *electrons* to build an ALU and a branch unit, which are the basic building blocks for a CPU.

[tggzzz]

The point is to choose the abstraction which best matches your problem's description, and ignore all the irrelevant abstractions underneath that.

Ocaml comes with debug-mode, but it has no support for ICE, and with it I am more fried and fried chips 

To have eRlang running as kind of "bare metal", I had to embed kernel support for "shebang", plus an eRlang virtual machine. It works, but it's an abominable thing that doesn't allow you to write a firmware for - say - a pocket calculator.

When I think about the Demiurge as the entity responsible for fashioning and maintaining the physical universe, well it's mathematically interesting the Babylonians invented "water games" similar to the modern conceit of "full binary adders". They didn't know anything about the Boolean logic neither how to use the invention, and it was just entertainment, and it's interesting because it demonstrates that it is potentially possible to use *water* instead of *electrons* to build an ALU and a branch unit, which are the basic building blocks of the CPU.

Your question was "can you write a firmware entirely in Ocaml? or in eRlang", and I answered "who cares, because...". I don't understand how your response relates to that.

As for "water logic", you miss the current industrial uses of fluid logic...

A simple example is the fluid logic in an automatic transmission gearbox, used to change gears.

40 years ago I was asked to see whether it was worth replacing an FSM implemented in fluid logic with a microprocessor. I concluded it wasn't, since that would have required introducing electricity to an unmanned offshore gas head. That's still true today, see the rubric at https://fluidiclogic.com/ (or https://en.wikipedia.org/wiki/Fluidics ).

[DiTBho]

Your question was "can you write a firmware entirely in Ocaml? or in eRlang", and I answered "who cares, because...". I don't understand how your response relates to that.

Can you write a firmware entirely in Ocaml? No, there is no ICE support, and without ICE support I cannot debug anything at the metal-bare level.

Can you write a firmware entirely in eRlang? No, eRlang depends on a virtual machine to operate (in my example, I embedded one into kernel space), so you can debug things *inside* the virtual machine, but not at the metal-bare level.

[tggzzz]

Your question was "can you write a firmware entirely in Ocaml? or in eRlang", and I answered "who cares, because...". I don't understand how your response relates to that.

Can you write a firmware entirely in Ocaml? No, there is no ICE support, and without ICE support I cannot debug anything at the metal-bare level.

Can you write a firmware entirely in eRlang? No, eRlang depends on a virtual machine to operate (in my example, I embedded one into kernel space), so you can debug things *inside* the virtual machine, but not at the metal-bare level.

And with that we circle around to "who cares". You've selected just one arbitrary pair of abstraction levels in a large continuum of abstraction levels. Why not choose others?

For example, why not choose business rules and HDLs? Some people do cast business rules in FPGA logic!

[Bassman59]

For example, why not choose business rules and HDLs? Some people do cast business rules in FPGA logic!

Aren't the people doing business rules in FPGA logic using high-level synthesis and not writing in an HDL?

[Bassman59]

why not choose business rules and HDLs? Some people do cast business rules in FPGA logic!

maybe because you don't know *how* to manage the process and, worse still, you don't know *how* to debug it? 

HDLs give you tools like Modelsim because it would be *VERY* hard to debug via "formal verification" basically because this approach requires too much time and memory; at each branch the investigation tree exponentially grows, so humans prefer to spend time with "waveform" and true ICEs (logic analyzers in this case). It's a limited approach that doesn't explore all the investigation tree, but it's an approach that *somehow* produces good results.

I think it "produces good results" because we spend a lot of time verifying the small blocks. Of course we all well know that we can introduce errors when we connect the blocks together.

You don't cast business logic in FPGA logic simply because you have neither debug tools nor infrastructures to make it reasonable in terms of "human resources" at the "human-time" scale: hours, days, weeks, months.

This is the reason for high-level synthesis tools. Rather than writing in an HDL, they take the C (or whatever) code and run it through a tool which magically converts it to the FPGA fabric. I guess it's not efficient in terms of FPGA area but the audience for this stuff has the $$$ to spend on the biggest FPGAs.

That said, "business logic" is a rather wide field, so the class of problems to be solved gets narrowed.

[tggzzz]

For example, why not choose business rules and HDLs? Some people do cast business rules in FPGA logic!

Aren't the people doing business rules in FPGA logic using high-level synthesis and not writing in an HDL?

I don't know: I haven't bothered to look!

There are many possible approaches, all the way from coding entirely in something like System-C or the coding top level directly in an HDL. But it is worth noting that the core business rules are normally pretty simple.

A typical application would be

• receiving input
• turning it into appropriately parameterised events
• queueing events for processing
• taking one event's parameters and deciding what to do
• creating a result event
• transmitting that event as output

All except 4 would be conventionally coded in a conventional HDL.

A modern HDL would be able to express 4 (i.e. the business rules) ready for synthesis.

[SiliconWizard]

But, can you write a firmware entirely in Ocaml? or in eRlang? 

The "who cares" reactions to this question were fun to read, although they make a point.

Trying to get back to the topic a bit, one of C's strong points is that it's indeed a language in which you an pretty much implement anything from very low-level to very high-level. Many may not find C very good for high-level abstractions, but it's still doable.

Erlang runs on a virtual machine. While you could probably write your own virtual machine for using Erlang on any target, it's going to take a lot of work for any target/platform that is not readily supported. Probably no one is going to do this. Besides, even the most minimal VM for Erlang is likely to require a lot more memory than any typical MCU has. If that's the kind of target you have in mind.

As to Ocaml, AFAIR, you can compile it into bytecode or into native code directly. But again here, the number of supported platforms is probably going to exclude anything like MCUs. And even native code requires a significant runtime, which you would also have to write for the specific target you wanna use. But I don't even know if there's any Ocaml compiler that supports, say, ARM-Cortex MCUs, for instance. So already good luck writing your own. (Now if that thing exists, I'll be curious to have a look.)

Of course it all depends on what you call "firmware" here. Erlang can certainly be used to write "firmware". As long as the target you want to use is supported. As I said, I doubt you'll be able to use a modest MCU. But I think there are Erlang tools for PowerPC, for instance, so you could probably use it on systems hosting a PowerPC CPU and consider the software you write here "firmware".

[SiliconWizard]

Your question was "can you write a firmware entirely in Ocaml? or in eRlang", and I answered "who cares, because...". I don't understand how your response relates to that.

Can you write a firmware entirely in Ocaml? No, there is no ICE support, and without ICE support I cannot debug anything at the metal-bare level.

Can you write a firmware entirely in eRlang? No, eRlang depends on a virtual machine to operate (in my example, I embedded one into kernel space), so you can debug things *inside* the virtual machine, but not at the metal-bare level.

I just answered your question, but am a bit intrigued by this reply to tggzzz  you wrote here. It looks like your only points are about debugging, whereas, as I said just above, I think you'd have many other things to work out before even getting to this point.

Besides, you don't "debug" code in languages such as Erlang or Ocaml the same way as you do in C. Different approach. Different mindset. Different tools. That doesn't mean those languages are not usable per se, even for writing "firmware". You seem to have an exxagerated need for low-level debugging tools. Heck, ICEs even? I think the last time I used one was over 20 years ago and that was because we were working on a very old board. As many others here (from what's being discussed on a regular basis), I even very rarely use a simple debugger for firmware development. Having one is certainly not a hard requirement for writing embedded code, and an excessive use of debuggers may be indicative of poor development methods. Just a thought, anyone can feel free to think otherwise.

[tggzzz]

But, can you write a firmware entirely in Ocaml? or in eRlang? 

The "who cares" reactions to this question were fun to read, although they make a point.

Trying to get back to the topic a bit, one of C's strong points is that it's indeed a language in which you an pretty much implement anything from very low-level to very high-level. Many may not find C very good for high-level abstractions, but it's still doable.

Erlang runs on a virtual machine. While you could probably write your own virtual machine for using Erlang on any target, it's going to take a lot of work for any target/platform that is not readily supported. Probably no one is going to do this. Besides, even the most minimal VM for Erlang is likely to require a lot more memory than any typical MCU has. If that's the kind of target you have in mind.

As to Ocaml, AFAIR, you can compile it into bytecode or into native code directly. But again here, the number of supported platforms is probably going to exclude anything like MCUs. And even native code requires a significant runtime, which you would also have to write for the specific target you wanna use. But I don't even know if there's any Ocaml compiler that supports, say, ARM-Cortex MCUs, for instance. So already good luck writing your own. (Now if that thing exists, I'll be curious to have a look.)

Of course it all depends on what you call "firmware" here. Erlang can certainly be used to write "firmware". As long as the target you want to use is supported. As I said, I doubt you'll be able to use a modest MCU. But I think there are Erlang tools for PowerPC, for instance, so you could probably use it on systems hosting a PowerPC CPU and consider the software you write here "firmware".

Of course it should be recognised that Intel has released many many virtual machines for its recent x86-64 bit ISAs.

I don't mean VMs that use those ISAs, I mean VMs that implement those ISAs. Those CISC assembler instructions are interpreted inside the processor and converted into undocumented more "primitive" RISC-like microcoded instructions that are executed by the internal logic.

Anybody vaguely familiar with the widely used AMD 2900 family (or intel 3000 family) of bit-slice processors will instantly recognise the concept. To coin a phrase, "plus ça change, plus c'est la même chose".
https://en.wikipedia.org/wiki/AMD_Am2900
https://en.wikipedia.org/wiki/Intel_3000#3000_Family

[DiTBho]

Erlang runs on a virtual machine

I know, a couple of months ago ago I implemented an eRlang virtual machine in Linux kernel space.
Kind of really crazy crazy thing to do