5 ms·

Maybe your problem is CPU-bound. Maybe there are good C libraries that solve your problem. Maybe you just want to learn C better. Maybe you have latency limits

Maybe your problem is CPU-bound. Maybe there are good C libraries that solve your problem. Maybe you just want to learn C better. Maybe you have latency limits you need to work within. Maybe you just want to be contrary. Sometimes "why not" is worth more than "why."

davidw 13y ago
Pretty much any decent language has a way to call out to C. I wrote a portion of a book on Tcl's C API, for instance, and it's very easy to farm out computationally intensive work to C code, as it is in Python, Ruby and most other things, one way or the other.
- fusiongyro 13y ago
  I suppose a response to the spirit of the remark as a whole rather than one exemplary detail would be asking a lot.
  - davidw 13y ago
    The spirit of using C for web applications is: it'd be faster and simpler just to publish your root password and IP address to the web.
    - fusiongyro 13y ago
      Insights like these are so rare. You must have worked really hard for them.
lmm 13y ago
> Maybe your problem is CPU-bound. Maybe you have latency limits you need to work within. Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. > Maybe there are good C libraries that solve your problem Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C". > Maybe you just want to learn C better. If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).
- kybernetyk 13y ago
  > lots and lots of time to spend micro-optimizing everything If you're an experienced C developer you know what's fast and what not (and you know about things like cache coherency). You don't spend that much time on 'micro optimization' because you know how to layout your memory in the first place, etc.
- bluecalm 13y ago
  >Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. This is just not true. Haskell is terribly (3x,4x) slow comparing to C for the most trivial of computing tasks. You can probably get it to 2x or 1.5x by giving up all the lists and other default data structures as well as writing everything in procedural (by monads) way. If you do all this you can get close to C performance but you just gave up all the advantages of writing in Haskell in the first place. And you are still slow as hell.
  - asdasf 13y ago
    You are just saying the equally wrong thing on the opposing side. You can get to 2x without giving up anything. Lists are just a data structure. So are vectors. You don't give anything up to choose one or the other, you pick the right one and use it. You do not write "everything in procedural (by monads) way" to gain performance. Do notation is literally syntactic sugar, and there is no "perform faster" monad to do it in. Haskell code gets to 2x C speeds the same way C gets to 1x C speeds: profile your code and fix the inefficiencies.
- Jeema101 13y ago
  "Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell." [citation needed]
- davidhollander 13y ago
  > Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.

davidw 13y ago

Pretty much any decent language has a way to call out to C. I wrote a portion of a book on Tcl's C API, for instance, and it's very easy to farm out computationally intensive work to C code, as it is in Python, Ruby and most other things, one way or the other.

fusiongyro 13y ago
I suppose a response to the spirit of the remark as a whole rather than one exemplary detail would be asking a lot.
- davidw 13y ago
  The spirit of using C for web applications is: it'd be faster and simpler just to publish your root password and IP address to the web.
  - fusiongyro 13y ago
    Insights like these are so rare. You must have worked really hard for them.

lmm 13y ago

> Maybe your problem is CPU-bound. Maybe you have latency limits you need to work within. Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. > Maybe there are good C libraries that solve your problem Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C". > Maybe you just want to learn C better. If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).

kybernetyk 13y ago
> lots and lots of time to spend micro-optimizing everything If you're an experienced C developer you know what's fast and what not (and you know about things like cache coherency). You don't spend that much time on 'micro optimization' because you know how to layout your memory in the first place, etc.
bluecalm 13y ago
>Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. This is just not true. Haskell is terribly (3x,4x) slow comparing to C for the most trivial of computing tasks. You can probably get it to 2x or 1.5x by giving up all the lists and other default data structures as well as writing everything in procedural (by monads) way. If you do all this you can get close to C performance but you just gave up all the advantages of writing in Haskell in the first place. And you are still slow as hell.
- asdasf 13y ago
  You are just saying the equally wrong thing on the opposing side. You can get to 2x without giving up anything. Lists are just a data structure. So are vectors. You don't give anything up to choose one or the other, you pick the right one and use it. You do not write "everything in procedural (by monads) way" to gain performance. Do notation is literally syntactic sugar, and there is no "perform faster" monad to do it in. Haskell code gets to 2x C speeds the same way C gets to 1x C speeds: profile your code and fix the inefficiencies.
Jeema101 13y ago
"Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell." [citation needed]
davidhollander 13y ago
> Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell. This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.