markup is not code
Markup is code. Any time you encode something into something else you are coding. "Coders" who write programs are the lowest caste of programmers.
Learning C will make you Ctarded. C is a 50 year old language that is outdated and doesn't allow you to make good abstractions over the system you are going to run your program on. C has caused so many security vulnerabilities that it is not even funny. Everyone thinks that, "Heh, I know C, I'd never make a mistake and create a vulnerability", but everyone is susceptible to this. They promote the UNIX weenie way of thinking that it's always the programmers fault, they should just remember not to do that rather than having an infrastructure in place to catch it for the programmer. The C language has probably set computing back 50 years, or maybe more. Things like bounds checking for accessing arrays are a solved problem You simply use refinement types so that either the compiler can prove that the array is big enough or you have to add an if block checking if the array is big enough and what to do if it isn't. This means trying to write outside the array will cause a compile time error. This technique only makes the compilation slower, the resulting binary will have no performance impact. Well, unless you consider actually handling errors correctly a performance impact. but people will still run into issues and cause security vulnerabilities by reading and writing outside of an array.
I've seen poorly written and confusing VHDL code too. When people are writing side projects or need to follow a strict schedule sometimes corners need to be cut.
Are you designing your circuit with code, or are you actually placing and routing transistors by hand.
I can see the unix brain-rot creeping all over Sun, now.
I have occasion to be in the middle of the design
for an Sbus card (you know, that "Open" bus in sun unix
boxes these days – if you're lucky, when you receive your
machine sun has condescended to actually leave one of them
open for you to put something of your own (or someone
else's) into).
Sun, seeing the need for high-level hardware
modelling in today's complex systems has developed a set of
models in Verilog (a popular hardware description language
due to the fact that it looks much like C….) for driving
and monitoring the sbus hardware. However, it's quite clear
that the unix mindset which the Sun engineers have become
accustomed to has crossed over into their hardware design
and modelling.
First, they provide a model that only works with a
special patch to Verilog (which they don't bundle in with
their hardware model). Now this patch actually deals with
the fact that Verilog inherits some braindeath from C and
apparently you can't get at some of the information Verilog
is storing around unless you go outside of Verilog to do it.
Sun's routines model various sbus transactions, but
they don't give you an actual handle on the data to, say,
check if it's correct.
Just like their network code, there are large
portions of this code which have clearly never been
used/tested. To check timeout on the bus, they look to see
if a certain 8 bit counter has counted up to 256. But
that's ok, if the counter was big enough, then you'd
discover that they actually didn't have any part of the
model sitting around ready to model the things which are
supposed to happen when timeout occurred (after all, since
the counter never reaches 256, the bus never times out —
why have useless code around when it's not needed…).
No wonder they've had so much troubles with
[–] 16410331? ago
kek