6 ms·

I think the author hits the nail on the head here: >Almost all the tricks I’ve built up over the years for creating embedded DSLs in Java or Ruby or Clojure ar

I think the author hits the nail on the head here: >Almost all the tricks I’ve built up over the years for creating embedded DSLs in Java or Ruby or Clojure are simply unavailable. >...if there’s one complaint I’ve heard consistently from my fellow developers over the years, it’s that they can’t understand my code until they also understand the set of abstractions I’ve introduced "Tricks" are lovely for personal projects, but no one wants to trawl through them at 3am when the server has gone down. Go removes a lot of tricks, and that makes people sad, but it makes total sense for a language design for large teams. You can still use Go for one-man projects, of course (I do), but don't expect it to be as whimsical an experience as using Ruby or Lisp.

pjmlp 8y ago
In what job does one trawl through code at 3am?
- pdpi 8y ago
  When you’re oncall and something broke.
  - watwut 8y ago
    You are on call for coding? What kind of job is that? This sort of things should be really really rare. If it happens in any regularity, then tricky abstractions are not the main problem. Apparent lack of QA and overall quality is.
    - pdpi 8y ago
      Point is that it broke and you’re trying to figure out why and how to get it fixed. Sometimes looking at the code is the most expeditious way to get there.
      - watwut 8y ago
        If 30 min fix in the middle of the night is your limit, then you better never do any non-trivial project. But my point is, this should not play like this with any kind of regularity. At all. And it is not happening regularly for mission critical projects. It is not that we write without bugs either, it is more that you have processes and multiple systems to avoid middle of the night quick fixes into production.
      - coldtea 8y ago
        >Point is that it broke and you’re trying to figure out why and how to get it fixed Yeah, but the point was made to support an argument (that code should have fewer abstractions so that it's faster to grasp any part while reading in a hurry, as opposed to more abstractions so that it's shorter and more generic, even if that means having to study the big picture to get what some smaller part of code does). Now, if devs routinely had to quickly understand some local code at 3am to fix bugs, as per the example, then sure, fewer abstractions and more clear local code would be better. But since your example is contrived, where does that leave the main argument?
- bborud 8y ago
  When I use the same expression to describe situations when you need to make changes to code and it is really inconvenient to have to spend time and effort to figure out cleverness or wade through someone else's unfamiliar abstractions.
- charleslmunger 8y ago
  I wouldn't want to trawl through macro and DSL heavy code at any hour of the day. A very senior engineer once said "do in two lines what you could have done in one line, if you had just made the interface more complicated".

pjmlp 8y ago

In what job does one trawl through code at 3am?

pdpi 8y ago
When you’re oncall and something broke.
- watwut 8y ago
  You are on call for coding? What kind of job is that? This sort of things should be really really rare. If it happens in any regularity, then tricky abstractions are not the main problem. Apparent lack of QA and overall quality is.
  - pdpi 8y ago
    Point is that it broke and you’re trying to figure out why and how to get it fixed. Sometimes looking at the code is the most expeditious way to get there.
    - watwut 8y ago
      If 30 min fix in the middle of the night is your limit, then you better never do any non-trivial project. But my point is, this should not play like this with any kind of regularity. At all. And it is not happening regularly for mission critical projects. It is not that we write without bugs either, it is more that you have processes and multiple systems to avoid middle of the night quick fixes into production.
    - coldtea 8y ago
      >Point is that it broke and you’re trying to figure out why and how to get it fixed Yeah, but the point was made to support an argument (that code should have fewer abstractions so that it's faster to grasp any part while reading in a hurry, as opposed to more abstractions so that it's shorter and more generic, even if that means having to study the big picture to get what some smaller part of code does). Now, if devs routinely had to quickly understand some local code at 3am to fix bugs, as per the example, then sure, fewer abstractions and more clear local code would be better. But since your example is contrived, where does that leave the main argument?
bborud 8y ago
When I use the same expression to describe situations when you need to make changes to code and it is really inconvenient to have to spend time and effort to figure out cleverness or wade through someone else's unfamiliar abstractions.
charleslmunger 8y ago
I wouldn't want to trawl through macro and DSL heavy code at any hour of the day. A very senior engineer once said "do in two lines what you could have done in one line, if you had just made the interface more complicated".