3 ms·

I find so many things about this line of reasoning wrong that I don't know where to start. So let's just pick one thing: Haskell does not ignore the physical re

by kqr 4y ago

I find so many things about this line of reasoning wrong that I don't know where to start. So let's just pick one thing: Haskell does not ignore the physical reality of the machine. It's one of few languages that explicitly recognise it. There are more facilities in Haskell to deal with this reality than in almost any other language you can think of.

javajosh 4y ago
Well, in my defense I did offer a "line of reasoning" and not just a flat contradiction with no support. Also, I'm sorry for any discomfort. To use an analogy, if your friend starts dating a girl that you know is bad for him, you can't just tell him that. You'll get punched. Especially early on when he's totally in love. It doesn't matter if you're right or wrong about her, there's no argument that is going to win against love, and to say anything ill of her is only going to cause pain and harm your relationship with your friend. And love is love, this applies to a person or a software tool. I'm sorry for the discomfort, but I'm telling the truth as I see it and am not trying to hurt you. But Haskell, I think she's bad for you.
AnimalMuppet 4y ago
Do you think Haskell recognizes the physical reality of the machine more than C does? If so, how specifically does it do so?
- kqr 4y ago
  Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou. (In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to explain some of the behaviour that can be expected. I would be surprised if any part of the C standard did that.) [1]: I mean, if we're using an x86 derivative we're still talking about a very fancy PDP-11 emulator.
  - AnimalMuppet 4y ago
    I see. The language spec explicitly talks about the machine. That's not nothing. In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say: *(uint32_t*)0xF00BA4 = 0x0102ABCD; or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot less.
    - tome 4y ago
      > C lets me actually control the whole machine Really? Can you run micro-ops?
    - yakshaving_jgt 4y ago
      You know you can write C inside Haskell, right? Like, there's literally nothing stopping you. You can use FFI, and you can also write C inline. You can have the best of both, if you want.
    - dllthomas 4y ago
      There might be a cleaner way of doing it, but do let ptr :: Ptr Word32 = nullPtr `plusPtr` 0xF00BA4 poke ptr 0x0102ABCD should have you covered.

by kqr 4y ago

javajosh 4y ago

Well, in my defense I did offer a "line of reasoning" and not just a flat contradiction with no support. Also, I'm sorry for any discomfort. To use an analogy, if your friend starts dating a girl that you know is bad for him, you can't just tell him that. You'll get punched. Especially early on when he's totally in love. It doesn't matter if you're right or wrong about her, there's no argument that is going to win against love, and to say anything ill of her is only going to cause pain and harm your relationship with your friend. And love is love, this applies to a person or a software tool. I'm sorry for the discomfort, but I'm telling the truth as I see it and am not trying to hurt you. But Haskell, I think she's bad for you.

AnimalMuppet 4y ago

Do you think Haskell recognizes the physical reality of the machine more than C does? If so, how specifically does it do so?

kqr 4y ago
Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou. (In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to explain some of the behaviour that can be expected. I would be surprised if any part of the C standard did that.) [1]: I mean, if we're using an x86 derivative we're still talking about a very fancy PDP-11 emulator.
- AnimalMuppet 4y ago
  I see. The language spec explicitly talks about the machine. That's not nothing. In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say: *(uint32_t*)0xF00BA4 = 0x0102ABCD; or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot less.
  - tome 4y ago
    > C lets me actually control the whole machine Really? Can you run micro-ops?
  - yakshaving_jgt 4y ago
    You know you can write C inside Haskell, right? Like, there's literally nothing stopping you. You can use FFI, and you can also write C inline. You can have the best of both, if you want.
  - dllthomas 4y ago
    There might be a cleaner way of doing it, but do let ptr :: Ptr Word32 = nullPtr `plusPtr` 0xF00BA4 poke ptr 0x0102ABCD should have you covered.