5 ms·

I think it is covered by this part: "If a big problem was C code in Erlang, why would using more C be good? Because it's easier to debug when you don't lose c

by ay 14y ago

I think it is covered by this part: "If a big problem was C code in Erlang, why would using more C be good? Because it's easier to debug when you don't lose context between the "application" layer and the lower level code. The big problem we've seen is when C code is getting called from higher level code in the same process, we lose all the debugging context between the higher level code and the underlying C code." OT: My personal best experience with interfacing a higher level language with C from the debugging standpoint was a C+Lua combo, and even then it was far from optimal.

sramsay 14y ago
It's never optimal, and often, it's the source of truly infuriating bugs. Yet for all that, people don't say, "Hey, let's skip the middle man and just call libcurl or libxml or whatever from C. Because you know, these are C libraries." I think they don't do that because they've been told a hundred thousand times that C is for low-level bit fiddling, that manual memory management is impossible, that it's tedious and difficult to write, that it's a "systems language." Honestly, if you haven't programmed in C since college, you should give it a try -- especially if you're on Linux. The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet. I agree with you about C+Lua. I also notice that people who seriously do that are serious C hackers -- which, I suspect, is seldom the case with most users of Python and Ruby.
- betterunix 14y ago
  "The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet." Conspicuously absent from this statement is, "the language features make you more productive," or, "smart programmers using this language are doing things people thought were impossible." The issue with C (and even more so with C++) is that the language features almost always work against you.
  - sramsay 14y ago
    "smart programmers using this language are doing things people thought were impossible." I think the fact that a great number of new, hip, who'd-have-thought-it-was-possible languages are written in C answers this one rather nicely. Not to mention hip new databases, hip new web servers . . . "the language features make you more productive" I think it's precisely this claim that is being called into question. I daily see new language features that strike me as literally marvelous. But when it comes to those features actually leading to increased productivity -- well, "ls /usr/bin" tells a different story about the productivity of people working in this language.
    - betterunix 14y ago
      "I think the fact that a great number of new, hip, who'd-have-thought-it-was-possible languages are written in C answers this one rather nicely" It's worth noting that writing a new language is not really something people think is "impossible." On the other hand, people take the languages that were implemented in C, and do things that nobody else thinks is possible -- things like logistics systems that save the military enough money in a few years to pay for the decades of research leading up to those systems. Sure, C is hiding underneath, but to claim that that means people are "doing things with C" is kind of silly (especially since there is no particular advantage to writing compilers or interpreters in C). For what it's worth, this situation has been inverted: on Open Genera, there was a C compiler written in Lisp, and what it really did was to generate Lisp code from C code (i.e. it was "C-in-Lisp"). This had some interesting benefits e.g. C programs had a garbage collector in that system (the same as the Lisp garbage collector). "when it comes to those features actually leading to increased productivity" It is a matter of what you are doing. For example, I do a lot of work with boolean circuits (related to secure two-party computation, i.e. "theoretical crypto stuff"), and it is nice to be able to write something like the "x*y + z" and have that become this: (lambda (x y z) (or (and x y) z)) In C, what do I get? The macro system is not powerful enough to write a simple expression parser, I cannot overload operators, and there is no support for lambda expressions anyway. So instead of just worrying about the expression itself, what would happen in C (and I know this because at one time I was trying to write this code in C) is that I would have to implement a C function for each expression, spreading the code out and introducing new ways for things to go wrong (a second issue is that the values are not actually simple values; in C, this turns into a mess of pointers etc.). It is not that it is impossible, but I can say this: I am doing more now than I would have been doing in C, and I am not exactly new to writing C code (although the languages I programmed the longest in was actually C++; I am still perfectly comfortable with C, and to be honest I like C++ even less). To be fair, this same argument applies to other high-level languages; Lisp is not exactly unique anymore in being very expressive, and other languages have things that Lisp is missing (like pattern matching, dependent types, etc.). My point is not that Lisp will change everything, though there seems to be a renewed interest in Lisp thanks to Clojure, but rather that high level languages absolutely do have a benefit. I suppose for most people, the easiest example is SQL: think about how you would write something as simple as an inner-join query if you could only use C (and then compare that to SQL).
- Wilya 14y ago
  I don't refrain from doing that because someone told me that C is horrible and too low-level. I refrain from doing that because I have tried it in the past, and while it works perfectly fine, it is horribly slow to write. There isn't really any compelling reason why you should spend time ironing the details and memory usage of one lone HTTP request when you could just do 'body = http_get url' and be done with it. You can do a ton of things in C. But it takes time, a lot of it. And sometimes, it's worth sacrificing a few Kb (well, okay, Mb) of memory usage to save time and do a program that does a little more. Don't get me wrong, there's a ton of things I would never do with anything else than C (image processing in C is just so absurdly faster than in any other language, even when you're just calling C libraries). But there's room for higher languages, because between libcurl and libxml, there's a ton of glue code that is way simpler to write in Ruby.
  - betterunix 14y ago
    "image processing in C is just so absurdly faster than in any other language, even when you're just calling C libraries" Hm... https://news.ycombinator.com/item?id=1390944 https://news.ycombinator.com/item?id=1390944 I'm not saying this is representative, but you did bring up image processing.
- bcoates 14y ago
  > The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet. This is causing me some pretty serious issues right now. The C community loves its giant ecosystem of C libraries. Everything on Earth seems to bring in a pile of delicate dependencies on the rest of the C universe. What should be fairly mundane configure, build and deployment problems become nightmares. C is also more likely than a lot of other languages to use outside tools to generate program text as part of a build. In a lot of other languages developers would use those hairy features everyone complains about instead, and avoid complicating the build for everyone who could otherwise treat their library as a black box.
- bch 14y ago
  I disagree with the "sub-optimal" label... Tcl, Lua, Ruby, $whatever are amplifiers for C. Arguably especially in the cases your citing. With libcurl, you want handy, dynamic string handling for parsing results, or doing ad-hoc requests. With libxml I -suspect- that any DOM parsing or XPath work, etc is the only "heavy lifting" component, and easily driven by a higher level scripting language. In use, there's no cost, because areas where a scripted language fails compared to C (performance, low-level bit-fiddling) are not at all applicable in the scripted domain. Conversely the scripted environment brings a comfortable interface to the user, highly dynamic and, like Unix pipes, allow bringing new functionality into the scripted domain and interacting with that universe (bind ruby to curl, do a bunch of ad hoc tests in the REPL, slurp up a list of URLs from a textfile, report all 404s to a database). Driving libxml or libcurl from C doesn't give this multiplier effect. Not that there's no reason to use C, but there are -easy- to identify reasons for using a higher level language. Whether the cost of integrating the two paradigms is worth it depends on the developer, and how they determine value.
- ay 14y ago
  I had to track down the bugs from embedded "gcc -O3" multi-#define-expanded C calling into Lua. Highly perverse definition of fun that would be, yet it was somehow. :-) I read from your comment that the "kids should start with building their own CPU". The Java abstraction disease has eaten far too many souls who think the magic just happens, without regards for the sweaty chaps who make this magic come true :-) I would beg anyone to try to program as many languages as they find around. Both Python and Ruby have their strong traits, though integration with C is not one of them. But "12345.to_s(21)" is a construct that is nowhere else, much like "python -m SimpleHTTPServer". Then Haskell can be fantastic in it's mind-numbing math-derived domain-specificity (This, to me, is the biggest power of C and the biggest drawback of any meta-capable language - anyone new onboard needs to learn the custom shortcuts. C sucks at this so it is relatively easy for onboarding). But all the languages you try leave a useful imprint in your brains. For FFI, however, in my experience nothing can beat the http://luajit.org/ext_jit.html http://luajit.org/ext_jit.html. So, for something that may in the future benefit of low level offload, start with Lua, then move to Luajit, then move to Luajit+C. C being used for (preferrably) purely functional demonstrably performance critical parts. If you do not benefit first of a better TTM if used Python/Ruby... But really it all boils down to using the best tool for the job. Starting your education with assembler (mine was the 16x16 matrix of instruction codes of 8080 back in the day mapping onto bytes of raw data) gives you the insight of what is going down the curtains, and a possibility to keep the higher level languages in check. Sorry for verbosity, bit tired to write in a more terse fashion.
betterunix 14y ago
My own experience with that sort of thing was Lisp calling C through an FFI. In the end, it was too much of a pain and I found a Lisp-only way to do it (it helps that SBCL has POSIX system calls available). Debugging was definitely an interesting one. The Lisp debugger was easily confused by problems in the C code (in fact, I cannot think of a time when it was not confused), and running the entire Lisp environment in gdb was just annoying. In the end, when I debugged, I just wound up strategically placing printf calls in the C code and tracing things manually. Of course, this is not a problem of languages, but of tools. What this says is, "When a language includes an FFI, it must also include a good debugger for the FFI." Not necessarily easy, but not impossible by any means. With enough free time, I suspect that the more experienced programmers on HN could produce such tools for any high level language.

by ay 14y ago

sramsay 14y ago

It's never optimal, and often, it's the source of truly infuriating bugs. Yet for all that, people don't say, "Hey, let's skip the middle man and just call libcurl or libxml or whatever from C. Because you know, these are C libraries." I think they don't do that because they've been told a hundred thousand times that C is for low-level bit fiddling, that manual memory management is impossible, that it's tedious and difficult to write, that it's a "systems language." Honestly, if you haven't programmed in C since college, you should give it a try -- especially if you're on Linux. The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet. I agree with you about C+Lua. I also notice that people who seriously do that are serious C hackers -- which, I suspect, is seldom the case with most users of Python and Ruby.

betterunix 14y ago
"The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet." Conspicuously absent from this statement is, "the language features make you more productive," or, "smart programmers using this language are doing things people thought were impossible." The issue with C (and even more so with C++) is that the language features almost always work against you.
- sramsay 14y ago
  "smart programmers using this language are doing things people thought were impossible." I think the fact that a great number of new, hip, who'd-have-thought-it-was-possible languages are written in C answers this one rather nicely. Not to mention hip new databases, hip new web servers . . . "the language features make you more productive" I think it's precisely this claim that is being called into question. I daily see new language features that strike me as literally marvelous. But when it comes to those features actually leading to increased productivity -- well, "ls /usr/bin" tells a different story about the productivity of people working in this language.
  - betterunix 14y ago
    "I think the fact that a great number of new, hip, who'd-have-thought-it-was-possible languages are written in C answers this one rather nicely" It's worth noting that writing a new language is not really something people think is "impossible." On the other hand, people take the languages that were implemented in C, and do things that nobody else thinks is possible -- things like logistics systems that save the military enough money in a few years to pay for the decades of research leading up to those systems. Sure, C is hiding underneath, but to claim that that means people are "doing things with C" is kind of silly (especially since there is no particular advantage to writing compilers or interpreters in C). For what it's worth, this situation has been inverted: on Open Genera, there was a C compiler written in Lisp, and what it really did was to generate Lisp code from C code (i.e. it was "C-in-Lisp"). This had some interesting benefits e.g. C programs had a garbage collector in that system (the same as the Lisp garbage collector). "when it comes to those features actually leading to increased productivity" It is a matter of what you are doing. For example, I do a lot of work with boolean circuits (related to secure two-party computation, i.e. "theoretical crypto stuff"), and it is nice to be able to write something like the "x*y + z" and have that become this: (lambda (x y z) (or (and x y) z)) In C, what do I get? The macro system is not powerful enough to write a simple expression parser, I cannot overload operators, and there is no support for lambda expressions anyway. So instead of just worrying about the expression itself, what would happen in C (and I know this because at one time I was trying to write this code in C) is that I would have to implement a C function for each expression, spreading the code out and introducing new ways for things to go wrong (a second issue is that the values are not actually simple values; in C, this turns into a mess of pointers etc.). It is not that it is impossible, but I can say this: I am doing more now than I would have been doing in C, and I am not exactly new to writing C code (although the languages I programmed the longest in was actually C++; I am still perfectly comfortable with C, and to be honest I like C++ even less). To be fair, this same argument applies to other high-level languages; Lisp is not exactly unique anymore in being very expressive, and other languages have things that Lisp is missing (like pattern matching, dependent types, etc.). My point is not that Lisp will change everything, though there seems to be a renewed interest in Lisp thanks to Clojure, but rather that high level languages absolutely do have a benefit. I suppose for most people, the easiest example is SQL: think about how you would write something as simple as an inner-join query if you could only use C (and then compare that to SQL).
Wilya 14y ago
I don't refrain from doing that because someone told me that C is horrible and too low-level. I refrain from doing that because I have tried it in the past, and while it works perfectly fine, it is horribly slow to write. There isn't really any compelling reason why you should spend time ironing the details and memory usage of one lone HTTP request when you could just do 'body = http_get url' and be done with it. You can do a ton of things in C. But it takes time, a lot of it. And sometimes, it's worth sacrificing a few Kb (well, okay, Mb) of memory usage to save time and do a program that does a little more. Don't get me wrong, there's a ton of things I would never do with anything else than C (image processing in C is just so absurdly faster than in any other language, even when you're just calling C libraries). But there's room for higher languages, because between libcurl and libxml, there's a ton of glue code that is way simpler to write in Ruby.
- betterunix 14y ago
  "image processing in C is just so absurdly faster than in any other language, even when you're just calling C libraries" Hm... https://news.ycombinator.com/item?id=1390944 https://news.ycombinator.com/item?id=1390944 I'm not saying this is representative, but you did bring up image processing.
bcoates 14y ago
> The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet. This is causing me some pretty serious issues right now. The C community loves its giant ecosystem of C libraries. Everything on Earth seems to bring in a pile of delicate dependencies on the rest of the C universe. What should be fairly mundane configure, build and deployment problems become nightmares. C is also more likely than a lot of other languages to use outside tools to generate program text as part of a build. In a lot of other languages developers would use those hairy features everyone complains about instead, and avoid complicating the build for everyone who could otherwise treat their library as a black box.
bch 14y ago
I disagree with the "sub-optimal" label... Tcl, Lua, Ruby, $whatever are amplifiers for C. Arguably especially in the cases your citing. With libcurl, you want handy, dynamic string handling for parsing results, or doing ad-hoc requests. With libxml I -suspect- that any DOM parsing or XPath work, etc is the only "heavy lifting" component, and easily driven by a higher level scripting language. In use, there's no cost, because areas where a scripted language fails compared to C (performance, low-level bit-fiddling) are not at all applicable in the scripted domain. Conversely the scripted environment brings a comfortable interface to the user, highly dynamic and, like Unix pipes, allow bringing new functionality into the scripted domain and interacting with that universe (bind ruby to curl, do a bunch of ad hoc tests in the REPL, slurp up a list of URLs from a textfile, report all 404s to a database). Driving libxml or libcurl from C doesn't give this multiplier effect. Not that there's no reason to use C, but there are -easy- to identify reasons for using a higher level language. Whether the cost of integrating the two paradigms is worth it depends on the developer, and how they determine value.
ay 14y ago
I had to track down the bugs from embedded "gcc -O3" multi-#define-expanded C calling into Lua. Highly perverse definition of fun that would be, yet it was somehow. :-) I read from your comment that the "kids should start with building their own CPU". The Java abstraction disease has eaten far too many souls who think the magic just happens, without regards for the sweaty chaps who make this magic come true :-) I would beg anyone to try to program as many languages as they find around. Both Python and Ruby have their strong traits, though integration with C is not one of them. But "12345.to_s(21)" is a construct that is nowhere else, much like "python -m SimpleHTTPServer". Then Haskell can be fantastic in it's mind-numbing math-derived domain-specificity (This, to me, is the biggest power of C and the biggest drawback of any meta-capable language - anyone new onboard needs to learn the custom shortcuts. C sucks at this so it is relatively easy for onboarding). But all the languages you try leave a useful imprint in your brains. For FFI, however, in my experience nothing can beat the http://luajit.org/ext_jit.html http://luajit.org/ext_jit.html. So, for something that may in the future benefit of low level offload, start with Lua, then move to Luajit, then move to Luajit+C. C being used for (preferrably) purely functional demonstrably performance critical parts. If you do not benefit first of a better TTM if used Python/Ruby... But really it all boils down to using the best tool for the job. Starting your education with assembler (mine was the 16x16 matrix of instruction codes of 8080 back in the day mapping onto bytes of raw data) gives you the insight of what is going down the curtains, and a possibility to keep the higher level languages in check. Sorry for verbosity, bit tired to write in a more terse fashion.

betterunix 14y ago

My own experience with that sort of thing was Lisp calling C through an FFI. In the end, it was too much of a pain and I found a Lisp-only way to do it (it helps that SBCL has POSIX system calls available). Debugging was definitely an interesting one. The Lisp debugger was easily confused by problems in the C code (in fact, I cannot think of a time when it was not confused), and running the entire Lisp environment in gdb was just annoying. In the end, when I debugged, I just wound up strategically placing printf calls in the C code and tracing things manually. Of course, this is not a problem of languages, but of tools. What this says is, "When a language includes an FFI, it must also include a good debugger for the FFI." Not necessarily easy, but not impossible by any means. With enough free time, I suspect that the more experienced programmers on HN could produce such tools for any high level language.