3 ms·

"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-i

• 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).
  • sramsay 14y ago
    (especially since there is no particular advantage to writing compilers or interpreters in C). Do you really believe there's no particular advantage to writing a compiler or an interpreter in C? Like, you could write it in Tcl or Perl or Ruby and it wouldn't matter?
    • betterunix 14y ago
      I would not particularly want to write a compiler in Tcl, Perl, or Ruby; on the other hand, if I were free to choose, I would pick Lisp, ML, or Haskell over C for compiler writing any day. For what it is worth, I have written a compiler in C and I have written one in Lisp, and doing it in Lisp was far more pleasant.
• ay 14y ago
  "the language features make you more productive" I discovered this is largely a function of the available libraries. In my practice, mostly I need a quick-and-dirty hack with sockets, and throughout the past few years I came up with something that allows me to whip up a quick prototype in under 10 minutes (shameless plug: https://github.com/ayourtch/libay https://github.com/ayourtch/libay) That gives me enough of high-level structures (refcounted buffers, hash tables, evented i/o) to either write everything in C, or I hook up some Lua callbacks in case I am really in trouble and have to do something high-level). But most of the time, as I grow more meat and "old blisters" around my C lib, I find only-C be mostly enough...