Comment by maxander | Hacker News Reader

Comment by maxander | Hacker News Reader

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.

> One wonders if we've made technology unnecessarily complicated.

I think we're waaaay past the "wondering" part.

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.

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.

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.

I lean towards providing both -- high-level abstractions sufficient for the 90% built on lower-level abstractions that are available if needed.

Declarative/imperative is orthogonal to high level/low level.

You can have high level imperative APIs... they just need to be explicit.

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.

No, I agree with you. There are some great declarative interfaces and there are many problems best solved by one.

SQL is a great example. But it’s also an example of how difficult it is to make a great declarative API. Look how much effort went into designing and then refining and then adapting SQL to changing needs. It’s been an enormous effort across a huge community.

Same with CSS. Those aren’t things some developer just wrote and they got refined in an application over time. There are entire conferences about the regular redefinition of those interfaces.

My point is that concept doesn’t scale to some large number of abstractions. SQL and CSS are big manifolds that operate on the boundary of your application, and often separate you from an entire other group of developers working to maintain the other side of that contract.

If you try to apply that same setup to every problem, with thousands of declarative manifolds all intersecting within your application, you get chaos. Which is what many modern frameworks try to do. Declarative APIs only work when they are rare and standard and everyone knows them.

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

That's just an excuse to stop mediocre engineers who would fiddle endlessly with pointless micro optimizations.

You very much need to understand the performance of your code if the product has performance requirements that fail unless you do.

I presume most coding is just crudding small strings from UI to database, where performance issues don't kick in, and hence it would be wastefull to care about them.

I've watched production builds to crawl to a halt and become sluggish as molasses because someone in the dev team was indoctrinated in this creed. (Many reasons, including a cartresian explosion in complexity due to some innocuous LINQ calls).

i don’t think it’s a problem of abstraction itself. it’s a problem of poor abtraction. most APIs and things of this sort aren’t some beautifully crafted abstraction that even try to take care of things nicely for you.

and efficiency of computation is the least of my worries. i would like things to just work.

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

Who is saying that? I've worked in video games for 18 years and never heard that. In fact, anyone who said that would get puzzled and suspicious looks. We generally use a very C-like variant of C++.

Your comment sounds accurate from what little I know of the game community. But the reason it is fun to read about game programing is precisely because you guys are so willing to dive into the detail.

I was responding to a comment about Cairo graphics, which I assume is not much used in games. The kind of graphics I was thinking about is things like Cairo, Windows WPF, the Web.

That said: once upon a long time, OpenGL was supposed to be achieve efficiency by being high level so that the rendering stack could optimise your drawing better than you could. That idea didn't work so well and modern OpenGL seems to take the opposite approach.

Cairo is currently desperately asking for development help, so uhh... https://people.gnome.org/~federico/blog/helping-cairo.html

"so uhh..."?

it's not bad because of misguided intentions, it's bad because it lacks resources. really badly, even.

Reply on news.ycombinator.com