HN Theater @HNTheaterMonth

Well I never learned it until the pain and waste of unfinished projects pushed me. This talk by John Carmack was encouraging too. He talks about the importance of finishing projects: https://youtu.be/vlYL16-NaOw

One point that I wish the article had expanded on is the impact on software development. In a recent speech, John Carmack talks of how the power of the desktop will never reach mobile.

https://m.youtube.com/watch?v=vlYL16-NaOw&t=14m20s

This is incredibly exciting. I see the end of Moores law as the return of the era of performance-oriented software development. The past decade was ruled by software methodologies which optimised for developer time at the cost of performance. Moores law was the crutch on which such latency ridden software limped into userland.

With the stabilization of hardware performance, developers can once again put dedicated time and effort into crafting performant software with the assurance that hardware gains will not render their efforts useless in 2 years.

⬐ BoiledCabbage

> This is incredibly exciting. I see the end of Moores law as the return of the era of performance-oriented software development.

And I see this as the exact opposite. Optimizing for developer time is one of the largest productivity enhancements we have. A true/pure positive feedback loop in technological progress. Optimizing for performance is getting little real gain for large human cost.

The end game of optimized for developer efficiency is we can design and implement "anything" we can think of in almost no time flat. The end game for optimizing for performance is it takes significantly longer to develop a program just to run it on the equivalent of 5 years ago hardware.

An analogy: it's early in human writing. People have trouble expressing average thoughts. We can either teach society to have a better grasp on writing and expressing complex ideas precisely. Or we can teach people to write really small because we're running out of paper.

The positive feedback loop of improved development is enormous.

⬐ waivek

If I may, a rebuttal.

The software methodology that has evolved over the last two decades has focused on development time. As such, there has not been much focus/research on performance-first methodologies. I see no reason that developer time cannot be optimized in a performance-first methodology, it's just that a developer time oriented methodology has years of fine tuning in it.

An example for this is video game development. If you look at some talks given by Mike Acton, you can see that it is possible to ship a game while optimizing for developer time. A triple A game is arguably one of the most intricate and complex projects under the label of "Software Engineering". I see no reason why we can't learn from such sub-fields and apply it to general software development.

I also disagree with you saying that "Optimizing for performance is getting little real gain for large human cost". Not optimizing for performance has had led to the creation of unresponsive text editors, slow word processors and a plethora of other latency-ridden software. This in turn affects the user and unfortunately alters their expectations for software.

There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in.

⬐ imtringued

You can improve performance by an order of magnitude or sometimes even more.

You can't improve productivity in the same way.

For personal projects I'll rather take 10x better performance over 100% more productivity.

Why? Because my time is valuable enough to not waste it on slow software.

⬐ BoiledCabbage

> If I may, a rebuttal.

Of course - when it's performing well, it's what this site shines at.

> I see no reason that developer time cannot be optimized in a performance-first methodology

Well clearly it can but it won't be nearly as much of a priority. Just like performance isn't as much of a priority when focusing on developer time. It's not clear what you're specifically rebutting in this section. We're both agreeing that developer-performance will improve significantly less in this model.

And unresponsive text editor gives at most what a 3x slowdown in performance. Very little of a programmer's time is actually inputting text or data. While let's take the other extreme to show a point: Building a distributed transactional relational data driven application from scratch (because our tools weren't built because people would have been optimizing performance of late 90s hw) would be a 1,000x loss of developer productivity.

The scaling factor of productivity just utterly dwarfs human interface performance.

> There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in.

True, but almost everyone would rather 2017 VS not run on a 5 year old laptop, then the best available product right now be Visual Studio 2005 era functionality highly optimized so it can still run on a 5 year old laptop.

⬐ waivek

If text editors slowed down by 3x, I'd be happy. The latency I am complaining about is orders of magnitude higher than 3x. This is the most rigorous benchmarking that I am aware of:

https://pavelfatin.com/typing-with-pleasure/

Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from.

Your next point is valid, it would not make sense to develop such an application from scratch. However, I'm not talking about rebuilding from scratch merely prioritizing performance. This can be done by learning from Data Oriented Design where developers give a lot of importance to performance critical issues such as cache locality. This can be done without rewriting our tools from scratch, it just means that the developer will have to understand how memory works. It's not a tools issue, it's a knowledge issue.

Your last point on Visual Studio makes me want to re-iterate the core of my argument: Performance and developer time optimizations need not be mutually exclusive.

⬐ BoiledCabbage

> Performance and developer time optimizations need not be mutually exclusive

Completely agreed. But since they're not mutually-exclusive why aren't you happy with the status quo? As stated we already can work on some perf improvements while focusing on developer productivity. I believe the reason why you aren't is logically, you'd rather the balance be shifted more towards performance. Which makes sense, but is illustrative of why saying "they aren't mutually exclusive" isn't a counterpoint. We're both discussing where the focus should be - not that the only options are all are nothing. If non mutually-exclusive were the solution, you wouldn't be happy to see this change and a shift towards performance.

> Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from.

Agreed. But taking sublime text as an example. I see peak ide/editor is roughly 7x faster across various tests, and slowest ide/editor is roughly 7x slower. Even combining both we see at most a 50x change in technical measures. Not in human productivity. The majority of the time people are sitting waiting. I think most people would argue that it doesn't take user 50x as long to write any program in Eclips/IDEA as it does in GVim. So that technical slowdown while annoying has a significantly lower impact on user performance.

Any my argument isn't that users shouldn't have to know about performance, or that performance is bad, it's that resources spent on performance come from being spent on productivity.

Here is an alternate view: Writing most software improves developer performance (text editors, communication tools, file system drivers, languages, compilers...). That better software ecosystem allowed developers to then write more / better software.

Over some timescale we can approximate this as P(t2) = P(t1) * e^(rt). Where P(x) is developer productivity at time x. And t is a timespan. And r is the "rate of return" or productivity improvement by writing software. Saying a developer now needs to spend 30% of their time on performance means we now have: P(t2) = P(t1) e^(.7 * r * t). Due to exponential growth this means significantly less productivity over the long term. This is no different than annually getting 20% returns or 13% returns in the stock market. I sounds like a little, but over a long time scale (or a high scaling rate) this adds up significantly. Meaning right now in 2017 we'd be using a decade or older technology (If peak performance slowdown had hit in some year in the past).

Overall I appreciate the debate and enjoy hearing different opinions. In this one, I feel we may just have different values here in the software space. I feel in an ideal world a developer would spend zero-time on performance. Since we don't live in an ideal world we have to spend some, but every bit of time spent on performance is time not spent on building a product. So we should want to minimize the amount of engineering time focused performance. My take is that you feel differently.

⬐ waivek

I think your last sentence sums it up perfectly. It does seem that we have different views on software. Rebutting your points would just rehash my above comment.

The only new point I'd like to add is one that requires imagination. Imagine if we had adopted performance oriented mindset 20 years ago, instead of today and we solved the developer productivity conundrum that we both care about so much. What a wonderful state software would be in, where IDE's can be installed in seconds, each action is instant and the engineer is completely intimate with every aspect of their baby. This depth of knowledge offers a certain creativity that results in amazing things. It lets engineers rise above what is good for the business and gives them the freedom to push software to it's utter limit. That's evolution. That's progress. That's engineering.

PS: The reason I quoted John Carmack specifically in my first comment is because he is such an engineer.

The record: https://youtu.be/vlYL16-NaOw

Here's the upload of just his talk: https://www.youtube.com/watch?v=vlYL16-NaOw