6 ms·

Even though the question is good, the article answer is disappointing. First, I really don't like the angle taken, then the question of abstraction (why we do

by mackwic 12y ago

Even though the question is good, the article answer is disappointing. First, I really don't like the angle taken, then the question of abstraction (why we do it, how) and choices made by languages designers (and variations in their idioms) are so vast that you really can't treat the question through a <1000 signs blog post. Some quick points: - You don't code for the machine, you code to be read by another human (possibly you) in the future. I insist, you will be read regularly and frequently. Thus, your code needs to be clear, precise, and concise. This must be the first thing in mind when coding: program what need to be done in a way that a fellow stranger could understand. - Abstraction is a way to keep a structure of code clear when the interactions become complex and/or abundant. If you can avoid them when still being crystal clear in your code, do it. Direct speaking is always better than convolution. - The main requirements when you code are often one or two of: quick to develop, easy to maintain, extensible, efficient (you control your big-O and _WORST_ exec times), correct (no bug. at. all.), real time (when X happens, Y is done between n µs and m µs during p ns) - So, know when performance is a goal, and know when it's not. Choose your language, your techs, your team considering these goals. - And yeah, C89, C99 and the C++es have a very high overhead of abstraction: clarity, concision, and sometimes performance (all abstractions can't be inlined). Think of it.

haberman 12y ago
You are speaking in vague platitudes, most of which don't contradict what I wrote in the article at all. I was speaking of a specific context in which I was working (writing C or C++ extensions for Python and Ruby), and addressing a specific design question (how much of the library should be in C or C++ vs. Python or Ruby). I guess I didn't specifically say this, but I thought I made it pretty obvious that I'm working in a situation where performance is a factor. My observations were also specific to the question of the relative cost of creating layering abstractions in Python/Ruby vs. C/C++. > And yeah, C89, C99 and the C++es have a very high overhead of abstraction: clarity, concision Now you're just being silly. Abstractions are sometimes good, making things clearer and more concise. The wrong abstractions can make code less clear and concise. Here is my solution to that problem: if an abstraction is not making your code clearer and more concise, don't use it. Saying that abstractions in C and C++ are inherently less clear and concise just shows anti-C/C++ bias.
- theflubba 12y ago
  I don't know if your solution is correct. Many functional abstractions in Haskell, such as those that involve high level typeclass abstractions, make code more esoteric, and not more clear. However this is a tradeoff to make code more based in algebra and logical structure. This is more important than readability and conciseness.
  - nostrademons 12y ago
    There is a very strong argument that you shouldn't be using the high-level esoteric typeclass abstraction in Haskell, or even that you shouldn't be using Haskell for production programming. I say this as someone who likes Haskell a lot and wrote one of the top tutorials on the web for it. But if you run a business based on software, and your core value proposition is not the 100% provability of your code (eg. Galois), then readability and conciseness are absolutely more important than algebra and logical structure.
    - theflubba 12y ago
      Very fair point. Thanks for replying.
adamnemecek 12y ago
> You don't code for the machine, you code to be read by another human This is like the new 'premature optimization is the root of all evil'. Mindlessly repeated without considering any context.
userbinator 12y ago
You don't code for the machine, you code to be read by another human (possibly you) in the future. This is one of those sayings (along with the one on "premature optimisation") that I believe has caused huge amounts of resource wastage over the years, and made much software orders of magnitude more inefficient that it could be. Only the exponential growth in hardware performance has hidden that waste, but that is (fortunately?) coming to an end. Despite humans writing it, code does not exist mainly to be read by humans. It exists to be executed by a machine, to solve a real problem for its users. Your users do not care about your source code. They want a small, fast and efficient application that does what they want. The majority of useful code is executed far more than it's read or written. program what need to be done in a way that a fellow stranger could understand This is vague. I agree with you that writing purposely obtuse code for no other reason isn't a good idea, but you should also be exploiting all the power your programming language has to offer when it can make your code simpler and more efficient. I believe that if someone else using the same programming language cannot understand your code, then they should improve themselves so they can. See also: http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/
- RedNifre 12y ago
  No, you code to get the job done in an optimal way which usually means for the minimum amount of cost. Given that the cost for a developer is roughly constant while computation time gets cheaper, this means that nowadays it's best to write code that is quick to modify and thus cheap to modify. The way to do this is to make the code easy to read. (There are exceptions where you end up writing difficult Fortran code on a supercomputer, but usually "You don't code for the machine, you code to be read by another human (possibly you) in the future." is a good rule of thumb for efficiency.)
  - svalorzen 12y ago
    While I understand and agree with what you say, this is generally the reason why I never open Facebook, but instead use Pidgin. This is why I don't like YouTube, but instead prefer youtube-dl + mplayer. This is why I'm far more likely to read HN comments versus opening a random webpage, or why I cannot multitask in my not-top-of-the-line smartphone. I have an old laptop which 8 years ago worked just fine, and is now being more and more useless; not because it is degrading, rather because programs are degrading around it. It's like the world is devolving in an effort to churn out as much crap as possible. When I open multiple programs which ought to be simple and things start to lag out, I feel a bit disrespected by developers which to avoid any kind of effort took it out on me cutting out what I could potentially do.

by mackwic 12y ago

haberman 12y ago

You are speaking in vague platitudes, most of which don't contradict what I wrote in the article at all. I was speaking of a specific context in which I was working (writing C or C++ extensions for Python and Ruby), and addressing a specific design question (how much of the library should be in C or C++ vs. Python or Ruby). I guess I didn't specifically say this, but I thought I made it pretty obvious that I'm working in a situation where performance is a factor. My observations were also specific to the question of the relative cost of creating layering abstractions in Python/Ruby vs. C/C++. > And yeah, C89, C99 and the C++es have a very high overhead of abstraction: clarity, concision Now you're just being silly. Abstractions are sometimes good, making things clearer and more concise. The wrong abstractions can make code less clear and concise. Here is my solution to that problem: if an abstraction is not making your code clearer and more concise, don't use it. Saying that abstractions in C and C++ are inherently less clear and concise just shows anti-C/C++ bias.

theflubba 12y ago
I don't know if your solution is correct. Many functional abstractions in Haskell, such as those that involve high level typeclass abstractions, make code more esoteric, and not more clear. However this is a tradeoff to make code more based in algebra and logical structure. This is more important than readability and conciseness.
- nostrademons 12y ago
  There is a very strong argument that you shouldn't be using the high-level esoteric typeclass abstraction in Haskell, or even that you shouldn't be using Haskell for production programming. I say this as someone who likes Haskell a lot and wrote one of the top tutorials on the web for it. But if you run a business based on software, and your core value proposition is not the 100% provability of your code (eg. Galois), then readability and conciseness are absolutely more important than algebra and logical structure.
  - theflubba 12y ago
    Very fair point. Thanks for replying.

adamnemecek 12y ago

> You don't code for the machine, you code to be read by another human This is like the new 'premature optimization is the root of all evil'. Mindlessly repeated without considering any context.

userbinator 12y ago

You don't code for the machine, you code to be read by another human (possibly you) in the future. This is one of those sayings (along with the one on "premature optimisation") that I believe has caused huge amounts of resource wastage over the years, and made much software orders of magnitude more inefficient that it could be. Only the exponential growth in hardware performance has hidden that waste, but that is (fortunately?) coming to an end. Despite humans writing it, code does not exist mainly to be read by humans. It exists to be executed by a machine, to solve a real problem for its users. Your users do not care about your source code. They want a small, fast and efficient application that does what they want. The majority of useful code is executed far more than it's read or written. program what need to be done in a way that a fellow stranger could understand This is vague. I agree with you that writing purposely obtuse code for no other reason isn't a good idea, but you should also be exploiting all the power your programming language has to offer when it can make your code simpler and more efficient. I believe that if someone else using the same programming language cannot understand your code, then they should improve themselves so they can. See also: http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/

RedNifre 12y ago
No, you code to get the job done in an optimal way which usually means for the minimum amount of cost. Given that the cost for a developer is roughly constant while computation time gets cheaper, this means that nowadays it's best to write code that is quick to modify and thus cheap to modify. The way to do this is to make the code easy to read. (There are exceptions where you end up writing difficult Fortran code on a supercomputer, but usually "You don't code for the machine, you code to be read by another human (possibly you) in the future." is a good rule of thumb for efficiency.)
- svalorzen 12y ago
  While I understand and agree with what you say, this is generally the reason why I never open Facebook, but instead use Pidgin. This is why I don't like YouTube, but instead prefer youtube-dl + mplayer. This is why I'm far more likely to read HN comments versus opening a random webpage, or why I cannot multitask in my not-top-of-the-line smartphone. I have an old laptop which 8 years ago worked just fine, and is now being more and more useless; not because it is degrading, rather because programs are degrading around it. It's like the world is devolving in an effort to churn out as much crap as possible. When I open multiple programs which ought to be simple and things start to lag out, I feel a bit disrespected by developers which to avoid any kind of effort took it out on me cutting out what I could potentially do.