Regarding unbounded queues
On Sunday, March 12, 2023 12:00pm, Dave Taht <[email protected]> said:
> Also it increasingly bothers me to see unbounded queues in so many new
> language libraries.
I disagree somewhat. Unbounded queueing is perfectly fine in a programming
language like Haskell, where there are no inherent semantics about timing - a
queue is an ordered list with append, and it's a GREAT way to formulate many
algorithms that process items in order.
Where the problem with queues arises is in finite (bounded) real-time
programming systems. Which include network protocol execution machines.
It's weird to me that people seem to think that languages intended for
data-transformation algorithms, parsers, ... are appropriate for programming
network switches, TCP/IP stacks, etc. It always has seemed weird beyond belief.
I mean, yeah, Go has queues and goroutines, but those aren't real-time
appropriate components.
What may be the better thing to say is that it increasingly bothers you that NO
ONE seems to be willing to create a high-level programming abstraction for
highly concurrent interacting distributed machines.
There actually are three commercial programming languages (which are about at
the level of C++ in abstraction, with the last maybe being at the level of
Haskell).
1. Verilog
2. VHDL
3. BlueSpec
For each one, there is a large community of programmers proficient in them. You
might also consider Erlang as a candidate, but I think its "queues" are not
what you want to see.
Why doesn't IETF bother to try to delegate a team to create such an expressive
programming language or whatever? I'd suggest that starting with Verilog might
be a good idea.
A caveat about my point: I write Verilog moderately well, and find it quite
expressive for modeling networking systems in my mind. I also write Haskell
quite well, and since BlueSpec draws on Haskell's model of computation I find
it easy to read, but I've not written much Haskell.
To me, those who write networking code in C or C++ are stuck in the past when
protocols were documented by bit-layouts of packets and hand-waving English
"standards" without any way to verify correctness. We need to stop worshipping
those archaic RFCs as golden tablets handed down from gods.
Who am I to criticize the academic networking gods, though?
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
