8 ms·

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example o

by rtpg 13y ago

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing for free, and there's no longer many excuses to run around with raw pointers except for legacy code.

jcalvinowens 13y ago
> There are languages that make it very very hard to write bad code. Haskell [...] Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... and no amount of security is worth a 1000% performance hit, let alone a vague "security mistakes are less likely this way" sort of security. Being secure is useless if your code is so slow that you have to run so many servers you don't make a profit. Could the Haskell compiler be improved to the point that this isn't a problem? Maybe. Ultimately I think the problem is that Haskell code is very unlike object code, and that makes writing a good compiler very difficult. C is essentially portable assembler; translating it to object code is much more trivial. > C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. C offers simplicity. Sure, there are some quirks that are complex, but by and large it is one of the simplest languages in existence. Once you understand the syntax, you've essentially learned the language. Contrast that to Java and C#: you are essentially forced by the language to use this gigantic and complicated library all the time. You are also forced to write your code in pre-determined ways, using classes and other OOP abstractions. In C, I don't have to do that: I can write my code in whatever way I feel makes it maximally readable and performant. C also offers flexibility: in C, I can make the computer do absolutely anything I want it to in exactly the way I want it to. Maybe I don't like 8-byte pointers on my 64-bit CPU, and I want to implement a linked list allocating nodes from a sparse memory-mapped pool with a known base address using 16-bit indexes which I add to the base to get the actual addresses when manipulating the list? That could be a big win depending on what you're doing, and (correct me if I'm wrong) there is no way to do that in Java or Haskell. > there's no longer many excuses to run around with raw pointers except for legacy code. If by "raw pointer" you mean haphazardly casting different things to (void * ) or (char * ) and doing arithmetic on them to access members of structures or something, I agree, 99.9% of the time you shouldn't do that. Or are you talking about that "auto_ptr" and so-called "smart pointer" stuff in C++? In that case, your definition of "raw pointer" is every pointer I've ever defined in all the C source code I've ever written. Pointers exist because that's the way computer hardware works: they will never go away. I'd rather deal with them directly, since it allows me to be clever sometimes and make things faster.
- Dylan16807 13y ago
  >no amount of security is worth a 1000% performance hit Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops. Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone. Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=ghc&lang2=gcc&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as C.
  - jcalvinowens 13y ago
    > Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL is a very performance-critical piece of most server-side software in the wild. If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money. > Also random BS benchmark says haskell is at least half as fast as C. I never said my "quick searching" was exhaustive. I suspect the relative performance is heavily dependent on what exactly is being done in the code.
    - MaulingMonkey 13y ago
      > If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money. All other things being equal, yes. But responding to security incidents also costs a lot of people a lot of money.
    - Dylan16807 13y ago
      SSL itself is a tiny fraction of the CPU load on a normal webserver. The idea that it's expensive has done more harm than many other things. It wouldn't cost anything except on accelerator boxes.
      - deleted 13y ago
krakensden 13y ago
> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. For a value of 'correct' that includes "uses all available memory and falls over".
twic 13y ago
> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. I really wish people would stop saying this. It's not in the slightest bit true. Making this assertion makes Haskellers seem dangerously naive.
- rtpg 13y ago
  it's just probably correct ;)
- makomk 13y ago
  This is especially true in the field of crypto, where timing attacks are a major issue. Knowing that your program will produce the correct result isn't enough, you need to know that the amount of time taken to compute that result doesn't leak information, and I don't think Haskell provides any way to ensure this.
  - stevejones 13y ago
    Haskell in fact does the opposite. Changes in compiler version can drastically alter the performance of your code, even changing its O() class.
orthecreedence 13y ago
How do I embed your Haskell library in my Lisp program? This is where C shines...it can be used everywhere, including embedded in other programs, now matter what language it's in.
- zopa 13y ago
  Like this: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#ffi-library http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-.... Haskell's FFI works both ways. (It's not free: you need to link in the entire Haskell runtime system, which is not small. But you can absolutely do it.)
  - orthecreedence 13y ago
    Cool, thanks for the link. Didn't know this was possible.

by rtpg 13y ago

jcalvinowens 13y ago

> There are languages that make it very very hard to write bad code. Haskell [...] Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... and no amount of security is worth a 1000% performance hit, let alone a vague "security mistakes are less likely this way" sort of security. Being secure is useless if your code is so slow that you have to run so many servers you don't make a profit. Could the Haskell compiler be improved to the point that this isn't a problem? Maybe. Ultimately I think the problem is that Haskell code is very unlike object code, and that makes writing a good compiler very difficult. C is essentially portable assembler; translating it to object code is much more trivial. > C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. C offers simplicity. Sure, there are some quirks that are complex, but by and large it is one of the simplest languages in existence. Once you understand the syntax, you've essentially learned the language. Contrast that to Java and C#: you are essentially forced by the language to use this gigantic and complicated library all the time. You are also forced to write your code in pre-determined ways, using classes and other OOP abstractions. In C, I don't have to do that: I can write my code in whatever way I feel makes it maximally readable and performant. C also offers flexibility: in C, I can make the computer do absolutely anything I want it to in exactly the way I want it to. Maybe I don't like 8-byte pointers on my 64-bit CPU, and I want to implement a linked list allocating nodes from a sparse memory-mapped pool with a known base address using 16-bit indexes which I add to the base to get the actual addresses when manipulating the list? That could be a big win depending on what you're doing, and (correct me if I'm wrong) there is no way to do that in Java or Haskell. > there's no longer many excuses to run around with raw pointers except for legacy code. If by "raw pointer" you mean haphazardly casting different things to (void * ) or (char * ) and doing arithmetic on them to access members of structures or something, I agree, 99.9% of the time you shouldn't do that. Or are you talking about that "auto_ptr" and so-called "smart pointer" stuff in C++? In that case, your definition of "raw pointer" is every pointer I've ever defined in all the C source code I've ever written. Pointers exist because that's the way computer hardware works: they will never go away. I'd rather deal with them directly, since it allows me to be clever sometimes and make things faster.

Dylan16807 13y ago
>no amount of security is worth a 1000% performance hit Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops. Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone. Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=ghc&lang2=gcc&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as C.
- jcalvinowens 13y ago
  > Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL is a very performance-critical piece of most server-side software in the wild. If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money. > Also random BS benchmark says haskell is at least half as fast as C. I never said my "quick searching" was exhaustive. I suspect the relative performance is heavily dependent on what exactly is being done in the code.
  - MaulingMonkey 13y ago
    > If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money. All other things being equal, yes. But responding to security incidents also costs a lot of people a lot of money.
  - Dylan16807 13y ago
    SSL itself is a tiny fraction of the CPU load on a normal webserver. The idea that it's expensive has done more harm than many other things. It wouldn't cost anything except on accelerator boxes.
    - deleted 13y ago

krakensden 13y ago

> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. For a value of 'correct' that includes "uses all available memory and falls over".

twic 13y ago

> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. I really wish people would stop saying this. It's not in the slightest bit true. Making this assertion makes Haskellers seem dangerously naive.

rtpg 13y ago
it's just probably correct ;)
makomk 13y ago
This is especially true in the field of crypto, where timing attacks are a major issue. Knowing that your program will produce the correct result isn't enough, you need to know that the amount of time taken to compute that result doesn't leak information, and I don't think Haskell provides any way to ensure this.
- stevejones 13y ago
  Haskell in fact does the opposite. Changes in compiler version can drastically alter the performance of your code, even changing its O() class.

orthecreedence 13y ago

How do I embed your Haskell library in my Lisp program? This is where C shines...it can be used everywhere, including embedded in other programs, now matter what language it's in.

zopa 13y ago
Like this: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#ffi-library http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-.... Haskell's FFI works both ways. (It's not free: you need to link in the entire Haskell runtime system, which is not small. But you can absolutely do it.)
- orthecreedence 13y ago
  Cool, thanks for the link. Didn't know this was possible.