Hacker News Reader

Comment by mercurial | Hacker News Reader

I'm all for simplicity, but often, programmers follow the same cycle:

1. X is bloated, let's reimplement it under the name Y with all the fat trimmed!

2. Notice that the problem may be a little bit harder than originally envisioned, start to add more and more features

3. Y is impossible to distinguish from X

Not to say that sometimes you shouldn't cast down existing systems, but it's often because the times have moved on (eg, Wayland vs X11).

I'll note that 1. is (involuntarily) in the same category as the discourse of populist politicians who promise simple solutions to complex problems. I am wary of both.

View on HN

Case in point: Notice that the web technology stack is really complex. So are the native GUI toolkits on all mature platforms. And something like wxWidgets that wraps all those toolkits is its own kind of complexity. "I know, I'll implement my own beautifully simple UI toolkit and bind it to the core graphics and input APIs on each platform." Congratulations; your beautifully simple solution is going to be off limits to some users, because you haven't handled accessibility, internationalization, etc. So some of that complexity you wanted to avoid was necessary after all. But maybe we can still categorically reject the web stack for applications that don't actually run in a browser.

It looks like you're making a point that these things are all inherently complex.

Isn't it more probable that the tools we have today are just inadequate to deal with those problems? And maybe they are still inadequate after all these years because our industry is very stubborn and doesn't learn from its mistakes?

I see nothing complex about drawing interactive elements on the screen. Smalltalk with its Morphic interface offers a much richer and flexible GUI toolkit and that was out when, in the 60s? How many GUI toolkits have learned from those lessons? And Morphic/Smalltalk was cross-platform before Java, in ways Java isn't to this day. It seems to me what hampers evolution is the technology we choose (Java, C) and not the problem itself (drawing interactive elements on the screen).

For anyone interested in this discussion I recommend Alan Kay's "The Computer Revolution hasn't happened yet": www.youtube.com/watch?v=oKg1hTOQXoY

My point is that the inherent complexity of a UI toolkit is greater than many programmers realize. It's quite easy to implement your own UI that directly draws its controls on the screen and handles mouse clicks. Now, how are you going to make that accessible to blind users? Users with mobility impairments who can't use a mouse? How about right-to-left languages and non-Latin input methods? And there's probably more that I'm not aware of.

Thats true, but there is still plenty of incidental complexity. Poor layout languages with no composition, stateful manipulation of the ui, no way to express components. Tools like React.js and Apple's Auto Layout show that much of this complexity is not actually needed.

Agreed. I like the ideas behind React.js in particular.

I think you are not stepping back far enough to look at the problem. Are you actually suggesting the entire complexity of the current web-stack (html, css, js and server side code) is essential to make web-apps?

I wasn't clear. I know there's a lot of incidental complexity in the web stack. But I'm afraid that some developers, in response to a stirring call to simplicity such as this manifesto, will go too far, blissfully unaware that some of the complexity of mature UI toolkits (not just the web stack, but also the native toolkits of mature platforms) is actually necessary.

I learned a great phrase over the weekend that perfectly applies to #2, "Chesterton's fence"[1]:

"[the] intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

In other words, that feeling when you realize that a thing you've rebuilt because you didn't like it was built that way for a reason.

[1] http://www.chesterton.org/taking-a-fence-down/

This manifesto pushes back hard against step 2. If the software is getting complex, it's worthwhile to reconsider your approach. And if the problem really requires complex software, it's worth changing the environment to simplify the problem instead of writing complex software!

> it's worth changing the environment to simplify the problem instead of writing complex software!

No doubt there is a fair amount of architecture astronautics out there, but thinking you're going to turn complex problems into simple problems by "changing the environment" is most of the time extremely naive. You can push against reality all you want, but reality tends to push back.

"Reality is going to push back." It's a tradeoff, but experience has shown that fixing the problem without software will cause fewer headaches in the long run than fixing it with complex software.

At the risk of belaboring the point from my other sub-thread...

Suppose you've developed an application that has a graphical user interface. For the sake of simplicity, you rejected all of the overly complex GUI toolkits out there and rolled your own, with the assumption that all of your users can see what you're drawing on the screen. So you didn't implement your host platform's accessibility API (assuming you're running on a host platform with an accessibility API.) Now, a blind person needs to use your software. How do you fix that problem without software?

Beyond that specific example, the point is that, as the GP said, trying to change the environment to eliminate inherent complexity is often not feasible.

Most of the complexity in these GUI toolkits is unrelated to accessibility or other "essential but non-obvious" features, so I don't think this is a good point.

As I mentioned, rethinking your approach is also valid. Making bad assumptions upfront is the cause of a lot of added complexity.

Maintaining complex software is also infeasible. Maybe we're doomed.

I implemented my own UI framework once on top of WPF:

http://bling.codeplex.com/

But I did something different: rather than wrap high-level APIs in even more higher-level APIs, I instead focused on making it "simple to express the math." So for a table, you could use data binding to simply express some constraints on cell width, height, adjacency, and so on. So I never bother using what WPF calls a table (or list or whatever); I would just use canvas and organize the cells using a few lines of math. That is quite liberating!

It is not always the case that GUI toolkit goes in the direction of increasingly more abstraction.

[citation needed]

More seriously, there are many classes of problems which range from extremely impractical to impossible to tackle without software. The question is also, who is getting the headaches? If you pile up enough man-hours on the most awful software, it will eventually work satisfactorily. Customers don't give a damn about the underlying code, nor they should, they want a product that works.

Most attempts at radical change will fail, does that mean it's not worth trying? Sometimes it does work, and the world becomes much better as a result.

As usual, the big issue is "do you actually understand the problem you need to solve?". Many problems are complex, either per se or due to constraints outside of your control. Maybe you don't like to have to implement a lot of complex code to interact with a terribly programmed legacy app, but if your customer pays you to do that, that's the kind of constraint you cannot really do anything about. When you look at it closely, my feeling is that you'll find a lot of apparently-unnecessary complexity is there for a good reason, and it's our job to make this complexity manageable.

It doesn't mean you shouldn't challenge existing paradigms. Innovate! Blow our minds! But just make sure you understand the problem you're solving first :)

As a researcher, I have freedom to constantly reinvent things. Complexity melts away the better you understand your problem: ya, it was there, it was needed, but now I know more and I can get rid of this. People in production don't usually have these benefits.

I have only made this letter longer because I have not had the time to make it shorter. - Blaise Pascal.

I think that's often true for blue-sky projects. And I agree that a better understanding of the problem can lead to a reduction in complexity, but you cannot always afford it.

As long as we are talking about reinventing programming, I think we can afford it. The problem is that once you are in production, you have to ship...this is what I always got from RPG's "worse is better!"

Of course, it's a matter of tradeoffs. It's particularly interesting to observe how Rust is moving along: since I started watching it, it has undergone a huge quantity of non-trivial changes. Which would tend to show that "worse is better" doesn't work for programming languages. Indeed, languages which have grown organically, like PHP, are not well-regarded. Maybe it's a question of surface: the smaller unpolished surface you expose to the outside, the faster you can ship something which will not turn into PHP later. If your CLI is not well thought-out, it's not a big problem, but you won't be able to make drastic, incompatible changes in syntax and semantics for a programming language with millions of existing lines (ask the Python 3 people :) ).

In which Y is usually prefaced with "micro"...

Reply on news.ycombinator.com