3 ms·

One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware d

One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware design, optics, display technology, manufacturing, user interface design, etc etc. Also, they apparently needed expertise in managing the ins-and-outs of the Windows driver security system. Adding one more subject to their already crowded curriculum wasn't very nice of Microsoft. A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.

andrewmcwatters 9y ago
I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up." When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something and two of them are not recommended OOTB. Or is primarily documented by third parties.
- adrianratnapala 9y ago
  The problem in this case is much deeper than their fault / your fault. The problem is that in this industry we do (have to?) lean too much on the power of abstraction. Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible". But that might not be very efficient at all. The people who write "the system" have to write software that does specific things in specific situations and there will be endless cases which cannot be dealt with efficiently. And the more the interface hides the implementation, the less likely it is that those cases will be obvious.
  - erikpukinskis 9y ago
    Yes, you’re talking about the proliferation of declarative APIs over explicit, imperative ones. My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our expectations about the “make it so” API into our architecture. Getting to a good, explicit, imperative API requires a whole nother step, and often a major refactor. You have to step back and ask “what is really happening now and can I conduct it more directly?” ... but by that time your code works and it hardly seems worth the effort. But it is worth the effort. The declarative API will just get uglier as you add to it, and provide no real guidance about where future additions should go. Just throw another key in the config. Add another conditional. An imperative one will constrain your future choices about how additions can work, and therefore helps you clarify your domain model as you add to it.
    - andreareina 9y ago
      I lean towards providing both -- high-level abstractions sufficient for the 90% built on lower-level abstractions that are available if needed.
      - erikpukinskis 9y ago
        Declarative/imperative is orthogonal to high level/low level. You can have high level imperative APIs... they just need to be explicit.
    - parasubvert 9y ago
      I think your theory and seeming aversion to declarative interfaces is a bit too general. Many declarative interfaces are the culmination of decades of work on re-inventing the wheel at the imperative level. The relational model and SQL databases are a great example of this - “we’ve solved these problems below this line mostly, please move on and focus up the stack closer to the customer/user”. It became a multi billion dollar industry as it nailed the 80/20 rule for data management. And for a large class of problems this remains solid, despite a perpetual subset of engineers that think they can do better than the declarative interface and engine and build an alternative. Sometimes it makes sense to be adventurous and drop back to the imperative level - SQL databases fell over in recent years was the scalability of the underlying engine for the largest uses. But a Postgres or MySQL endures as a great declarative abstraction over a very complicated set of issues.
- nbsd4lyfe 9y ago
  Cairo is currently desperately asking for development help, so uhh... https://people.gnome.org/~federico/blog/helping-cairo.html https://people.gnome.org/~federico/blog/helping-cairo.html
  - ksrm 9y ago
    "so uhh..."?
    - nbsd4lyfe 9y ago
      it's not bad because of misguided intentions, it's bad because it lacks resources. really badly, even.
majewsky 9y ago
> One wonders if we've made technology unnecessarily complicated. I think we're waaaay past the "wondering" part.

andrewmcwatters 9y ago

I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up." When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something and two of them are not recommended OOTB. Or is primarily documented by third parties.

adrianratnapala 9y ago
The problem in this case is much deeper than their fault / your fault. The problem is that in this industry we do (have to?) lean too much on the power of abstraction. Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible". But that might not be very efficient at all. The people who write "the system" have to write software that does specific things in specific situations and there will be endless cases which cannot be dealt with efficiently. And the more the interface hides the implementation, the less likely it is that those cases will be obvious.
- erikpukinskis 9y ago
  Yes, you’re talking about the proliferation of declarative APIs over explicit, imperative ones. My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our expectations about the “make it so” API into our architecture. Getting to a good, explicit, imperative API requires a whole nother step, and often a major refactor. You have to step back and ask “what is really happening now and can I conduct it more directly?” ... but by that time your code works and it hardly seems worth the effort. But it is worth the effort. The declarative API will just get uglier as you add to it, and provide no real guidance about where future additions should go. Just throw another key in the config. Add another conditional. An imperative one will constrain your future choices about how additions can work, and therefore helps you clarify your domain model as you add to it.
  - andreareina 9y ago
    I lean towards providing both -- high-level abstractions sufficient for the 90% built on lower-level abstractions that are available if needed.
    - erikpukinskis 9y ago
      Declarative/imperative is orthogonal to high level/low level. You can have high level imperative APIs... they just need to be explicit.
  - parasubvert 9y ago
    I think your theory and seeming aversion to declarative interfaces is a bit too general. Many declarative interfaces are the culmination of decades of work on re-inventing the wheel at the imperative level. The relational model and SQL databases are a great example of this - “we’ve solved these problems below this line mostly, please move on and focus up the stack closer to the customer/user”. It became a multi billion dollar industry as it nailed the 80/20 rule for data management. And for a large class of problems this remains solid, despite a perpetual subset of engineers that think they can do better than the declarative interface and engine and build an alternative. Sometimes it makes sense to be adventurous and drop back to the imperative level - SQL databases fell over in recent years was the scalability of the underlying engine for the largest uses. But a Postgres or MySQL endures as a great declarative abstraction over a very complicated set of issues.
nbsd4lyfe 9y ago
Cairo is currently desperately asking for development help, so uhh... https://people.gnome.org/~federico/blog/helping-cairo.html https://people.gnome.org/~federico/blog/helping-cairo.html
- ksrm 9y ago
  "so uhh..."?
  - nbsd4lyfe 9y ago
    it's not bad because of misguided intentions, it's bad because it lacks resources. really badly, even.

majewsky 9y ago

> One wonders if we've made technology unnecessarily complicated. I think we're waaaay past the "wondering" part.