5 ms·

I actually disagree. High-level knowledge without later filling in the gaps leads to cargo-cult software engineering. If people get lost in the details, they a

by kbwt 9y ago

I actually disagree. High-level knowledge without later filling in the gaps leads to cargo-cult software engineering. If people get lost in the details, they are not prepared to fully understand the big picture.

MaxBarraclough 9y ago
I'm not sure that applies to everything, though. I'm sure we agree there's a limit. Joel Spolsky is right when he writes about the 'Law of Leaky Abstractions', but I'm not sure the average CRUD developer needs to know the gory nuts and bolts of his DBMS. Of course they need to know enough to reason effectively about good design, performance, security, etc, and more low-level knowledge is always a good thing. As an extreme example, PHP programmers don't need to understand branch prediction and caches.
- tinymollusk 9y ago
  You are very correct for anyone who would consider themselves a programmer. I was thinking in a bigger scope; with so many non-programmers working technical roles (and especially with data/databases), I think this is a marvellous way for e.g. project managers to have a brief mental model of what a db index is.
- amirouche 9y ago
  I think 'Law of Leaky Abstractions' is overrated. Abstractions always leak, the question is whether it is part of the API and explained or not. Another example that is not indices: async/await is a leak of the underlying implementation and inner working.
  - MaxBarraclough 9y ago
    You've mentioned an abstraction but not explained why it's leaky. I agree that async/await leaks in places, such as in the surprising deadlocks that Stephen Cleary explains. I've met more than one pretty serious C# developer that wasn't aware of this. http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html http://blog.stephencleary.com/2012/07/dont-block-on-async-co... > the question is whether it is part of the API and explained or not More broadly it's a question of pretending things can be wrapped up in tidy self-contained entities, and the idea that we can fully design away the messy details of reality. See also the Three Big Lies of C++ https://youtu.be/rX0ItVEVjHc?t=17m15s https://youtu.be/rX0ItVEVjHc?t=17m15s
    - amirouche 9y ago
      My understanding is that async/await gives the promise to write asynchronous code like synchronous code. Except the use of 'await' it's true.
      - MaxBarraclough 9y ago
        All told I'd say it's an successful but imperfect abstraction. I've been very impressed by it all in all. Concurrent programming isn't easy, and it's not a silver bullet, but it's a great language feature. In an ideal world you'd just take existing synchronous code and throw async/await keywords at it to make it async. The abstraction isn't quite that successful, of course. See Stephen Cleary's AsyncEx library, which provides async-specific functionality such as AsyncLock, which doesn't exist in the standard library. https://github.com/StephenCleary/AsyncEx/wiki/AsyncLock https://github.com/StephenCleary/AsyncEx/wiki/AsyncLock

by kbwt 9y ago

MaxBarraclough 9y ago

I'm not sure that applies to everything, though. I'm sure we agree there's a limit. Joel Spolsky is right when he writes about the 'Law of Leaky Abstractions', but I'm not sure the average CRUD developer needs to know the gory nuts and bolts of his DBMS. Of course they need to know enough to reason effectively about good design, performance, security, etc, and more low-level knowledge is always a good thing. As an extreme example, PHP programmers don't need to understand branch prediction and caches.

tinymollusk 9y ago
You are very correct for anyone who would consider themselves a programmer. I was thinking in a bigger scope; with so many non-programmers working technical roles (and especially with data/databases), I think this is a marvellous way for e.g. project managers to have a brief mental model of what a db index is.
amirouche 9y ago
I think 'Law of Leaky Abstractions' is overrated. Abstractions always leak, the question is whether it is part of the API and explained or not. Another example that is not indices: async/await is a leak of the underlying implementation and inner working.
- MaxBarraclough 9y ago
  You've mentioned an abstraction but not explained why it's leaky. I agree that async/await leaks in places, such as in the surprising deadlocks that Stephen Cleary explains. I've met more than one pretty serious C# developer that wasn't aware of this. http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html http://blog.stephencleary.com/2012/07/dont-block-on-async-co... > the question is whether it is part of the API and explained or not More broadly it's a question of pretending things can be wrapped up in tidy self-contained entities, and the idea that we can fully design away the messy details of reality. See also the Three Big Lies of C++ https://youtu.be/rX0ItVEVjHc?t=17m15s https://youtu.be/rX0ItVEVjHc?t=17m15s
  - amirouche 9y ago
    My understanding is that async/await gives the promise to write asynchronous code like synchronous code. Except the use of 'await' it's true.
    - MaxBarraclough 9y ago
      All told I'd say it's an successful but imperfect abstraction. I've been very impressed by it all in all. Concurrent programming isn't easy, and it's not a silver bullet, but it's a great language feature. In an ideal world you'd just take existing synchronous code and throw async/await keywords at it to make it async. The abstraction isn't quite that successful, of course. See Stephen Cleary's AsyncEx library, which provides async-specific functionality such as AsyncLock, which doesn't exist in the standard library. https://github.com/StephenCleary/AsyncEx/wiki/AsyncLock https://github.com/StephenCleary/AsyncEx/wiki/AsyncLock