3 ms·

I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs

by tlb 9y ago

I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs with robots. Most of them liked the danger. They enjoyed having mastered the art of not getting killed by falling tree branches, or live wires, or runaway trucks, or whatever the job involved. They felt satisfaction at doing a job where, if someone else tried to do it, they'd probably get hurt on their first day. You can imagine various ways this could have evolved in hunter-gatherer societies. Most new languages are far safer than C. For some that's the main selling point, for others it's just a side-effect of having GC. I wonder if you could get a lot of traction with a language as expressive as Ruby, but with footguns galore. I'm not sure that space has been adequately explored.

AnimalMuppet 9y ago
I wouldn't put it as "danger", exactly. It's freedom. The language won't trap you, pretty much ever. You need to write directly to hardware registers? Fine. You need to drop into assembly for a bit? Go for it. However down-and-dirty you have to get, you can do it. Whereas with some other languages, if you ever need to get more down-and-dirty than the language is designed to allow, even for just a little bit of your program, well, too bad - you're not allowed to.
- pjmlp 9y ago
  I could do all of that in Turbo Pascal, Turbo Basic and Modula-2 compilers.
  - AnimalMuppet 9y ago
    Ah, I had forgotten that Turbo Pascal let you drop into assembly. But could you write directly to a hardware address? I don't know, but I doubt it - Turbo Pascal ran on the PC, which didn't have memory-mapped hardware. You could do an outp. But in C, you could do *(unsigned long*)0xFFFE0004 = 0x8000FF2C; which was either absolutely necessary or absolutely stupid, depending on whether or not you had custom memory-mapped hardware at the specified address. Could you do that in Turbo Pascal? What's more, Turbo Pascal was PC-only, at least initially. If you had to work on a 68000-based embedded system running PDOS (not PC-DOS), and you had to use Pascal, it wasn't Turbo Pascal. It was just bog-standard Pascal. Inline assembler? No way. Pointer to a variable-sized array? Can't do it (you cannot give it a type). It was painful to work in that environment. And that environment was Pascal as specified by the language standard. Turbo Pascal fixed most of the problems, but it trampled all over the standard to do it. (At least it did have separate compilation.) Why was it painful to work in that environment? First, we couldn't access our custom hardware without having to link to an assembly-language subroutine. In doing so, we lost type safety, which led to at least one hard-to-find crash. It also was just much more difficult and error-prone to write those routines. Second, we wanted to have a user-specified variable-sized array. We wound up having to create the largest array we could given the memory the machine had, and only using the part that the user specified, which was a pretty ugly kludge. Third, Pascal was just clumsier to use than C. It was more verbose and more finicky. (One part I remember in particular was the semicolons. You couldn't have a semicolon on the last statement in a block. As you added or removed statements, you kept having to fiddle with the semicolons, including on lines other than the ones you were changing.)
    - pjmlp 9y ago
      Something like, myMemoryAddr : Longint absolute $FFFE0004; There were Turbo Pascal compatible compilers for Amiga, and it was the most common dialect, to the point ISO Extended Pascal compatibility was mostly ignored. There are still companies selling Turbo Pascal compatible compilers for embedded systems. https://www.mikroe.com/mikropascal/ https://www.mikroe.com/mikropascal/ Inline Assemly is not part of C, it is a common compiler extension, whose semantics are not even portable across compilers. Back in the day when Pascal compilers were more widespread, C was hardly much more portable, with each compiler having its own little world between K&R C and ANSI C89.

by tlb 9y ago

AnimalMuppet 9y ago

I wouldn't put it as "danger", exactly. It's freedom. The language won't trap you, pretty much ever. You need to write directly to hardware registers? Fine. You need to drop into assembly for a bit? Go for it. However down-and-dirty you have to get, you can do it. Whereas with some other languages, if you ever need to get more down-and-dirty than the language is designed to allow, even for just a little bit of your program, well, too bad - you're not allowed to.

pjmlp 9y ago
I could do all of that in Turbo Pascal, Turbo Basic and Modula-2 compilers.
- AnimalMuppet 9y ago
  Ah, I had forgotten that Turbo Pascal let you drop into assembly. But could you write directly to a hardware address? I don't know, but I doubt it - Turbo Pascal ran on the PC, which didn't have memory-mapped hardware. You could do an outp. But in C, you could do *(unsigned long*)0xFFFE0004 = 0x8000FF2C; which was either absolutely necessary or absolutely stupid, depending on whether or not you had custom memory-mapped hardware at the specified address. Could you do that in Turbo Pascal? What's more, Turbo Pascal was PC-only, at least initially. If you had to work on a 68000-based embedded system running PDOS (not PC-DOS), and you had to use Pascal, it wasn't Turbo Pascal. It was just bog-standard Pascal. Inline assembler? No way. Pointer to a variable-sized array? Can't do it (you cannot give it a type). It was painful to work in that environment. And that environment was Pascal as specified by the language standard. Turbo Pascal fixed most of the problems, but it trampled all over the standard to do it. (At least it did have separate compilation.) Why was it painful to work in that environment? First, we couldn't access our custom hardware without having to link to an assembly-language subroutine. In doing so, we lost type safety, which led to at least one hard-to-find crash. It also was just much more difficult and error-prone to write those routines. Second, we wanted to have a user-specified variable-sized array. We wound up having to create the largest array we could given the memory the machine had, and only using the part that the user specified, which was a pretty ugly kludge. Third, Pascal was just clumsier to use than C. It was more verbose and more finicky. (One part I remember in particular was the semicolons. You couldn't have a semicolon on the last statement in a block. As you added or removed statements, you kept having to fiddle with the semicolons, including on lines other than the ones you were changing.)
  - pjmlp 9y ago
    Something like, myMemoryAddr : Longint absolute $FFFE0004; There were Turbo Pascal compatible compilers for Amiga, and it was the most common dialect, to the point ISO Extended Pascal compatibility was mostly ignored. There are still companies selling Turbo Pascal compatible compilers for embedded systems. https://www.mikroe.com/mikropascal/ https://www.mikroe.com/mikropascal/ Inline Assemly is not part of C, it is a common compiler extension, whose semantics are not even portable across compilers. Back in the day when Pascal compilers were more widespread, C was hardly much more portable, with each compiler having its own little world between K&R C and ANSI C89.